[tree-ssa] tree-ssa vs. fold

[Diego Novillo]

On Fri, 2003-06-06 at 18:18, Jeff Sturm wrote:
> Here's something I've found while experimenting with Java and GIMPLE.
> 
> I get an ICE compiling OperatorBenchmark.java with -O.  The interesting
> part of this test is:
> 
>     float f1 = 1, f2 = 2;
> 
>     for (int cnt = 10; --cnt > 0;) {
>         f1 *= f2;
>     }
> 
> Analysis: rewrite_stmt calls fold() after discovering the constant
> operands, but fold() doesn't return a GIMPLE tree.  In this case fold()
> wants to reduce (f1 * 2) to (f1 + f1), along with save_expr to evaluate f1
> exactly once.
> 
> A few ideas I had:
> 
> a) Don't bother folding here at all.  This breaks
> gcc.c-torture/execute/950704-1.c and defeats a potentially useful
> optimization.
> 
Agreed.  Not an option.

> b) Fold anyway but mark the tree non-GIMPLE.  I tried TREE_NOT_SIMPLE; it
> fails for obscure reasons.  (Perhaps it is too late to use TREE_NOT_SIMPLE
> within the ssa rewriting pass?)
> 
Yes.  TREE_NOT_GIMPLE is only limited to MD builtins at the moment and
we want to get rid of it eventually.

> c) Fold and re-simplify the tree.  The gimplify interface doesn't help
> here; it exports simplify_function_tree which can only work on whole
> functions, and simplify_stmt/simplify_expr which may only be used while
> gimplify is in progress.
> 
This could be a temporary solution.  Expensive and may need some
backtracking in the SSA renamer to rename the new instructions inserted
prior to the current statement.  I don't like this very much.

> d) Fix fold() not to save_expr.
> 
> Is d) the only real choice?  Am I missing something easy?
> 
IMO d) is the solution.  fold() should be rewritten to generate GIMPLE
code.  In particular, why does it need those SAVE_EXPRs in this case? 
We know that these nodes have no side-effects in GIMPLE.  Maybe it
wouldn't be too hard to avoid emitting SAVE_EXPRs when we know we're
folding GIMPLE code.


Diego.