<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 17, 2018 at 11:28 PM, Philip Reames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span><br><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote></span>
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.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The initial implementation would treat them as strongly ordered. (Just for simplicity).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It sounds like perhaps this would be allowed, and this could be useful for modeling non-coherent memory accesses in GLSL and SPIR-V.<br>
</blockquote></span>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Sameer.<br></div></div><br></div></div>