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

["Diego Novillo" <dnovillo at google dot com>]

On Mon, Mar 17, 2008 at 08:40, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:

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

Yes.  When this issue came up last year, I proposed implementing
is_gimple_min_invariant in terms of a new is_gimple_const() and
TREE_INVARIANT.  I was wrong about relying on TREE_INVARIANT, but we
do want to distinguish const vs invariantness for things like &a[XXX].
 In that context, we want XXX to be const, to avoid things like
&a[&b].

So, we have:

bool
is_gimple_invariant (const_tree t)
{
  if (TREE_CODE (t) == ADDR_EXPR)
     return address_invariant_p (t);
  else
     return is_gimple_const (t);
}

And is_gimple_const() is the same is_gimple_min_invariant() we have
today minus ADDR_EXPR handling.

Thoughts?


Diego.