This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


>>>>> "Jason" == Jason Merrill <> writes:

>>>>> "Richard" == Richard Henderson <> writes:
>> On Wed, May 08, 2002 at 01:56:07PM +0100, Jason Merrill wrote:
>>> It seems that setting TREE_CONSTANT on the INDIRECT_REF does what I want,
>>> thanks to the check in set_mem_attributes; would it make sense to bless
>>> this usage?

>> No.  I want to remove RTX_UNCHANGING_P altogether.

>> You should be able to force-assign a unique alias set to a vtable though.

> I don't think that would help; a call is considered to change arbitrary
> memory.  A unique alias set still conflicts with alias set 0.

It seems that the only loads which aren't considered to conflict with an
unknown_address_altered are loads seen to be from the constant pool.  That
doesn't apply to my situation; this isn't something that can be deduced by
looking at the RTL.  It's a property of the type.

What I'm trying to express is the notion that the vtable pointer of an
object is fixed, so the vtable pointer is a const function of the object
address.  Or rather, it's a const function of the object's static type,
which is a const function of the object address.  Furthermore, the referent
of the vtable pointer, the vtable itself, is constant.

The notion of constancy needs to be expressible at the RTL level.
Currently RTX_UNCHANGING_P provides that; it does seem to be a problematic
feature, but if it is removed it should be replaced with another way of
expressing the same thing.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]