[LLVMdev] Clang devirtualization proposal
prazek at google.com
Sat Aug 1 09:08:07 PDT 2015
oh I see. Yep, my mistake.
On Fri, Jul 31, 2015 at 5:03 PM, Philip Reames <listmail at philipreames.com>
> 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>
>> 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
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev