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));
Not really sure if the first argument will ever be say INTEGER_CST,
#pragma GCC unroll 8
while (1)
{
if (something)
break;
}
?
Jakub
