[LLVMdev] [RFC] Proposal for Adding SPIRV Target
Neil Henning
llvm at duskborn.com
Tue Jul 7 02:17:20 PDT 2015
So we have been in discussions within the Khronos SPIR-V work group on
our push to get our SPIR-V code into tip LLVM and have drawn the
following conclusions;
* We absolutely must create a fully fledged backend that uses all the
machinery that target backends are expected to use.
* We probably have to split out the SPIR-V -> LLVM IR into a separate
project from LLVM ala Clang et al.
As we want to allow developers to use the SPIR-V production/consumption
code now, and the time sink doing the above approach would incur, we are
going to open source the current work on the Khronos GitHub page as a
first step.
We intend to revisit introducing a SPIR-V backend to LLVM in the future.
Cheers,
-Neil.
On 18/06/15 20:25, Liu, Yaxun (Sam) wrote:
>
> *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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150707/85da5167/attachment.html>
More information about the llvm-dev
mailing list