[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