This is the mail archive of the
mailing list for the GCC project.
>>>>> "Richard" == Richard Henderson <firstname.lastname@example.org> 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.