[cfe-dev] [RFC] Support synchronisation scope in Clang atomic builtin functions
Anastasia Stulova via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 19 09:51:34 PST 2017
Yes, I agree we could append “__opencl” prefix to the function names from the spec. ☺
Anastasia
From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: 19 January 2017 15:57
To: rjmccall at apple.com; Anastasia Stulova
Cc: cfe-dev (cfe-dev at lists.llvm.org); nd; Tye, Tony; Bader, Alexey (alexey.bader at intel.com); Sumner, Brian; Zhuravlyov, Konstantin
Subject: RE: [cfe-dev] [RFC] Support synchronisation scope in Clang atomic builtin functions
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
From: rjmccall at apple.com<mailto:rjmccall at apple.com> [mailto:rjmccall at apple.com]
Sent: Tuesday, January 17, 2017 2:45 PM
To: Anastasia Stulova <Anastasia.Stulova at arm.com<mailto:Anastasia.Stulova at arm.com>>
Cc: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>; nd <nd at arm.com<mailto:nd at arm.com>>; Tye, Tony <Tony.Tye at amd.com<mailto:Tony.Tye at amd.com>>; Bader, Alexey (alexey.bader at intel.com<mailto:alexey.bader at intel.com>) <alexey.bader at intel.com<mailto:alexey.bader at intel.com>>; Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com<mailto:Konstantin.Zhuravlyov at amd.com>>
Subject: Re: [cfe-dev] [RFC] Support synchronisation scope in Clang atomic builtin functions
On Jan 17, 2017, at 1:54 PM, Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
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.
Cheers,
Anastasia
From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: 17 January 2017 17:16
To: cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Sumner, Brian; Tye, Tony; Zhuravlyov, Konstantin; Anastasia Stulova; Bader, Alexey (alexey.bader at intel.com<mailto:alexey.bader at intel.com>)
Subject: [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
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170119/1ea2f100/attachment.html>
More information about the cfe-dev
mailing list