[tree-ssa] Work around for an unfortunate fold-const vs. tree-optimizer interaction

Zack Weinberg zack@codesourcery.com
Thu Nov 6 21:05:00 GMT 2003


Roger Sayle <roger@eyesopen.com> writes:

> From the middle-end perspective, its reasonable to disable many of
> the problematic transformations during the tree-ssa passes, as long
> as they are available to front-ends during parsing and then again
> during RTL expansion.  We don't really need a tree-peephole pass as
> the RTL expanders for problematic nodes, could call fold themselves.
> A good example is optimizations that introduce new SAVE_EXPR nodes,
> which can/should/must be disabled during the tree-ssa passes.
>
> Indeed the only remaining reason for the duplication between fold_builtin
> (and all of its fold_builtin_foo children) and simplify_builtin (and all
> simplify_builtin_foo children) is that fold_builtin_cabs may introduce
> new SAVE_EXPRs to evaluate "sqrt(x*x + y*y)".  If the tree-ssa branch
> or the corresponding front-ends could signal which phase of compilation
> they were in, we can avoid introducing SAVE_EXPRs, BITFIELD_REFs, etc...
> expand_builtin_cabs can call fold_builtin_cabs to recapture this
> optimization.
>
> If someone could provide a patch to introduce this global variable
> and set it appropriately in toplev.c, I'd be happy to make the
> corresponding changes to fold and friends.

This all feels like a step in the wrong direction.  I thought the idea
was to stay in GIMPLE form all the way to tree->RTL conversion, and
simplify the RTL expanders based on the assumption that they received
only GIMPLE form.  SAVE_EXPR in particular I thought was slated for
total elimination.

Now it sounds like you're backing away from that concept and the
promise of being able to have a straightforward tree->RTL lowering
pass instead of the current mess.

zw



More information about the Gcc-patches mailing list