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

Sameer Sahasrabuddhe via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 18 11:15:17 PDT 2018

On Mon, Sep 17, 2018 at 11:28 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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 singlethread fence. I think that variant may need to prevent the reordering. Having singlethread have stronger reordering semantics than the cross thread variant feels really ugly though.

That sounds about right. It looks ugly only when we look at the compiler in isolation. But this does happen in the actual execution of a program with synchronization scopes. The synchronizing memory operation loses its semantics outside its scope and becomes an ordinary operation which can be reordered in hardware. In that sense, a smaller scope has stronger semantics than a larger scope.

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.

The non-coherent memory could be seen as weaker than unordered. Operations to such memory need not become visible even when the thread synchronizes at an acquire/release operation.

Sameer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180918/4b5993ed/attachment.html>

More information about the llvm-dev mailing list