[tree-ssa] tree-ssa vs. fold
Jeff Sturm
jsturm@one-point.com
Fri Jun 6 22:18:00 GMT 2003
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
More information about the Gcc
mailing list