On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <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. Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/680b60f5/attachment.html>
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>
On Fri, Jul 31, 2015 at 4:05 PM, Piotr Padlewski <prazek at google.com> wrote:> > > On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <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.IIUC, given how @llvm.invariant.barrier is specified, you don't have to actually assume that. Since the second load from `a` will be through the same SSA value, it could not have been piped through @llvm.invariant.barrier. OTOH, if you have A *a = new A; a->foo(); bar(&a); a->foo(); Then you'll (rightly) have to forgo optimizing the second call to a->foo(). -- Sanjoy> > > Piotr > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Fri, Jul 31, 2015 at 5:03 PM, Philip Reames <listmail at philipreames.com> wrote:> 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> > 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) >Right, you got the intention of the design. The foo call can placement new into %a if it wants to, but it better put things back the way they were before we return, because %a isn't changing. We probably missed that sentence when reviewing the proposal. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/12abb266/attachment.html>
oh I see. Yep, my mistake. On Fri, Jul 31, 2015 at 5:03 PM, Philip Reames <listmail at philipreames.com> wrote:> > > 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> > 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/20150801/45f9682e/attachment.html>