[fpc-devel] Tail recursion optimization
Jonas Maebe
jonas.maebe at elis.ugent.be
Tue Oct 10 14:12:10 CEST 2006
On 10 okt 2006, at 13:46, Florian Klaempfl wrote:
> Practical argument:
> the assembler code _is_ better for the code I tested and up to as
> twice as fast
> as the original one.
That's indeed true for an extremely small function with so few local
variables/parameters that even on an i386 it doesn't need spilling in
the absence of register allocation optimizations. That's why I said
it *may* currently degrade performance in more complex functions (it
also may not, I really don't know, it was just a remark).
> Theoretical argument:
> - using the tail goto you've one function with one set of variables
> being active
> across the the whole function
> - using a recursive call you've at least two sets of variables: the
> caller and
> the callee ones. Though one set is only active at a limited part of
> the
> function, the set of the caller is still in use while the callee is
> called
> though they (the caller variables) are spilled.
The first point is just as much a downside as an upside in the
current situation, because parameters/variables which are used
without being destroyed by some function call can normally be put in
a (reusable) volatile register. Now they need a non-volatile register
during the entire function.
The fact that you get such a speedup is in my view mainly an
indication of the fact that the function barely does anything, and
that almost half the time is spent in setting up and tearing down
stack frames. So it's logical that register allocation has little
influence and that optimizations which remove this stack frame logic
help a lot.
> I guess it could be used to change to code above to
> leal 1(%esi),%eax
> ?
Yes.
> Or is this slower on some CPUs?
I don't know.
Jonas
More information about the fpc-devel
mailing list