Re: [Committed] PR26557: Handle const_int in emit_case_nodes

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 13 Mar 2006, Andrew Pinski wrote:
> > The second of the two fixes mentioned above follows the "why fix it
> > once" idiom, by teaching fold-const.c/fold_stmt that dereferencing
> > constant initialized arrays with a constant index returns a constant
> > result.  This should allow the constant index in the test case below
> > to be seen by the tree-ssa optimizers.  Unfortunately, this second
> > change is significantly more intrusive, and probably not appropriate
> > for the 4.0 and 4.1 release branches.
>
> Store CCP already does this optimization which is why at -O2 the ICE
> does not show up.  Now one could argue that Store CCP should also be
> turned on at -O1 (which I think is a good thing).

My plan was to move the code that performed this from expr.c's
expand_expr_real_1's ARRAY_REF handling to fold-const.c's
fold_read_from_constant_string.  Not only does expand_expr itself
already call fold_read_from_constant_string, but its also called from
fold_stmt.  This rationalization should also allow us to eventually
handle "const double x = 3.14159; return ((char*)&x)[2];" without code
duplication once I finish the target layout version/implementation of
my VIEW_CONVERT_EXPR folding patch.

I'm not sure if we're guaranteed to call fold_stmt on every statement
at -O1, but it might be reasonable to do this in the gimplifier as
fold_stmt can perform more transformations than fold?  It should also
be cheaper than relying on store CCP which may legitimately be turned
off at low optimization levels.

Thoughts?

Roger
--