[llvm-dev] Why can't we devirtulize this?

[Hiroshi Yamauchi via llvm-dev]

Not adding much, but I see that there's the sub::method call outside of the
loop (loop peeling?) that is devirtualized but not inlined. If the peeling
doesn't happen or that can be inlined somehow, it should probably work out
for this particular case.

On Tue, Nov 3, 2020 at 7:36 PM Hubert Tong via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Try -fstrict-vtable-pointers: https://godbolt.org/z/hfTe6e
>
> -- HT
>
> On Tue, Nov 3, 2020 at 9:12 PM Sameer Abu Asal via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> Hi,
>>
>> I came across this case that shows a bad case for de-virtualizeation
>>
>> https://godbolt.org/z/e7r6a8
>>
>> If you have a call to a virtual function inside of a Loop, llvm is unable
>> to de-virt the call simply with Instr Combine. However, for the case where
>> we put the virtual call inside a loop.
>>
>> You can recreate the output for inst-combine with:
>>
>> clang++ -mllvm -print-after-all -mllvm -filter-print-funcs=_Z10devirt_badm -S -O3 -emit-llvm ./test_devirt.cpp -mllvm -debug-only=instcombine -o ./test_devi
>> rt.ll |& tee /tmp/log.bad
>>
>> clang++ -mllvm -print-after-all -mllvm -filter-print-funcs=_Z11devirt_goodv -S -O3 -emit-llvm ./test_devirt.cpp -mllvm -debug-only=instcombine -o ./test
>> _devirt.ll |& tee /tmp/log.good
>>
>> It seems to me a problem with Inst combine not being able to hoist the
>> call to get the virtual func pointer outside of the loop, is that right?
>> Can we possibly do better than this?
>>
>> Thank you,
>>
>> --Sameer
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201104/9440c740/attachment.html>