[RFC] Support synchronisation scope in Clang atomic builtin functions

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.

Your comments are welcome.

Thanks.

Sam

FYI, reference to the relevant part of the OpenCL spec: https://www.khronos.org/registry/OpenCL/specs/opencl-2.0-openclc.pdf#105

From the OpenCL side this proposal seems to make sense generally. I am not quite clear though what would happen with the scopes other than synch_scope_single_thread.

Do you need to extend the IR language to accommodate that too in addition to ‘singlethread’ flag you already use?

Cheers,

Anastasia

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.

FYI, reference to the relevant part of the OpenCL spec: https://www.khronos.org/registry/OpenCL/specs/opencl-2.0-openclc.pdf#105

From the OpenCL side this proposal seems to make sense generally. I am not quite clear though what would happen with the scopes other than synch_scope_single_thread.

Do you need to extend the IR language to accommodate that too in addition to ‘singlethread’ flag you already use?

Thank you for linking the actual language specification. It seems clear to me now that we just need to introduce new builtin functions specifically for OpenCL. The OpenCL implementation in IRGen can then just handle different constants however it wishes.

John.

FYI, reference to the relevant part of the OpenCL spec: https://www.khronos.org/registry/OpenCL/specs/opencl-2.0-openclc.pdf#105

From the OpenCL side this proposal seems to make sense generally. I am not quite clear though what would happen with the scopes other than synch_scope_single_thread.

Do you need to extend the IR language to accommodate that too in addition to 'singlethread' flag you already use?
We have the review/RFC for this posted here: https://reviews.llvm.org/D21723. But did not get a chance to follow up yet.

Konstatnin

Cheers,
Anastasia

Thanks John for your comments. I will try adding builtin functions for OpenCL atomics instead.

Anastasia, Alexey,

To allow OpenCL implementations have flexibility of their own implementation of OpenCL atomic builtin functions, I think the clang atomic builtin functions for OpenCL should not have the same name as the OpenCL atomic builtin functions, instead they can have names like _opencl_atomic*. What do you think?

Thanks.

Sam

Yes, I agree we could append “__opencl” prefix to the function names from the spec. J

Anastasia

Hi Sam,

No objections from my side neither.