[LLVMdev] memory scopes in atomic instructions

[Owen Anderson]

Hi Sameer,

Did you ever get any further with this proposal?

—Owen

> On Dec 1, 2014, at 3:03 AM, Sahasrabuddhe, Sameer <sameer.sahasrabuddhe at amd.com> wrote:
> 
> 
> On 11/19/2014 6:11 AM, Owen Anderson wrote:
>>> On Nov 18, 2014, at 2:35 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>>> 
>>> I think this should be an arbitrary bit width integer. I think baking any size into this is a mistake unless that size is "1”.
>> ...
>>> If we go with your proposed constraint below, I think it is essential to model single-thread-scope as the maximum integer. It should be a strict subset of all inter-thread scopes.
>> 
>> These seem mutually contradictory.
> 
> I managed to implement wider synchronization scopes in the IR as follows. Would like to put the changes up for review, but I still need some high-level inputs.
> 
> 1. The synchronization scope is already implemented as an unsigned
>   integer in the bitcode, as far as I can tell (but I am still new at
>   understanding BitcodeWriter). Only BitcodeReader needs to change so
>   that it is aware that CrossThread and SingleThread are not the only
>   two values possible.
> 
> 2. My change redefines CrossThread to be "0" from the current "1", and
>   SingleThread to "~0U" from the current "0".
> 
> 3. The LLVM assembly language needs a way to specify all the scopes.
>   The proposed syntax is:
>    1. singlethread: This represents "the largest integer representable
>       in the underlying implementation" and hence "the smallest
>       scope". LLParser will interpret this "~0U".
>    2. synchscope(n): Used to specify any synchronization scope that is
>       larger than a single thread. The notation is similar to that
>       used for address spaces.
>    3. The default scope is the same as specifying "synchscope(0)".
> 
> 4. But the above encoding is actually incompatible with the current
>   encoding; I had got this wrong in my original post. In particular,
>   the following tests failed because the meaning of 0/1 changed:
> 
>   LLVM :: Bitcode/cmpxchg-upgrade.ll
>   LLVM :: Bitcode/memInstructions.3.2.ll
>   LLVM :: Bitcode/weak-cmpxchg-upgrade.ll
> 
>   All three tests contain comments on making sure that older bitcode
>   files can be read correctly.
> 
>   The simplest approach is to invert the new encoding and say that "0"
>   remains as SingleThread, and CrossThread is now the largest integer.
>   This will need a new token "crossthread" in the assembly, and point
>   (3) above will change accordingly. This breaks away from the general
>   tradition of "zero as default", but this was not true with
>   synchronization scopes anyway.
> 
> 5. And yes, "crossthread" needs to be renamed to something better, like
>   "allthreads", or "systemscope", or "addressspacescope". The last one
>   is accurate but takes a small effort to see why. I would go for
>   "allthreads".
> 
> Sameer.
> 
>