[cfe-dev] [RFC][OpenCL] Allow users to add supported OpenCL extensions by pragma

C Bergström via cfe-dev cfe-dev at lists.llvm.org
Mon Jun 27 02:55:49 PDT 2016


I don't care 2-ways about OpenCL, but adding non-standard pragma is a
slippery slope. Please don't add extensions because some vendor is
incapable of doing slight modifications to the source. If instead of a
pragma you offered a build configuration, macros or something else to
make this easier that I could totally understand.

On Mon, Jun 27, 2016 at 3:43 PM, Bader, Alexey via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi,
>
>
>
> Sorry for being late to the discussion, but I didn’t get the use case of the
> proposed feature.
>
> Why vendor/library developer would need compiler to support for some pragma
> that doesn’t change to behavior of the compiler?
>
>
>
> Thanks,
>
> Alexey
>
>
>
> From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
> Sent: Tuesday, June 14, 2016 6:56 PM
> To: Sumner, Brian <Brian.Sumner at amd.com>; Liu, Yaxun (Sam)
> <Yaxun.Liu at amd.com>; cfe-dev (cfe-dev at lists.llvm.org)
> <cfe-dev at lists.llvm.org>; Bader, Alexey <alexey.bader at intel.com>; Pan, Xiuli
> <xiuli.pan at intel.com>
> Cc: Jeroen Ketema <j.ketema at imperial.ac.uk>; nd <nd at arm.com>
> Subject: RE: [RFC][OpenCL] Allow users to add supported OpenCL extensions by
> pragma
>
>
>
> Thanks, Brian!
>
>
>
> Yes, perhaps we could try to make the extension list fully dynamic. Although
> I would imagine it’s still useful to have standard extensions from the Spec
> directly in Clang to be available for the cases without standard header
> include.
>
>
>
> Cheers,
>
> Anastasia
>
>
>
> From: Sumner, Brian [mailto:Brian.Sumner at amd.com]
> Sent: 14 June 2016 16:18
> To: Anastasia Stulova; Liu, Yaxun (Sam); cfe-dev (cfe-dev at lists.llvm.org);
> Bader, Alexey (alexey.bader at intel.com); Pan, Xiuli
> Cc: Jeroen Ketema; nd
> Subject: RE: [RFC][OpenCL] Allow users to add supported OpenCL extensions by
> pragma
>
>
>
> Hi Anastasia,
>
>
>
> To answer your last question, this would be specific to clang.  It will
> allow those of us using clang for OpenCL languages to implement many of our
> vendor specific extensions without any other changes to clang.  I expect a
> few of the current KHR extensions that do not involve new or special types
> could be moved into opencl-c.h using this mechanism if desired as well.
>
>
>
> Thanks,
>
> Brian
>
>
>
> From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
> Sent: Monday, June 13, 2016 11:25 AM
> To: Liu, Yaxun (Sam); cfe-dev (cfe-dev at lists.llvm.org); Bader, Alexey
> (alexey.bader at intel.com); Pan, Xiuli
> Cc: Sumner, Brian; Jeroen Ketema; nd
> Subject: RE: [RFC][OpenCL] Allow users to add supported OpenCL extensions by
> pragma
>
>
>
> Interesting idea! Just to be clear, you are suggesting to add parsing of the
> following into Clang:
>
>
>
> #pragma OPENCL EXTENSION the_new_extension_name : register
>
>
>
> Which would add custom the_new_extension_name to the list of known and
> supported OpenCL extensions dynamically?
>
>
>
> Normally, target triple that combines RT and specific hardware type would be
> used for those purposes.
>
> But I believe it shouldn’t be too complicated to add this pragma considering
> that OpenCL already has similar ones.
>
>
>
> This approach could offer some degree of flexibility to the library
> implementations,
>
> which would otherwise have to add separate triple representing their library
> ABIs.
>
>
>
> Would this be allowed in any OpenCL code as some sort of Clang extension or
> is there a plan to add this into Spec?
>
>
>
> Thanks,
>
> Anastasia
>
>
>
> From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
> Sent: 10 June 2016 19:40
> To: cfe-dev (cfe-dev at lists.llvm.org); Anastasia Stulova; Bader, Alexey
> (alexey.bader at intel.com); Pan, Xiuli
> Cc: Sumner, Brian; Jeroen Ketema
> Subject: [RFC][OpenCL] Allow users to add supported OpenCL extensions by
> pragma
>
>
>
> Currently Clang defines supported OpenCL extensions for each target based on
> triple and CPU. As a default configuration this seems sufficient.
>
>
>
> However if vendors and library developers want to add support of their own
> extensions, they have to modify Clang, which is very inconvenient.
>
>
>
> We need a flexible and expressive way to add supported extensions for
> vendors and library developers.
>
>
>
> Brian has a proposal which introduces a pragma to add supported extensions:
>
>
>
> #pragma OPENCL EXTENSION the_new_extension_name : register
>
>
>
> This pragma tells clang the name of a new OpenCL extension and request that
> it process it just like any other OpenCL extension, e.g. recognize
>
>
>
> #pragma OPENCL EXTENSION the_new_extension_name : enable/disable
>
>
>
> in subsequent code.
>
>
>
> Since this pragma can be used in the header file of vendors or library
> developers’ OpenCL implementations, it can provide flexible and expressive
> way to represent supported extensions when combined with other preprocessor
> constructs.
>
>
>
> Any feedbacks? Thanks.
>
>
>
> Sam
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> Russian Federation
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>



More information about the cfe-dev mailing list