[LLVMdev] [RFC] Proposal for Adding SPIRV Target

[Eli Bendersky]

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

>
> On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote:
>
>
>
> *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>]
>
> *Sent:* Thursday, June 18, 2015 11:24 AM
> *To:* Liu, Yaxun (Sam)
> *Cc:* 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> wrote:
>
> Hi Mehdi,
>
> Thank you for your comments. My comments are below.
>
> Sam
>
> *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>]
>
> *Sent:* Wednesday, June 17, 2015 12:43 PM
> *To:* Liu, Yaxun (Sam)
> *Cc:* 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/79549e87/attachment.html>