[LLVMdev] Missed devirtualization opportunities

John McCall rjmccall at apple.com
Tue Oct 12 10:32:39 PDT 2010


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

I should clarify my last response to say that copies of a pointer point
to the same object.  When a new object is created at that storage, all
the old pointers may or may not forward;  only the result of the
new-expression actually automatically points to the new object.
But we probably shouldn't rewrite invalid uses of stale pointers to
unreachable just because we can. :)

> 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!)

I'm not sure why we would.  Any workable approach based on invariant
ranges will need to allow open ranges.

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

Nothing this sophisticated.

John.



More information about the llvm-dev mailing list