News for hackers. Stuff that matters.
Re:How Tail Call Optimization Works by aste-risk on Friday January 08, 2021 @01:42AM (#25682214)
how do modern compilers like clang/gcc handle the debug info while still doing TCO? Any description or links appreciated.
Re:How Tail Call Optimization Works by tomp on Friday January 08, 2021 @09:22AM (#25684961)
Clang will very aggressively optimize with -O2 (or whatever the max speed optimization is). It think gcc and MSVC as well.

I was experimenting with a simple indirect-threaded interpreter, which I wanted to write in a "nice" style (1 function per opcode) but have compiled in an "optimized" way (state machine). Playing around in Godbolt, I found out that the compilers managed to detect & optimize even indirect tail calls, i.e. tail calls to function pointers. This was indeed on a toy example (i.e. like 5 functions, not a real interpreter with 100 different opcodes) but still truly amazing.

The reason for this was, I was trying to replicate LuaJIT2 - Mike Pall was complaining that the reason interpreters written in C are slow is, that the compiler cannot optimize & register-allocate a large function containing a switch statement for 100 opcodes. Instead, he wrote the interpreter in asm, and made sure all important variables are kept in registers. My thesis was that we could do the same thing by having a bunch of functions tail-calling each other, with all important variables as parameters (which would be optimized into registers). Better, actually, because the compiler could improve register allocation within each "opcode"/function.

Re:How Tail Call Optimization Works by millstone on Friday January 08, 2021 @02:23AM (#25682428)
They don't. The whole point of TCO is to discard stack frames, which means local variables cannot be recovered. Optimize or debug, pick one.
Re:How Tail Call Optimization Works by manwe150 on Friday January 08, 2021 @02:44AM (#25682541)
My recollection (without references) is that they can do some amount of guess work. They might see the stack says A->C, but can see the code of A actually calls B, so logically it must have been A->B->C at some point.

Or you can use the rr-debugger, and just return back to the exact sequence of calls, and reject the need to pick between optimization and debugging :D

Re:How Tail Call Optimization Works by eyelidlessness on Friday January 08, 2021 @02:42AM (#25682529)
Well, the point of TCO is to discard stack pressure. Discarding stack frames is just an unfortunate side effect.
Re:How Tail Call Optimization Works by Geminidog on Friday January 08, 2021 @03:36AM (#25682797)
clang will actually optimize non tail recursive function as well. Check out the code in this question. It will not stack overflow.

https://stackoverflow.com/questions/65225761/trying-to-delib...

Re:How Tail Call Optimization Works by namibj on Friday January 08, 2021 @06:55AM (#25683728)
Pun intended?
Re:How Tail Call Optimization Works by Geminidog on Friday January 08, 2021 @12:36PM (#25687267)
People who say "no pun intended" are cowards. Intend your puns weaklings.
Re:How Tail Call Optimization Works by eyelidlessness on Friday January 08, 2021 @01:43PM (#25688203)
I usually say “punexpected” because I think what’s meant by “no pun intended” is usually “I only recognized the pun after I said it”. But I agree! Puntention is best.