[cfe-dev] [RFC] Support synchronisation scope in Clang atomic builtin functions

[John McCall via cfe-dev]

> On Jan 17, 2017, at 12:15 PM, Liu, Yaxun (Sam) via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> OpenCL 2.0 atomic builtin functions have a scope argument which is ideally represented as synchronization scope argument in LLVM atomic instructions.
> 
> Clang supports translating Clang atomic builtin functions to LLVM atomic instructions. However it currently does not support synchronization scope of LLVM atomic instructions. Without this, users have to use LLVM assembly code to implement OpenCL atomic builtin functions.
> 
> I have a patch (https://reviews.llvm.org/D28691 ) which allows Clang atomic builtin functions to accept an optional synchronization scope argument, so that they can be used to implement OpenCL atomic builtin functions.
> 
> This patch will not just benefits OpenCL. It will benefit any languages which need to generate atomic instructions with synchronization scopes. For languages not using synchronization scopes there is no functional change, since the synchronization scope argument is optional, and its default value generates the same LLVM instruction as before.

I missed the introduction of synchronization scope to LLVM.  Okay, so the idea is that these accesses still need to be executed atomically, and they can have various ordering requirements like ordinary atomics, but they need to protect against interrupts instead of concurrency?

One interesting point is that these aren't strictly easier to support than concurrent atomics.  You can fall back on using locks for concurrent atomics; you can't do that here, because the interrupting code would not be able to successfully access the object at all.  The only thing you can do is temporarily disable interrupts (if you were in the kernel).  This makes me wonder whether we really understand the spectrum that users will want to express here.

I'm very concerned about adding things to builtins that Clang doesn't technically "own", because it could put us in a position where we can't support the owner's future extensions to those builtins.  We certainly don't own any builtins that originated with GCC, and I think the __c11 ones are intentionally designed to emulate the corresponding C11 functions.

John.