[LLVMdev] memory scopes in atomic instructions

[Sahasrabuddhe, Sameer]

On 11/19/2014 11:24 PM, Sahasrabuddhe, Sameer wrote:

>>     5. Possibly add the following constraint on memory scopes: "The 
>> scope
>>        represented by a larger value is nested inside (is a proper 
>> subset
>>        of) the scope represented by a smaller value." This would also
>>     imply
>>        that the value used for single-thread scope must be the largest
>>        value used by the target.
>>        This constraint on "nesting" is easily satisfied by HSAIL (and 
>> also
>>        OpenCL), where synchronization scopes increase from a single
>>        work-item to the entire system. But it is conceivable that other
>>        targets do not have this constraint. For example, a platform may
>>        define synchronization scopes in terms of overlapping sets 
>> instead
>>        of proper subsets.
>>
>> I think this is the important thing to settle on in the design. I'd 
>> really like to hear from a diverse set of vendors and folks operating 
>> in the GPU space to understand whether having this constraint is 
>> critically important or problematic for any reasons.
>
> I think "heterogenous systems" (in general, and not just HSA) might be 
> a better term since it covers more than just GPU devices.

I asked around inside AMD. The feedback that I got is that assuming 
nested scopes for GPUs is reasonable, but the concern about future 
targets is valid on general principles.

I still feel that it is a bit premature to build this assumption into 
LLVM ... we can at least wait until we encounter the first analysis or 
transformation that needs to depend on nested scopes! Note that this 
only affects the comparison of atomic accesses to each other, and that 
too, only when their scopes do not match. It does not affect how 
non-atomic accesses are optimized with respect to atomic accesses.

Meanwhile, I will start working on the required changes. The only 
decision required right now is whether to use "1" for SingleThread, or 
the largest integer value.

Sameer.