[LLVMdev] Missed devirtualization opportunities

[Kenneth Uildriks]

On Mon, Oct 11, 2010 at 12:30 PM, John McCall <rjmccall at apple.com> wrote:
> On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote:
>> 3. The front-end, recognizing that scribbling on an instance's vtbl
>> pointer has undefined results, eliminated the loads of the vtbl
>> pointer and replaced them with @classvtbl.TestVirtual.  This would
>> allow devirtualization within a function at least, but (I think) would
>> do less to allow analysis to spot devirtualization opportunities
>> across functions.  (Although ArgPromotion could arrange to have the
>> vtbl pointer passed in separately, and then inlining and/or partial
>> specialization could be made to see that it's a pointer to a constant
>> and thus add in the IndirectCallBonus)
>
> There are always going to be cases that can only be deduced with
> language knowledge.  We already do some frontend de-virtualization;
> this may just be a missing case.  Can you post your test?
>
> John.
>

I compiled the attached c++ code to bitcode using clang++ -O3, then
ran it through opt -std-compile-opts.  I got a reload of the vtbl
pointer after the printf call.  The compiler is allowed to cache the
vtbl pointer as soon as the object is constructed or passed into a
function, right?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestVirtual.cpp
Type: application/octet-stream
Size: 366 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/46973ee1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestVirtual.h
Type: application/octet-stream
Size: 97 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/46973ee1/attachment-0001.obj>