On Fri, Aug 09, 2024 at 05:12:00PM +0100, Alex Coplan wrote:
> > > I suppose I was just concerned about any other properties of
> > > ANNOTATE_EXPRs that might be inherited from the operand (that could be
> > > affected by such a change).
> > >
> > > It looks like TREE_{READONLY,THIS_VOLATILE,SIDE_EFFECTS} are all set
> > > in convert_from_reference and propagated by build3, so if those change
> > > underneath us then only updating the type seems insufficient.
> >
> > I think TREE_THIS_VOLATILE isn't, that is only for references.
> > The others could change, but only in the !TREE_SIDE_EFFECTS ->
> > TREE_SIDE_EFFECTS or TREE_READONLY -> !TREE_READONLY direction
> > (the former if it was volatile bool &).
> > So you could also in the loop update it just in case,
> > TREE_SIDE_EFFECTS (c) |= TREE_SIDE_EFFECTS (*condp);
> > TREE_READONLY (c) &= TREE_READONLY (*condp);
>
> Any reason not to just update those unconditionally? I.e. just make
> those normal assignments? I'm assuming we'll only run the loop at all
> in the case that TREE_TYPE (*condp) != TREE_TYPE (cond).
ANNOTATE_EXPR has 3 arguments, not one, and the flags are dependent on all
of them. If you look at the build3 construction of those flags,
TREE_SIDE_EFFECTS is ored from all the operands while TREE_READONLY is only
set if all the operands are.
Jakub
