[LLVMdev] memory scopes in atomic instructions

[Sahasrabuddhe, Sameer]

Copying #5 here for reference:

 > 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.

On 11/15/2014 12:20 AM, Owen Anderson wrote:
> I support this proposal, and have discussed more or less the same idea 
> with various people in the past.

Thanks! Good to know that.

>  Regarding point #5, I believe address spaces may already provide the 
> functionality needed to express overlapping constraints.

I am not sure how address spaces can solve the need for such a 
constraint. Memory scopes are orthogonal to address spaces. An agent 
that atomically accesses a shared location in one address space may 
specify a different memory scope on different instructions.

>  I’m also not aware of any systems that would really need that 
> functionality anyways.

Agreed that there are no known systems with overlapping memory scopes, 
but it might premature to just dismiss the possibility. For example, 
there could be a system with a fixed number of agents, say four. Each 
agent can choose to synchronize with one, two or all three peers on 
different instructions. The resulting memory scopes cannot be ordered as 
proper subsets.

Sameer.