Hi Nathan, > I question if it is better to fold early. As I've said before, I think > the optimizations that fold performs should be turned into a proper SSA > optimization phase% -- that can be repeatedly applied as necessary. In the > front end, folding should not generally be done. I see two needs for > early folding,
I may not be quite answering your question, but I have a comment. Maybe we can have an early fold and a general fold. The former would handle constant expressions for front ends. The latter is a full fledged version but optimized to handle GIMPLE statements. The reasons to optimize the full fledged version to handle GIMPLE statements include 1) We can remove parts of fold handling those cases that never occur in the GIMPLE world. 2) Currently, fold has so many transformations that look into a heavily nested tree, but all of those are useless in the GIMPLE world unless one builds scratch node and passes it to fold. An example of such a transformation would be: (A * C) + (B * C) -> (A + B) * C We would express this in GIMPLE as D = A * C; E = B * C; F = D + E; Given D + E, we can instead have fold chase SSA_NAME_DEF_STMT of D and E so that the above transformation is performed. Whether we want to always chase SSA_NAME_DEF_STMT is another question. Richard Henderson once suggested putting a hook for chasing. In a tree combiner, we may want to limit SSA_NAME_DEF_STMT chasing to the case where the SSA_NAME is used only once. In other situations, we might want to have a more relaxed hook although I cannot come up with a specific example. Kazu Hirata
