On 16/08/2024 12:47, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 11:38:03AM +0100, Alex Coplan wrote:
> > Looking at the calls to build3 (ANNOTATE_EXPR, ...) in cp/semantics.cc,
> > it looks like the other two operands of ANNOTATE_EXPRs are only ever
> > INTEGER_CSTs (the code in tree-cfg.cc:replace_loop_annotate_in_block
> > corroborates this).
>
> As long as we don't add new ANNOTATE_EXPR kinds with non-constant arguments,
> but we don't have them right now.
>
> > I think an INTEGER_CST C will always have:
> >
> > TREE_SIDE_EFFECTS (C) = TREE_READONLY (C) = 0
>
> That is true.
> >
> > and since the TREE_READONLY flags are conjunctive and TREE_SIDE_EFFECTS
> > flags are disjunctive, for an ANNOTATE_EXPR A we will necessarily have:
> >
> > - TREE_READONLY (A) = 0
>
> No. The TREE_READONLY computation is:
> read_only = 1;
> ...
> if (!TREE_READONLY (arg##N) \
> && !CONSTANT_CLASS_P (arg##N)) \
> (void) (read_only = 0); \
> While INTEGER_CST isn't TREE_READONLY, it is CONSTANT_CLASS_P.
>
> > - TREE_SIDE_EFFECTS (A) = TREE_SIDE_EFFECTS (TREE_OPERAND (A, 0))
>
> So, unless we add non-INTEGER_CST extra arguments to ANNOTATE_EXPR,
> TREE_READONLY (A) = TREE_READONLY (TREE_OPERAND (A, 0))
> || CONSTANT_CLASS_P (TREE_OPERAND (A, 0));
Ah, right. I was going off memory of what we discussed so far and didn't look
at what PROCESS_ARG actually does. Thanks.
In any case, this avoids the need for the checking in the change of
direction of the flags (although perhaps pushes the problem elsewhere in
that now we arguably need to check that operands 1 and 2 of each
ANNOTATE_EXPR is an INTEGER_CST, unless we want to just rely on that
assumption unchecked).
> Not really sure if the first argument will ever be say INTEGER_CST,
> #pragma GCC unroll 8
> while (1)
> {
> if (something)
> break;
> }
> ?
>
> Jakub
>
