[cfe-dev] [RFC][OpenCL] Rename OpenCL opaque types in LLVM IR from opencl.* to __opencl_*

Wed Jul 27 08:29:04 PDT 2016

You are right. It should be struct.__opencl_ prefix.

Sam

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: Wednesday, July 27, 2016 10:56 AM
To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>
Cc: Sumner, Brian <Brian.Sumner at amd.com>; Pan, Xiuli <xiuli.pan at intel.com>; nd <nd at arm.com>
Subject: RE: [RFC][OpenCL] Rename OpenCL opaque types in LLVM IR from opencl.* to __opencl_*

Hi Sam,

I want to clarify the use case.
The intension is to allow library developer redefining OpenCL images types in a library written in OpenCL C and prefix starting with double underscore is supposed to protect the library image types definitions from redefinition by user.
The change you are proposing is to rename image opaque types in LLVM IR, without making them concrete.
Am I getting it right?

Wouldn't types defined by library developer prefixed with 'struct.'? Shouldn't clang create opaque types with 'struct.__opencl_' prefix instead to match the type names defined by library developer?

Thanks,
Alexey

From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
Sent: Monday, July 25, 2016 6:41 PM
To: 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>>
Cc: Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Bader, Alexey <alexey.bader at intel.com<mailto:alexey.bader at intel.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>; nd <nd at arm.com<mailto:nd at arm.com>>
Subject: RE: [RFC][OpenCL] Rename OpenCL opaque types in LLVM IR from opencl.* to __opencl_*

Sounds good to me!

Thanks,

Anastasia

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: 20 July 2016 18:49
To: cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Anastasia Stulova; Sumner, Brian; Bader, Alexey (alexey.bader at intel.com<mailto:alexey.bader at intel.com>); Pan, Xiuli
Subject: [RFC][OpenCL] Rename OpenCL opaque types in LLVM IR from opencl.* to __opencl_*

Currently OpenCL opaque types have name opencl.* in LLVM IR, which causes difficulty for library developers who need to implement the concrete types corresponding to the opaque types.

For example, read_only image2d_t type is translated to opencl.image2d_ro_t addrspace(1)* in LLVM IR. Ideally, a library developer would implement a concreate struct type with name opencl.image2d_ro_t and access its members. However, due to the '.', 'opencl.image2d_ro_t' is not a valid identifier in OpenCL C language, library developers cannot use it as the name of the concrete struct type for image2d_t. Bitcasts have to be introduced, which causes extra efforts in backends.

Due to this reason, we would like to propose renaming OpenCL opaque types in LLVM IR from opencl.* to __opencl_*.

This change will make the IR deviate from SPIR spec. However, considering there is simple rule to map this new name to SPIR defined name, and LLVM IR currently generated by Clang has already been deviated from SPIR spec, a SPIR consumer should be able to accommodate this change if it is able to accommodate existing deviations.

Your feedbacks are welcome. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160727/658e6ff2/attachment.html>