This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
- To: Andi Kleen <freitag at alancoxonachip dot com>
- Subject: Re: forcing tail/sibling call optimization
- From: Jeffrey A Law <law at redhat dot com>
- Date: Mon, 27 Nov 2000 09:26:06 -0700
- cc: gcc at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <oupn1el760c.fsf@pigdrop.muc.suse.de>you write:
> Problem I see with that is diagnostics again: e.g. someone depends on a
> particular call being a tail call and not allocating new storage.
Therein lies the first problem -- programmer dependence on specific
optimizations in the compiler. That's a fundamental mistake.
If you _must_ have tail calls optimized to gotos, then write them that way
or use a language which guarantees tail calls will turn into gotos. If
tail call optimizations are merely convenience, then write them as calls :-)
> With a
> "tail call statement" gcc could easily give a warning or even an error
> when the compiler is not able to satisfy that requirement.
True.
> With the functio
> wide attribute it would be much harder to enforce it. Every call could
> possible be a tail call depending on rather complex, machine dependent rule
True.
> How would you generate the "not a tail call" warning without getting lots
> of false positives? With an explicit statement it is clear what to do.
I don't think there really is a way. Nor do I think we should spend a lot
of time worrying about it :-)
jeff