[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [LLVMdev] Clang devirtualization proposal
From:       Sanjoy Das <sanjoy () playingwithpointers ! com>
Date:       2015-08-01 0:14:12
Message-ID: CAMiUf7dpXNKC56PLMCxe-E2F5fgXwcN3Es24+LV9ze1z7xpCxg () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jul 31, 2015 at 4:05 PM, Piotr Padlewski <prazek@google.com> wrote:
>
>
> On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail@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@cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

[prev in list] [next in list] [prev in thread] [next in thread]