[LLVMdev] [RFC] Proposal for Adding SPIRV Target
Tom Stellard
tom at stellard.net
Tue Jul 7 06:43:55 PDT 2015
On Tue, Jul 07, 2015 at 10:17:20AM +0100, Neil Henning wrote:
> 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.
Can you give details on how you reached this conclusion? Why was this
determined to be better than the alternatives?
Thanks,
Tom
> * 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list