<div dir="ltr">Pretty sure the inlined version works because the frontend devirtualizes (since the concrete type is known without any analysis) - once that's not possible, the single call (or probably any non-looping chain of calls) can be devirtualized until a non-inline virtual call is hit - at that point the compiler can't see that the vtable pointer hasn't changed (this is a limitation of LLVM, not a limitation of C++ in general - C++ in general guarantees that the vtable pointer won't change over a virtual call - but it doesn't guarantee that it won't change at all (you can placement delete, placement new some other object, then reverse that before the function returns and that's valid)).<br><br>For example: <a href="https://godbolt.org/z/8zrhx8">https://godbolt.org/z/8zrhx8</a> - two calls to 'test' if 'sub::method' is not defined in this translation unit: First is devirtualized because the ctor is inline and the vtable pointer is seen from that, but then the compiler assumes the vtable pointer might've been modified by that call, so the second call is not devirtualized. If you make the ctor non-inline, you'll see both are indirect/not devirtualized.<br><br>The loop presents the general case of this problem - can't provide an inductive proof that every call will result in the same vtable pointer, so have to err on the side of caution.<br><br>I think tehre's an old bug kicking around somewhere that boils down to "make we could use the llvm.assume intrinsic after every virtual call, to assert that the vtable pointer is the same before and after the call" but not sure what state that bug is in/how practical that strategy would be.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 3, 2020 at 6:12 PM Sameer Abu Asal via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Hi, <br><br>I came across this case that shows a bad  case for  de-virtualizeation<br>
<br>
<a href="https://godbolt.org/z/e7r6a8" target="_blank">https://godbolt.org/z/e7r6a8</a><br>
<br>
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. <br><br>You can recreate the output for inst-combine with:<br>
<br>
<pre><code>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</code><br><code>rt.ll |& tee /tmp/log.bad</code><br><br><code>clang++ -mllvm -print-after-all -mllvm -filter-print-funcs=_Z11devirt_goodv -S -O3 -emit-llvm ./test_devirt.cpp -mllvm -debug-only=instcombine -o ./test</code><br><code>_devirt.ll |& tee /tmp/log.good</code><br></pre>
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?<br></div><div><br></div><div>Thank you,</div><br clear="all"><div><div dir="ltr"><div dir="ltr">--Sameer<br><br></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>