[LLVMdev] memory scopes in atomic instructions

[Owen Anderson]

> On Nov 16, 2014, at 9:03 PM, Sahasrabuddhe, Sameer <Sameer.Sahasrabuddhe at amd.com> wrote:
> 
>> 
>> 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.

It is already the case that address spaces can (potentially) alias.  As such, the combination of address spaces and memory scopes can represent any combination where the sharing properties of memory are statically known, simply by having (potentially aliasing) address spaces to represent memory pools that are only shared with a specific combinations of agents.  One can imagine a GPU that worked like this, and GPU programming models do generally differentiating various sharing pools statically.

The case that this doesn’t handle is when the sharing properties are not known statically.  However, I question the utility of designing this, since there are no known systems that require it.  We should design the representation to cover all reasonably anticipated systems, not ones that don’t, and have no prospect of, existing.

—Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141116/bdc36d35/attachment.html>