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*: "Richard Guenther" <richard dot guenther at gmail dot com>*To*: "Eric Botcazou" <ebotcazou at adacore dot com>*Cc*: gcc at gcc dot gnu dot org*Date*: Wed, 4 Jul 2007 14:43:55 +0200*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.

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

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