This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Optimize tail calls not in the final block
- From: Richard Henderson <rth at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 24 Oct 2003 17:33:26 -0700
- Subject: Re: [tree-ssa] Optimize tail calls not in the final block
- References: <20031022213036.GA29762@atrey.karlin.mff.cuni.cz>
On Wed, Oct 22, 2003 at 11:30:36PM +0200, Zdenek Dvorak wrote:
> this patch enables the tail recursion optimization to handle calls that
> are not in a basic block that directly precedes exit, e. g.
>
> void yyy(int a, int b)
> {
> if (a < b)
> yyy (b, a);
> else
> foo (a, b);
> }
We handle this example without this new patch. I'm guessing
that you had something else in mind.
> * tree-cfg.c (first_real_stmt): New.
> * tree-flow.h (first_real_stmt): Declare.
> * tree-tailcall.c (bb_optimize_tail_calls, find_tail_call_p,
> eliminate_tail_call): Optimize tail calls not in the exit predecessor.
I can't quite follow what you're trying to do here. I see
forward and backward searching all within the same function
all within a single while loop.
I'd expect something like this to be written to search on
the post dominator graph. It should be trivial to use existing
bits to compute then walk this graph.
Functions are good. Mashing all this into a single function
makes it unnecessarily difficult to follow what's going on.
Does all of this become unnecessary given a good jump threader?
If these paths really do lead to exit, why wouldn't they be
direct ancestors of the exit block?
r~