[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

On Tue, Oct 12, 2010 at 7:00 AM, Kenneth Uildriks <kennethuil at gmail.com> 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:
>
> 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?
>

For that matter, when you can find the *last* use of pT, you should be
able to put an llvm.immutable.end marker right after it, right?  Or
have I forgotten something else in the standard? (entirely possible,
it's enormous!)

Do you do any processing of an IR Function after you've compiled it in clang?