[LLVMdev] [RFC] Proposal for Adding SPIRV Target

Thu Jun 18 12:25:39 PDT 2015

From: Eli Bendersky [mailto:eliben at google.com]
Sent: Thursday, June 18, 2015 1:43 PM
To: Mehdi Amini
Cc: Liu, Yaxun (Sam); llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target

On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote:

On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote:

From: Mehdi Amini [mailto:mehdi.amini at apple.com]
Sent: Thursday, June 18, 2015 11:24 AM
To: Liu, Yaxun (Sam)
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target

On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote:

Hi Mehdi,

Thank you for your comments. My comments are below.

Sam

From: Mehdi Amini [mailto:mehdi.amini at apple.com]
Sent: Wednesday, June 17, 2015 12:43 PM
To: Liu, Yaxun (Sam)
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target

Hi Liu,

Thanks for the detailed proposal.

On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote:

Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks.

Proposal of Adding SPIRV Target

Background

SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows:

1.      An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms.
2.      The application developer ships the application containing the SPIR-V binary to customers.
3.      A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function.
4.      The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device.

Step 4 of your “typical use case” includes "changes the target triple and data layout to suit the device which will execute the kernel”. It implies that SPIR-V is data layout agnostic since you can load it with any data layout, or there are (to be specified) constraint on what a “compatible” data layout is, or you considered that it is up to the OpenCL vendor to figure out what will work or not, with the drawback that any LLVM update can break its use case.

+ For OpenCL, LLVM IR translated from SPIR-V has specific data layouts, which are the data layouts for target spir/spir64. OpenCL vendor’s target data layout are assumed to be consistent with them.

For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all.

Location

From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter:

1.      llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V.

How important is it to “reflect it”?
The SPIR-V emitter could just assert on the data layout matching what is expected.
+ Putting the converter at llvm/lib/SPIRV may encourage misuse of the converter, i.e., using the converter to convert LLVM IR of arbitrary target, whereas the converter can only convert LLVM IR with spir/spir64 target.

I don’t know how the discussion about SelectionDAG impact your plan.
If the IR -> SPIR-V path is implemented as a “regular” target using the legalization framework and so on, almost all the code will be in lib/Target/SPIRV.
However it is not clear to me why the SPIR-V -> IR path would benefit in any way to be there as well?

Conceptually I should be able to compile LLVM and disable the SPIR-V backend but still be able to read-in SPIR-V and target my fancy OpenCL compliant device with my backend.
+ The rationale is that SPIR-V is an alternative representation of LLVM IR for spir/spir64 target. Therefore bi-way translation between LLVM and SPIR-V is possible. Such functionality naturally belongs to the target. The user who needs the translation functionality needs to link to the SPIRV target library.

It doesn’t not seem “natural” to me that a “target” backend would operate as a “source”.
It is not clear also what piece of the target infrastructure would be helpful to convert from SPIR-V to IR.
At some point there was a C target backend, it still would seem silly to implement clang as a target.

+1

It's highly unusual for lib/Target to implement X-to-LLVM-IR conversions.

Eli

OK how about let’s keep the original location. Keep the converter in lib/SPIRV and add a thin wrapper in lib/Target/SPIRV for now. As refactoring work goes on and lib/Target/SPIRV becomes full-fledged, phase out the SPIRV writer in lib/SPIRV. This also helps keep the SelectionDAG/MC implementation cleaner.

Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/eba71c13/attachment.html>