This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386 string patterns vs global registers
On 12-Feb-2003, Richard Henderson <rth@redhat.com> wrote:
> BTW, how are things working out with the tail-call stuff?
The lack of support for tail calls with `-fpic' is a serious impediment.
I have not yet committed the approved patch which adds a hook to the
GCC back-end to allow the front-end to force tail calls, because I do not yet
have a copyright assignment. (I'm working on that, but I've been dragging
my heels on it for the last few weeks due to license-negotiation-fatigue.
I won't bore you with the details. <Sigh>.)
The GCC back-end support in the Mercury compiler is not included in most
of our binary distributions; they still compile via C. The main reason
for this is that including this support in the mercury_compile executable
would slow it down a little, even for those users who do not use it.
This occurs because the GCC back-end library has a considerable amount of
static data (about 400k, IIRC), and the Boehm conservative collector
scans this data at each collection. Compilation speed is a significant
concern for us, because the Mercury compiler is already much too slow.
The code generated by the Mercury compiler's GCC back-end interface is
still considerably less efficient than that generated by compiling via
C for some benchmarks, because when compiling via C we can inline C code
used for various primitives in the Mercury standard library, but this
can't be done when compiling directly to assembler via the GCC back-end.
It would be possible for the Mercury GCC front-end to recognize these
routines and generate appropriate GCC trees for them, but this has not
been done due to lack of development resources -- as well as the
difficulty of initial implementation, doing so would increase the
complexity of the Mercury implementation and would make maintenance
more difficult.
Because of the two reasons above, the Mercury compiler back-ends which
compile via C get a lot more attention than the one which interfaces
directly with GCC. So it would help a lot to have a tail call annotation
in C (i.e. GNU C syntax to access the GCC back-end hook implemented in the
above-mentioned patch).
Andreas Bauer recently finished his PhD, and is planning to work on the
tail call stuff in GCC again soon.
> Seems
> like the code I looked at would work out much nicer if each of those
> pieces were a separate function for which we tail called to the next.
> That would let you use eax, edx, ecx as well, since you'd be able to
> pass them as parameters from one function to the next (via regparm(3)).
> And since they'd be parameters, they'd get copied to pseudos at function
> entry and thense register allocated.
regparm(3) prevents tail call optimization of calls via function pointers,
since there may be no spare caller-save registers to hold the function pointer.
So we can only use regparm(2).
The Mercury compiler has support for using regparm(2) in the new back-end,
but currently this is not enabled by default, because it doesn't work with
gcc 2.95 due to bugs in that version, IIRC. Even if the user has gcc 3,
we still don't enable it by default, to keep binary compatibility
with Mercury code compiled using gcc 2.95. We'll change that when
most of our users have upgrade to gcc 3... but given the issues with
compile times in gcc 3, that might be a long time coming.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.