[LLVMdev] Missed devirtualization opportunities

[John McCall]

On Oct 12, 2010, at 5:00 AM, Kenneth Uildriks wrote:
> On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote:
>> On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote:
>>> A better way for a front-end to declare that vtbl-ptr-hacking is not
>>> expected and not supported is for it to emit llvm.invariant.start and
>>> llvm.invariant.end calls for it.
>> 
>> Some of us were talking about this apropos your earlier post.
>> @llvm.invariant.start/end aren't appropriate, because the memory *isn't*
>> invariant;  the user is totally allowed to destruct the object in-place and
>> create a new object there.  The only thing the standard tells us is that
>> old references and pointers are only considered to be automatically
>> "forwarded" to the new object (i.e. aren't just invalid) if the types match.
>> So we're allowed to assume that a pointer or reference validly formed
>> to an object of dynamic type T will always refer to an object of that
>> dynamic type.
> 
> So does that mean that we're allowed to assume that, given an "old"
> pointer to that memory, the vtbl-ptr slot hasn't changed?  Which
> allows us to devirtualize:

Yes, and also (POD) const member variables.

> Base* pT = GetMyObjectThatHappensToBeT();
> // ...
> // stuff that we can't tell what it does to our memory
> // ...
> pT->A();
> // more mysterious stuff
> pT->B();
> // etc.
> 
> as long as we can tell that a given pointer is actually pT and not
> another pointer copied from it or aliased to it?

Right, which is another reason I'm skeptical of (the current design of)
the invariant intrinsics;  I think using them will make the analysis
much harder.  But they have other benefits.

John.