[llvm-dev] Memory scope proposal

[Zhuravlyov, Konstantin via llvm-dev]

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