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

[Sameer Sahasrabuddhe via llvm-dev]

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
> 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.
>

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>