[LLVMdev] Clang devirtualization proposal (original) (raw)

Philip Reames listmail at philipreames.com
Fri Jul 31 17:03:14 PDT 2015

On 07/31/2015 04:05 PM, Piotr Padlewski wrote:

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: Quoting from the google doc: "If we don’t know definition of some function, we assume that it will not call @llvm.invariant.group.barrier()." This part really really bugs me. We generally try to assume minimal knowledge of external functions (i.e. they can do anything) and this assumption would invert that. Is there a way we can rephrase the proposal which avoids the need for this? I'm not quite clear what this assumption buys us. This is because without it the optimization will be useless. For example: A* a = new A; a->foo(); //outline virtual a->foo(); If we will assume that foo calls @llvm.invariant.barrier, then we will not be able to optimize the second call. Why not? If foo calls @llvm.invariant.group.barrier, then it would have to produce a new SSA value to accomplish anything which might effect the second call. Given the call is on "a", not some return value from foo or a global variable, we know that any SSA value created inside foo isn't relevant. We should end up a with two loads of the vtable using the same SSA value and the same invariant.group metadata. The later can be forwarded from the former without issue right?

%a = ...; %vtable1 = load %a + Y !invariant.group !0 %foo1 = load %vtable1 + X, !invariant.group !1 call %foo1(%a) %vtable2 = load %a + Y !invariant.group !0 <-- Per state rules, this value forwards from previous vtable load %foo2 = load %vtable2 + X, !invariant.group !1 call %foo2(%a)

Philip

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/e35aa01c/attachment.html>

More information about the llvm-dev mailing list