[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

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:

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?