This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimization for walk_tree
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: [PATCH] Optimization for walk_tree
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 21 Jun 2000 10:48:13 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <20000621185027.J474@sunsite.ms.mff.cuni.cz>you write:
> On Wed, Jun 21, 2000 at 09:53:25AM -0600, Jeffrey A Law wrote:
> >
> > In message <20000621152315.D474@sunsite.ms.mff.cuni.cz>you write:
> > > Hi!
> > >
> > > gcc does not recognize
> > > int foo(void)
> > > {
> > > int r;
> > > do {
> > > r = foo(void);
> > > if (r) return r;
> > > } while (0);
> > > return 0;
> > > }
> > Well, in function-at-a-time mode we might be able to detect that the loop
> > iterates exactly once (and thus isn't a loop). That in turn would allow
> for
> > the possibility of a tail call optimization.
>
> I think the if (r) return r; ... return 0; is what prevents the tail recurs
> ion,
> not the loop.
Anytime we're in a loop nest we disable tail call optimizations since no call
in the loop could ever be a tail call.
That probably isn't strictly necessary anymore since we use the cfg to find
calls which pass control to the exit block immediately after they return.
Yes, the if (r) return r; may be problematical too, but the first thing I
saw when I looked at the code was the loop.
jeff