This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Optimize tail calls not in the final block


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]