[PATCH] Fix PR35607, another revenge of invariant addresses (ivopts)

[Richard Guenther]

On Mon, 17 Mar 2008, Eric Botcazou wrote:

> > IMHO there are two possible ways to solve these problems:
> >
> > 1) something like the patch below (up to details of
> >    address_invariant_p, this is just a quick hack).
> 
> It's roughly equivalent to what I proposed here:
>   http://gcc.gnu.org/ml/gcc/2007-07/msg00093.html
> but I'm not convinced it's the correct approach because IIUC 
> is_gimple_min_invariant does its job correctly.
> 
> > 2) making TREE_INVARIANT behave equivalently to this patch after
> >    gimplification (or introducing a new tree flag with this altered
> >    semantics)
> >
> > 2) seems complicated and possibly causing further problems, so I would
> > propose to go with 1), unless there are compile-time performance
> > problems due to this change.
> >
> > I tried to understand Diego's proposal
> > (http://gcc.gnu.org/ml/gcc/2007-07/msg00097.html), however it seems to
> > propose to keep relying on TREE_INVARIANT with its current semantics,
> > which seems wrong -- I think middle-end should not use TREE_INVARIANT at
> > all, as it is more or less redundant with SSA form,
> 
> I'd agree with this, TREE_INVARIANT should not be relied upon here, but why 
> can't this problem be also solved by invoking the correct predicate in 
> expand_simple_operations?  E.g. tree-ssa-ccp.c:ccp_decl_initial_min_invariant 
> or tree-ssa-propagate.c:valid_gimple_expression_p?

Not really if you rely on re-gimplification anyway, as the gimplifier
does not gimplify anything in &a[(int)u_2] if that is invariant as
of the is_gimple_min_invariant predicate.

But - if that would work (and so passes that don't expect to
produce gimple), then simple propagators can of course use
more complicated predicates to tell if a result is valid (and they
do not want to re-gimplify).

I'll have a look at the gimplification problem later but also agree
that we should _not_ use TREE_INVARIANT (at least not in the way
it is set by frontends) and its lazy updating mechanism
(recompute_invariant_for_addr_expr).

Richard.