Re: TREE_UNCHANGING?

[Jason Merrill <jason at redhat dot com>]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

> On Thu, May 09, 2002 at 11:00:11PM +0100, Jason Merrill wrote:

>> I suppose it might be feasible to model this using a magic alias set that
>> doesn't conflict with alias set 0.  Is that the sort of thing you had in
>> mind?

> Yes.  A set that really Really means "this mem resides in read-only memory".

> Unlike the current RTX_UNCHANGING_P, which perhaps once meant that, but now
> appears to mean something akin to "once we get the thing set up, we won't
> change it until it goes out of scope".

Hmm, that's pretty much what I want to say about the vfield in a class;
it's not in read-only memory, but I assert that any time we look it up it
will always have the same value.

Of course, that's not true until the object is fully constructed, and
inlined constructors could cause trouble.  And have, in my experimentation
with TREE_CONSTANT; g++.rfg/21027_14+.C was misoptimized because I was
assigning multiple times to an UNCHANGING location.  Tweaking things so
that I don't set TREE_CONSTANT if we're in a constructor, it works
properly, but I suspect might have problems in the presence of agressive
scheduling; if the read is marked UNCHANGING and the write isn't, the
current code would not see the dependency.

Hmm.  Perhaps what I want is, rather, to tell the optimizer that the value
will not change behind its back; that the assignments we can see are all
there is.  That it can change, but cannot alias.  Which sounds like pretty
much the same magic alias set.

Jason