[llvm-dev] RFC: Adding a !thread.private metadata

[Philip Reames via llvm-dev]

On 09/16/2018 05:03 AM, Nicolai Hähnle via llvm-dev wrote:
> On 15.09.2018 01:13, Philip Reames via llvm-dev wrote:
>> Add a new metadata type which applies to memory accessing 
>> instructions (store, load, atomicrmw, etc...) and indicates that the 
>> memory location accessed is known to be accessed only by a single 
>> thread everywhere it is dereferenceable.
>
> What are the implications for how this interacts with fences and atomics?
Great question, hadn't thought about it honestly.
>
> For example, if there is a store to a !thread.private memory location 
> before an atomic with release semantics, are we allowed to move the 
> store to after the atomic?
I think this should be allowed.  Because it's known to only be read by a 
single thread, it *can't* be part of any synchronization between threads 
and thus should be freely reorderable.  The slightly tricky one is a 
single_thread fence.  I think that variant may need to prevent the 
reordering.  Having single_thread have *stronger* reordering semantics 
than the cross thread variant feels really ugly though.

The initial implementation would treat them as strongly ordered. (Just 
for simplicity).

>
> It sounds like perhaps this would be allowed, and this could be useful 
> for modeling non-coherent memory accesses in GLSL and SPIR-V.
Can you spell out the semantics you're looking for?  If you have a form 
of memory access which is shared, just unordered, I suspect NotAtomic or 
Unordered are probably a better fit, but I'd need more information to 
really tell.
>
> Cheers,
> Nicolai
>