This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About the is_gimple_min_invariant predicate


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]