[llvm-dev] RFC: Adding a !thread.private metadata (original) (raw)

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 17 10:58:17 PDT 2018

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

More information about the llvm-dev mailing list