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

[Zdenek Dvorak]

Hi,

> > 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.

well... in what sense?  Returning TREE_INVARIANT seems wrong, as any
number of things may be TREE_INVARIANT.

> > 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?

You would have to rewrite all the uses of is_gimple_min_invariant in
middle-end to some such predicate (because as far as I can tell, all the
uses of is_gimple_min_invariant in middle-end have this different
meaning).  Also, you would have to rewrite all the uses of is_gimple_val
in middle end, as it uses is_gimple_min_invariant.  All in all, it seems
simpler to make is_gimple_min_invariant behave the way most of people
think it does,

Zdenek