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] |

*From*: "Daniel Berlin" <dberlin at dberlin dot org>*To*: "Eric Botcazou" <ebotcazou at adacore dot com>*Cc*: "Richard Guenther" <richard dot guenther at gmail dot com>, gcc at gcc dot gnu dot org*Date*: Wed, 4 Jul 2007 18:51:12 -0400*Subject*: Re: About the is_gimple_min_invariant predicate*References*: <200707041129.01890.ebotcazou@adacore.com> <200707041316.34358.ebotcazou@adacore.com> <84fc9c000707040451o6d7bbca9l5f9acfc31117c77d@mail.gmail.com> <200707041428.09951.ebotcazou@adacore.com>

> 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 :)

**Follow-Ups**:**Re: About the is_gimple_min_invariant predicate***From:*Eric Botcazou

**References**:**About the is_gimple_min_invariant predicate***From:*Eric Botcazou

**Re: About the is_gimple_min_invariant predicate***From:*Eric Botcazou

**Re: About the is_gimple_min_invariant predicate***From:*Richard Guenther

**Re: About the is_gimple_min_invariant predicate***From:*Eric Botcazou

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |