This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Steven Bosschner<stevenb at suse dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Thu, 06 Nov 2003 13:05:19 -0800
- Subject: Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction
- References: <Pine.LNX.4.44.0311061149050.12964-100000@www.eyesopen.com>
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