[tree-ssa] tree-ssa vs. fold

[Jeff Sturm <jsturm at one-point dot com>]

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.

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?)

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.

d) Fix fold() not to save_expr.

Is d) the only real choice?  Am I missing something easy?

Jeff