About the is_gimple_min_invariant predicate

Richard Guenther richard.guenther@gmail.com
Wed Jul 4 12:44:00 GMT 2007


On 7/4/07, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > 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

Sure, but CONST isn't specified.  Simply restricting it to "real"
constants might
pessimize optimization (though it also simplifies code to not having
to special case
non-constants).  While I would not be against this chage it requires
some performance
testing.

Richard.



More information about the Gcc mailing list