llvm dev - Aug 2016 - invariant.load metadata semantics

On 8/30/2016 4:53 PM, Sanjoy Das via llvm-dev wrote:
> This seems fine, but it does disallow introduction of dead stores.
> That is, given:
>
> void f() {
>   %x = calloc()
>   call void @g(nocapture %x)
> }
>
> we cannot transform it to
>
> void f() {
>   %x = calloc()
>   *(%x) = 100
>   *(%x) = 0
>   call void @g(nocapture %x)
> }
>
> (after proving that %x is not visible to other threads), since @g
> could have invariant loads from %x.
>
> I don't have a good way of avoiding this issue, but given that the
> transform above does not seem very useful I'm inclined to say the
> definition above is okay for now.
LICM performs precisely this transformation... see "If this is a thread 
local location" etc. in LICM.cpp.  That said, I doubt this case matters; 
nobody is going to use invariant.load on the result of calloc().

-Eli


-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

Hi Eli,

Friedman, Eli wrote:
 > LICM performs precisely this transformation... see "If this is a
thread
 > local location" etc. in LICM.cpp. That said, I doubt this case
matters;
 > nobody is going to use invariant.load on the result of calloc().

IIRC LICM will not introduce a dead store in the way I mentioned
above.  I think it uses thread-locality as an excuse for inserting a
store on every exit of the value that the memory location in question
would have held at that exit (even on exits that didn't have a store),
so it should not _change_ the value held by a location at any point in
the trace of the program.

But this ^ is going off of memory.

-- Sanjoy

On 8/30/2016 5:15 PM, Sanjoy Das wrote:
> Hi Eli,
>
> Friedman, Eli wrote:
> > LICM performs precisely this transformation... see "If this is a
thread
> > local location" etc. in LICM.cpp. That said, I doubt this case
matters;
> > nobody is going to use invariant.load on the result of calloc().
>
> IIRC LICM will not introduce a dead store in the way I mentioned
> above.  I think it uses thread-locality as an excuse for inserting a
> store on every exit of the value that the memory location in question
> would have held at that exit (even on exits that didn't have a store),
> so it should not _change_ the value held by a location at any point in
> the trace of the program.
>
> But this ^ is going off of memory.
>
> -- Sanjoy
Yes, that's right, I think.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project