[cfe-dev] [LLVMdev] Clang devirtualization proposal

Sanjoy Das sanjoy at playingwithpointers.com
Fri Jul 31 17:14:12 PDT 2015


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
>




More information about the cfe-dev mailing list