------- Additional Comments From joseph at codesourcery dot com 2005-05-16
20:28 -------
Subject: Re: [4.0/4.1 Regression] ICE in
make_decl_rtl
On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:
>
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
> 20:03 -------
> (In reply to comment #3)
> > If you get rid of decl_constant_value_for_broken_optimization then I
> > suspect you'll lose some optimizations because fold doesn't operate on SSA
> > so some constant values won't be available to fold, only to later
> > optimizations. But you'll get rid of the only references to "optimize" in
> > the C front end other than those defining built-in macros, and the
> > front-end shouldn't care about "optimize" in principle, and you'll
> > probably get rid of some XFAILs in c9?-const-expr-?.c in the process.
>
> Why do you believe fold does not operate on SSA?
Fold has optimizations working on large complicated trees of expressions,
looking at their subexpressions and subsubexpressions; such trees are only
available during parsing, before conversion to GIMPLE form. If the
constants aren't available in these non-GIMPLE trees then you lose the
optimizations. The folding called from the SSA optimizers can only fold
smaller fragments of trees. Everything fold does which looks at
subexpressions and subsubexpressions of non-GIMPLE trees can in principle
be done on GIMPLE but I don't think there's evidence that every such fold
optimization is implemented for GIMPLE.
Here is a trivial example where the transformation ~A + 1 to -A is only
done by the RTL optimizers in function g but is done by fold for function
f.
int f(int a) { return ~a + 1; }
int g(int a) { int b = 1; return ~a + b; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21610
