[llvm-dev] Memory scope proposal

[Zhuravlyov, Konstantin via llvm-dev]

>Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like:
>Something like:
>  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!42}
>  cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!43}

>...

>!42 = !{"singlethread"}
>!43 = !{"L2"}

>It is not clear to me if there is any correctness issues to dropping metadata?



Yes, we cannot use the metadata approach since this metadata can be dropped during the processing of one module but not dropped in the processing of a second module, potentially resulting in inconsistent scopes for synchronizing operations leading to data races and subsequently leading to correctness issues.



Thanks,

Konstantin



________________________________
From: Zhuravlyov, Konstantin
Sent: Wednesday, August 17, 2016 4:29:30 PM
To: Sameer Sahasrabuddhe; Philip Reames
Cc: Mehdi Amini; Liu, Yaxun (Sam); Ke Bai; Mekhanoshin, Stanislav; Sumner, Brian; llvm-dev at lists.llvm.org; Tye, Tony
Subject: RE: [llvm-dev] Memory scope proposal

Hi,

I have updated the review here:
https://reviews.llvm.org/D21723

As Sameer pointed out, the motivation is:
In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope" in OpenCL 2.x. Encoding OpenCL 2.x scope as metadata in LLVM IR would be a problem because there cannot be a "safe default value" to be used when the metadata is dropped. If the "largest" scope is used as the default, then the optimizer must guarantee that the metadata is dropped from every atomic operation in the whole program, or not dropped at all.

Thanks,
Konstantin

From: Sameer Sahasrabuddhe [mailto:sameer at sbuddhe.net]
Sent: Sunday, July 10, 2016 4:06 AM
To: Philip Reames <listmail at philipreames.com>
Cc: Mehdi Amini <mehdi.amini at apple.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; Ke Bai <kebai613 at gmail.com>; Mekhanoshin, Stanislav <Stanislav.Mekhanoshin at amd.com>; Sumner, Brian <Brian.Sumner at amd.com>; llvm-dev at lists.llvm.org; Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com>; Tye, Tony <Tony.Tye at amd.com>
Subject: Re: [llvm-dev] Memory scope proposal


On Mon, Jul 4, 2016 at 5:09 AM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
I will comment - as one of the few people actually working on llvm's atomic implementation with any regularity - that I am opposed to extending the instructions without a strong motivating case.  I don't care anywhere near as much about metadata based schemes, but extending the instruction semantics imposes a much larger burden on the rest of the community.  That burden has to be well justified and supported.

In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope" in OpenCL 2.x. Encoding OpenCL 2.x scope as metadata in LLVM IR would be a problem because there cannot be a "safe default value" to be used when the metadata is dropped. If the "largest" scope is used as the default, then the optimizer must guarantee that the metadata is dropped from every atomic operation in the whole program, or not dropped at all.
Hence the original attempt to extend LLVM atomic instructions with a broader scope field.
Sameer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/0b3cef5d/attachment.html>