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