On Tue, 26 Jan 2021, Jakub Jelinek wrote: > On Tue, Jan 26, 2021 at 12:25:16PM +0100, Richard Biener wrote: > > On Tue, 26 Jan 2021, Jakub Jelinek wrote: > > > > > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote: > > > > > + /* Unless this is called during FE folding. */ > > > > > + if (cfun > > > > > + && (cfun->curr_properties & (PROP_trees | PROP_rtl)) == 0 > > > > > > > > don't you want && (cfun->curr_properties & PROP_trees) != 0? > > > > > > No, PROP_trees is misnamed and it actually means GIMPLE. > > > > Doh. Patch doing s/PROP_trees/PROP_gimple/ pre-approved ;) > > > > > I could use (PROP_gimple_any | PROP_rtl) if that is more readable, > > > PROP_trees stands for: > > > (PROP_gimple_any | PROP_gimple_lcf | PROP_gimple_leh | PROP_gimple_lomp) > > > but I don't think we ever have any of the latter 3 set when > > > PROP_gimple_any > > > is not set. > > > > I think PROP_gimple_any should be removed by the gimple lowering > > pass that sets PROP_gimple_lcf since the docs > > > > #define PROP_gimple_any (1 << 0) /* entire gimple grammar > > */ > > #define PROP_gimple_lcf (1 << 1) /* lowered control flow */ > > > > suggest that PROP_gimple_any means we can have sub-stmts for example? > > > > But anyway, since we don't seem to have a property for GENERIC > > and they are only introduced by gimplification even a > > cfun->curr_properties == 0 would work ... > > > > But yes, PROP_trees | PROP_rtl looks good to me as well. > > > > I guess we should document how those properties work ... (and discover > > we don't use them consistently). > > I guess even safer would be to add PROP_generic and set it initially > and clear it at the start of gimplification, so that already during folding > inside of gimplification we don't look at the DECL_INITIAL.
That's also a good idea. But let's play safe at this point (setting PROP_generic at struct function allocation requires clearing it at the points we introduce functions in the middle-end for example). Richard.
