<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 13, 2017 at 6:27 PM Easwaran Raman 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, this looks broken in the new PM. The DevirtSCCRepeatedPass::run method first scans the functions in the SCC to collect value handles for indirect calls, runs the CGSCC pass pipeline and then checks if any of the call value handles now point to a direct call, in which case it runs the pipeline again (which should inline the devirtualized call) . The problem is scanning the initial SCC for indirect calls is not enough since inlining can produce indirect calls (which could then get devirtualized by later passes). One (ugly) fix is to pass the value handles to the inliner through CGSCCUpdateResult and let the inliner augment it as the caller gets indirect calls due to inlining.</div></blockquote><div><br></div><div>Yeah, this is a frustrating tradeoff....</div><div><br></div><div>The new PM's approach here is dramatically simpler, but can't handle certain edge cases. I'm not sure how much complexity it is worth adding here.</div><div><br></div><div>The other way to address this is to not try so hard to exactly match the old PM's behavior. Instead of trying to detect when an indirect call is turned into a direct call, we could do something more like iterating to a fixed-point, or at least a fixed point of inlining. This is even simpler than the current approach and also more robust (it would handle cases like you describe).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 12:20 PM, Fedor Sergeev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 12/07/2017 11:09 PM, Fedor Sergeev via llvm-dev wrote:<br>
> Chandler et al,<br>
><br>
> I have been playing with the new PM pipeline, being particularly interested in how it can handle devirtualization.<br>
> Now, I discovered what I believe is a "regression" vs old PM on a rather simple one-translation-unit testcase.<br>
><br>
> clang is able to devirtualize it with -O3 and fails to do so with -fexperimental-new-pass-manager added.<br>
<br></span>
I hate to correct myself ;) yet it is able to devirtualize (that is GVN does its job) though it does fail to perform<br>
a rather expected inline afterwards.<br>
<br>
regards,<br>
Fedor.<div class="m_7742765524802934477HOEnZb"><div class="m_7742765524802934477h5"><br>
<br>
<br>
><br>
> It looks like a pipeline issue, though I did not dig deeper as I'm not sure if this kind of behavior<br>
> is expected at current stage of New PM life or not?<br>
><br>
> If it is not expected then I'ld be happy to file a bug and do a bit deeper look for the cause.<br>
><br>
> regards,<br>
> Fedor.<br>
> -------------------------------<br>
> ] cat devirt.cpp<br>
> struct A {<br>
> virtual int virt1();<br>
> };<br>
> struct B : A {<br>
> int virt1() override {<br>
> return 20;<br>
> }<br>
> };<br>
> static int redirect(A* a) {<br>
> return a->virt1();<br>
> }<br>
> int calc() {<br>
> B b;<br>
> return redirect(&b);<br>
> }<br>
> ] clang++ -O3 devirt.cpp -std=c++11 -S -emit-llvm -o -<br>
> ...<br>
> define i32 @_Z4calcv() local_unnamed_addr #0 {<br>
> entry:<br>
> ret i32 20 <--- nicely devirtualized (&b)->virt1() call<br>
> }<br>
> ...<br>
> ] clang++ -O3 -fexperimental-new-pass-manager -std=c++11 -S -emit-llvm -o -<br>
> ...<br>
> define i32 @_Z4calcv() local_unnamed_addr #0 {<br>
> entry:<br>
> %b = alloca %struct.B, align 8<br>
> %0 = bitcast %struct.B* %b to i8*<br>
> call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0) #3<br>
> %1 = getelementptr inbounds %struct.B, %struct.B* %b, i64 0, i32 0, i32 0<br>
> store i32 (...)** bitcast (i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }* @_ZTV1B, i64 0, inrange i32 0, i64 2) to i32 (...)**), i32 (...)*** %1, align 8, !tbaa !2<br>
> %call.i = call i32 @_ZN1B5virt1Ev(%struct.B* nonnull %b)<br>
> call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %0) #3<br>
> ret i32 %call.i<br>
> }<br>
> ...<br>
> ] clang++ --version<br>
> clang version 6.0.0 (trunk 319748) (llvm/trunk 319768)<br>
> Target: x86_64-unknown-linux-gnu<br>
> Thread model: posix<br>
><br>
><br>
> _______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>