> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization passes
> that treat is_gimple_min_invariant() values as "as cheap as constants",
> which in this case surely is not true.
Yes, is_gimple_min_invariant seems to be mostly used for this purpose.
> So maybe you can try reworking is_gimple_min_invariant to restrict this
> case to where the address computation is indeed as cheap as a constant or
> register value?
I think that you're implicitly assuming that is_gimple_min_invariant is not a
formal predicate of the GIMPLE grammar, which I agree is an interpretation of
the sparse documentation. The other one is that is_gimple_min_invariant is a
formal predicate of the GIMPLE grammar, for example because it is invoked in
/* Return true if T is a GIMPLE rvalue, i.e. an identifier or a constant. */
bool
is_gimple_val (tree t)
{
/* Make loads from volatiles and memory vars explicit. */
if (is_gimple_variable (t)
&& is_gimple_reg_type (TREE_TYPE (t))
&& !is_gimple_reg (t))
return false;
/* FIXME make these decls. That can happen only when we expose the
entire landing-pad construct at the tree level. */
if (TREE_CODE (t) == EXC_PTR_EXPR || TREE_CODE (t) == FILTER_EXPR)
return true;
return (is_gimple_variable (t) || is_gimple_min_invariant (t));
}
and is_gimple_val is a formal predicate IIUC. In this latter case, we
wouldn't have much leeway and is_gimple_min_invariant should simply
implement the GIMPLE grammar, i.e the CONST in
val : ID
| CONST
--
Eric Botcazou
