Re: About the is_gimple_min_invariant predicate

[Diego Novillo <dnovillo at google dot com>]

On 7/4/07 5:29 AM, Eric Botcazou wrote:

>   /* Make sure result is not a complex expression consiting
>      of operators of operators (IE (a + b) + (a + c))
>      Otherwise, we will end up with unbounded expressions if
>      fold does anything at all.  */
>   if (result)
>     {
>       if (is_gimple_min_invariant (result))
> 	return result;
> 
> The expression
> 
> &p__name_buffer[(<unnamed-signed:32>) MAX_EXPR <D.738_31, 0> + 1]
> 
> is_gimple_min_invariant because it is TREE_INVARIANT.  TREE_INVARIANT is 
> correct because the semantics of Ada for IN parameters guarantees that the 
> index is TREE_INVARIANT and p__name_buffer is a global variable.

The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
value for ADDR_EXPRs.  We still require a TREE_CONSTANT as an array
index.  So,  ARRAY[TREE_INVARIANT] is not valid GIMPLE.

FRE should refuse to substitute a TREE_INVARIANT expression as an
ARRAY_REF index.


> I think that the head comment is a little confusing: is it a formal predicate 
> of the GIMPLE grammar, as most of its uses would suggest, e.g.

It is a formal predicate of the GIMPLE grammar.  But there is an
inconsistency now.  I don't think we want to allow min-invariant as
ARRAY_REF indexes because this would allow things like

	&a[&b[3]]

which is too gross for words.  So, the grammar should be updated to
include invariant addresses in 'val', but it should have a new rule so
that no invariant addresses are allowed as array indices.