llvm dev - Aug 2016 - invariant.load metadata semantics

Hi Hal,

Hal Finkel via llvm-dev wrote:
 > Some questions: Do we allow stores to these locations at all? Only if

I'd vote for disallowing stores to these locations, but if "stores
allowed only if the value is the same" is helpful in some situation
then I don't have specific reasons why that would be problematic.

 > the value is the same? Must any change be observable to be a problem? Do

Not sure what you mean by "Must any change be observable".

 > atomic loads of invariant locations really need to be atomic?

It depends on the answer to "Do we allow stores to these locations at
all?".  If we don't allow stores to these locations at all then atomic
loads are not required, since we can't have racing stores to that
location.

However, syntactically, I'd be tempted to allow invariant loads to be
atomic; and maybe have a later pass strip out the atomic bit if the
semantics we decide allow that.

-- Sanjoy

On Thu, Aug 25, 2016 at 4:09 PM, Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Hal,
>
> Hal Finkel via llvm-dev wrote:
> > Some questions: Do we allow stores to these locations at all? Only if
>
> I'd vote for disallowing stores to these locations, but if "stores
> allowed only if the value is the same" is helpful in some situation
> then I don't have specific reasons why that would be problematic.

To be specific, does this imply "if we see a store, we can assume it is of
the same value the load already has"?

IE if i have:

func()
{
load a, invariant.load !1
<use of a>
store a, 5
}

Can i assume that a in  <use of a> has the value 5?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160825/d4aaefc9/attachment.html>

----- Original Message -----
> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, August 25, 2016 6:09:14 PM
> Subject: Re: [llvm-dev] invariant.load metadata semantics
> 
> Hi Hal,
> 
> Hal Finkel via llvm-dev wrote:
>  > Some questions: Do we allow stores to these locations at all? Only
>  > if
> 
> I'd vote for disallowing stores to these locations, but if "stores
> allowed only if the value is the same" is helpful in some situation
> then I don't have specific reasons why that would be problematic.
I would as well; and from what I understand, this is consistent with current use
cases.
> 
>  > the value is the same? Must any change be observable to be a
>  > problem? Do
> 
> Not sure what you mean by "Must any change be observable".
If we allow stores, if we have an invariant load from some location, and then a
store to that location (value arbitrary), is that a problem if the IR being
analyzed never loads from it again? I don't just mean dead stores: just
because the IR in question does not load from it again, that does not mean that
"the system" doesn't.
> 
>  > atomic loads of invariant locations really need to be atomic?
> 
> It depends on the answer to "Do we allow stores to these locations at
> all?".  If we don't allow stores to these locations at all then
> atomic
> loads are not required, since we can't have racing stores to that
> location.
> 
> However, syntactically, I'd be tempted to allow invariant loads to be
> atomic; and maybe have a later pass strip out the atomic bit if the
> semantics we decide allow that.
I agree. We should allow atomic loads to be marked as !invariant.load. We might,
if we decide on semantics that allow it, canonicalize by demoting to a
non-atomic load.

 -Hal
> 
> -- Sanjoy
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Aug 25, 2016 16:09, "Sanjoy Das via llvm-dev" <llvm-dev at
lists.llvm.org>
wrote:

Hi Hal,

Hal Finkel via llvm-dev wrote:
> Some questions: Do we allow stores to these locations at all? Only if
I'd vote for disallowing stores to these locations, but if "stores
allowed only if the value is the same" is helpful in some situation
then I don't have specific reasons why that would be problematic.

I disagree. It's much easier to write fronted and use invariant load when
you can emit stores that store the same value.
For example with invariant.group used on vptrs optimizer can assume the 2
loads load the same vtable, even when you can write code in c++ that is
valid that store vptr after calling virtual function (like placement
new(this) with the same type).

> the value is the same? Must any change be observable to be a problem? Do
Not sure what you mean by "Must any change be observable".

> atomic loads of invariant locations really need to be atomic?
It depends on the answer to "Do we allow stores to these locations at
all?".  If we don't allow stores to these locations at all then atomic
loads are not required, since we can't have racing stores to that
location.

However, syntactically, I'd be tempted to allow invariant loads to be
atomic; and maybe have a later pass strip out the atomic bit if the
semantics we decide allow that.

-- Sanjoy

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160825/50548f41/attachment.html>

Hi Daniel,

Daniel Berlin wrote:
 > To be specific, does this imply "if we see a store, we can assume it
is
 > of the same value the load already has"?
 >
 > IE if i have:
 >
 > func()
 > {
 > load a, invariant.load !1
 > <use of a>
 > store a, 5
 > }
 >
 > Can i assume that a in <use of a> has the value 5?

Yes, that is what I had in mind.  Moreover, in

func()
{
   int k = load a, invariant.load !1
   print(k);
   store a, 5
}

k can be optimized to 5, in a form of "time traveling store
forwarding" :).  The store (at least if non-atomic and non-volatile)
is also trivially dead.

But I'd rather not allow stores at all.

-- Sanjoy

Hi Piotr,

Piotr Padlewski wrote:
 > I disagree. It's much easier to write fronted and use invariant load
 > when you can emit stores that store the same value.
 > For example with invariant.group used on vptrs optimizer can assume the
 > 2 loads load the same vtable, even when you can write code in c++ that
 > is valid that store vptr after calling virtual function (like placement
 > new(this) with the same type).

That's a good point -- I didn't have this use case in mind.

-- Sanjoy

I believe the following is a reasonable attempt at boiling down this 
discussion.  It does allow stores of the same value.  It avoids the dead 
invariant.load issue Sanjoy brought up.  It does not allow final stores 
of a different value, the issue Hal most recently brought up in this thread:

     If a load instruction tagged with the ``!invariant.load`` metadata 
is executed, the optimizer may assume the memory location referenced by 
the load contains the same value at all points in the program where the 
memory location is known to be dereferenceable.

Thoughts?

On 8/25/2016 7:23 PM, Hal Finkel via llvm-dev wrote:
> ----- Original Message -----
>> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Thursday, August 25, 2016 6:09:14 PM
>> Subject: Re: [llvm-dev] invariant.load metadata semantics
>>
>> Hi Hal,
>>
>> Hal Finkel via llvm-dev wrote:
>>   > Some questions: Do we allow stores to these locations at all?
Only
>>   > if
>>
>> I'd vote for disallowing stores to these locations, but if
"stores
>> allowed only if the value is the same" is helpful in some
situation
>> then I don't have specific reasons why that would be problematic.
> I would as well; and from what I understand, this is consistent with
current use cases.
>
>>   > the value is the same? Must any change be observable to be a
>>   > problem? Do
>>
>> Not sure what you mean by "Must any change be observable".
> If we allow stores, if we have an invariant load from some location, and
then a store to that location (value arbitrary), is that a problem if the IR
being analyzed never loads from it again? I don't just mean dead stores:
just because the IR in question does not load from it again, that does not mean
that "the system" doesn't.
>
>>   > atomic loads of invariant locations really need to be atomic?
>>
>> It depends on the answer to "Do we allow stores to these locations
at
>> all?".  If we don't allow stores to these locations at all
then
>> atomic
>> loads are not required, since we can't have racing stores to that
>> location.
>>
>> However, syntactically, I'd be tempted to allow invariant loads to
be
>> atomic; and maybe have a later pass strip out the atomic bit if the
>> semantics we decide allow that.
> I agree. We should allow atomic loads to be marked as !invariant.load. We
might, if we decide on semantics that allow it, canonicalize by demoting to a
non-atomic load.
>
>   -Hal
>
>> -- Sanjoy
>>
-- 
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.