[cfe-dev] [LLVMdev] Clang devirtualization proposal

[Reid Kleckner]

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/cfe-dev/attachments/20150731/12abb266/attachment.html>