Re: Help on code generation and register allocation

Whywhat wrote:
> I always considered tail recursion elimination to be a
> target-independent optimization process. So what does it have to deal
> with register allocator and processor architecture?


On PPC for instance it's easy to just pack arguments in some registers,
pop the stack, and jump to the tail-calling location. On x86 you don't
have registers, so you pass (at least some) arguments on the stack.
That means you have to put whatever resided on the stack before in some
other location: registers (which have to be saved) or somewhere else on
the stack. Read my post again for how I'd prepare for a tail call on x86.


But it's not only CPU-dependent, but also register dependent, because
you can't simply push registers and call. You have to pop the stack
before calling, so you have to save those values somewhere else. As I
said, on most RISC machines that isn't a problem, but with THE
architecture for desktop, server, and workstation use, it is.


If tail recursion were completely target independent (and an
optimization), I don't see why not all compilers would Just Do It.
Especially GCC in Intel doesn't do it (except maybe for
self-tail-recursion), which means that you have to use trampolines, or
weird source code transformations to achieve the same effects (e.g. when
you want to transform a DFA to machine code, routines tail-calling each
other).


--
Suffering from Gates-induced brain leakage...

Return to the comp.compilers page.
Search the comp.compilers archives again.