llvm dev - Jun 2016 - Memory scope proposal

Hi all,

On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote:
>> Why not going with a metadata attachment directly and kill the
"singlethread" keyword? Something like:
>> >Something like:
>> >
>> >  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3,
!memory.scope{!42}
>> >  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3,
!memory.scope{!43}
>> >
>> >...
>> >
>> >!42 = !{"singlethread"}
>> >!43 = !{"L2"}
>> >
>> >
>> >I also avoids manipulating/pruning the global map, and target
won't depend on integer to keep bitcode compatibility.
>> >
>> >
> This seems like it will work assuming that promoting something like
"L2" to the
> most conservative memory scope is legal (this is what would have to happen
> if the metadata was dropped).  Are there any targets where this type
of'
> promotion would be illegal?
+1

Sorry to enter this discussion so late, but in my opinion this
is a very good non-intrusive starting point solution.

Implementing it as a MD with the assumption of there being a safe
conservative memory scope to fall back to (in case the MD gets
stripped off for some reason) converts it to a mere
optimization hint without the need to touch LLVM IR instruction semantics.

Also, as it's only a MD, if we encounter a need to extend it later 
towards a more integrated solution (or a mechanism to support
targets where this scheme is not feasible), we can more easily do so.

BR,
-- 
Pekka

+ Brian and Konstantin

On Wed, May 18, 2016 at 11:18:53AM +0300, Pekka Jääskeläinen
wrote:
> Hi all,
> 
> On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote:
> >>Why not going with a metadata attachment directly and kill the
"singlethread" keyword? Something like:
> >>>Something like:
> >>>
> >>>  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3,
!memory.scope{!42}
> >>>  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3,
!memory.scope{!43}
> >>>
> >>>...
> >>>
> >>>!42 = !{"singlethread"}
> >>>!43 = !{"L2"}
> >>>
> >>>
> >>>I also avoids manipulating/pruning the global map, and target
won't depend on integer to keep bitcode compatibility.
> >>>
> >>>
> >This seems like it will work assuming that promoting something like
"L2" to the
> >most conservative memory scope is legal (this is what would have to
happen
> >if the metadata was dropped).  Are there any targets where this type
of'
> >promotion would be illegal?
> 
> +1
> 
> Sorry to enter this discussion so late, but in my opinion this
> is a very good non-intrusive starting point solution.
> 
> Implementing it as a MD with the assumption of there being a safe
> conservative memory scope to fall back to (in case the MD gets
> stripped off for some reason) converts it to a mere
> optimization hint without the need to touch LLVM IR instruction semantics.
> 
> Also, as it's only a MD, if we encounter a need to extend it later
towards a
> more integrated solution (or a mechanism to support
> targets where this scheme is not feasible), we can more easily do so.
> 
> BR,
> -- 
> Pekka

We believe that it would be best that this is added to the LLVM IR atomic memory
instruction as fields on atomic instructions rather than using meta data.

The reasoning is that this information is similar to other information that is
represented as instruction fields. For example, the indication that memory
operations are atomic rather than non-atomic, the memory ordering of atomics,
and whether per-thread or system scope. In all these cases this information has
a semantic meaning for the instructions that can be exploited by optimizations.
Representing it as meta data would mean this information could be dropped making
the optimizations impossible with very significant performance penalty.

For example, if memory operations were not marked as being atomic, all memory
operations would have to be generated as sequential consistent atomics at system
scope. Although this "default" behavior is correct, it would not be
very performant. Similarly, the memory ordering could use a "default"
of sequentially consistent, which again is much less efficient than the weaker
orderings. By analogy, the memory scope could also have a "default" of
system scope, but that is also not performant when the scope is narrower.

In all these cases this information changes the semantics of the instructions.
It affects whether a program is undefined behavior. Using a "default"
value leads to those same programs being treated as having defined behavior (for
example by eliminating data races).

Currently the atomic memory instructions have the own-thread/system recorded on
the instruction which is a limited form of memory scope. The proposal is to
replace this with a more general field that can have more than 2 values.
Languages that do not use memory scopes can simply use the value corresponding
to system scope.

We understand that it is good to avoid adding information to LLVM instructions
that is not primary, but in this case it seems that the atomicity, memory
ordering and memory scope are all equally primary information that characterize
the semantics of memory instructions.

We have posted reviews that implement the proposal and invite everyone to
discuss it:
http://reviews.llvm.org/D21723
http://reviews.llvm.org/D21724

Thank you,
Konstantin



-----Original Message-----
From: Tom Stellard [mailto:tom at stellard.net] 
Sent: Wednesday, June 22, 2016 4:51 PM
To: Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>
Cc: Mehdi Amini <mehdi.amini at apple.com>; Liu, Yaxun (Sam) <Yaxun.Liu
at amd.com>; Ke Bai <kebai613 at gmail.com>; Mekhanoshin, Stanislav
<Stanislav.Mekhanoshin at amd.com>; llvm-dev at lists.llvm.org; Tye, Tony
<Tony.Tye at amd.com>; Sumner, Brian <Brian.Sumner at amd.com>;
Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com>
Subject: Re: [llvm-dev] Memory scope proposal

+ Brian and Konstantin

On Wed, May 18, 2016 at 11:18:53AM +0300, Pekka Jääskeläinen
wrote:
> Hi all,
> 
> On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote:
> >>Why not going with a metadata attachment directly and kill the
"singlethread" keyword? Something like:
> >>>Something like:
> >>>
> >>>  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, 
> >>> !memory.scope{!42}  cmpxchg i32* %addr, i32 42, i32 0
monotonic
> >>> monotonic, 3, !memory.scope{!43}
> >>>
> >>>...
> >>>
> >>>!42 = !{"singlethread"}
> >>>!43 = !{"L2"}
> >>>
> >>>
> >>>I also avoids manipulating/pruning the global map, and target
won't depend on integer to keep bitcode compatibility.
> >>>
> >>>
> >This seems like it will work assuming that promoting something like 
> >"L2" to the most conservative memory scope is legal (this is
what
> >would have to happen if the metadata was dropped).  Are there any
targets where this type of'
> >promotion would be illegal?
> 
> +1
> 
> Sorry to enter this discussion so late, but in my opinion this is a 
> very good non-intrusive starting point solution.
> 
> Implementing it as a MD with the assumption of there being a safe 
> conservative memory scope to fall back to (in case the MD gets 
> stripped off for some reason) converts it to a mere optimization hint 
> without the need to touch LLVM IR instruction semantics.
> 
> Also, as it's only a MD, if we encounter a need to extend it later 
> towards a more integrated solution (or a mechanism to support targets 
> where this scheme is not feasible), we can more easily do so.
> 
> BR,
> --
> Pekka