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.

Yes. We actually use it to catch constants. As does every other user i think.


Note that TREE_INVARIANT is not going to be useful in an IPA world
anyway for these users, if it really means that different calls to the
function could produce different results.
(Because it will mean it's not "constant enough" to rematerialize
wherever we want, only wherever we want *inside that function*)


> 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


It originally was such a formal predicate. Whether it is anymore is a good question :)

/* 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


This would make sense to me. Again, the fact that it catches things *other* than true constants is just by accident to most users. They certainly don't expect it :)

I'm also not surprised your force_gimple_operand didn't work, since we
call force_gimple_operand on the expressions we produce already  :)


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