This is the mail archive of the gcc@gcc.gnu.org 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]

Re: TREE_UNCHANGING?


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

> On Fri, May 10, 2002 at 12:18:22PM +0100, Jason Merrill wrote:
>> It seems that restrict provides this sort of guarantee; in this testcase,
>> can the compiler avoid doing two loads from *p?
>> 
>> int i;
>> void f ();
>> void g (int *__restrict p)
>> {
>>   int j = *p;
>>   f ();
>>   j += *p;
>>   i = j;
>> }

> At the moment, I think not, but is that test case really going to help
> you at all with vtables?  Cause I would think the most common form would
> include passing the THIS pointer to the function, so you wind up with
> "f(p)" which means that the function _can_ name p, which means that it
> can modify the contents.

> Incidentally, your patch is broken for exactly this reason.  You'd need
> to be able to follow data flow to know which restricted pointers leak
> into each function call so that those function calls can clobber the
> accessible memory.

You're right, my patch is inadequate for actual restricted pointers; I was
misreading the text about based expressions.

For vtable pointer handling, it's just as well, as a called function won't
modify it.  The only things that modify vtable pointers are constructors
and destructors; if they are inlined, they will be available to the
optimizer, and if they aren't, they should bracket any uses.

But then, I suppose there wouldn't then be anything preventing us from
moving the vptr load before the constructor call; I guess such calls should
clobber the vptr alias set.

>...
> This seems dangerous.  Alias set zero is also the "oops, our 
> legacy optimizer lost track of what we were doing".

Also a good point, but I think not a problem for the vptr case, where all
MEMs for a vtable pointer are immediately used.

Jason


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