[LLVMdev] [RFC] Proposal for Adding SPIRV Target
Chandler Carruth
chandlerc at google.com
Tue Jul 7 09:55:39 PDT 2015
Sorry I've not updated this thread more often.
One thing I want to clarify something for other (possibly future) readers
of the email thread to avoid confusion. I don't think the SPIR folks have
misunderstood, but context is always hard to convey. =]
I'm not pushing for using the machinery for the sake of using it. That
wouldn't make sense. I think there are specific reasons why the
*legalization* machinery (in whatever form that takes) should be common
across backends. This primarily to help ensure that a growing number of
LLVM backends doesn't make changing the core or common parts of LLVM
intractably hard by consolidating and unifying the infrastructure which
provides minimally correct functionality for a backend.
I worry there are similar maintenance concerns with not having an MC-based
encoding layer, but I'm not as deeply familiar with MC so I would defer to
others there.
I also want to make it clear that I'm not under any illusion that these
layers are really in good shape to serve the needs of SPIR-V, or other
virtual ISAs. I think that *any* of the virtual ISA backends currently
being developed will end up needing to do non-trivial work to refactor and
improve these layers of LLVM in order to make them a better fit.
As much as I'd like to have SPIR-V in the tree (and I would), I'm honestly
happier to see appropriate planning for the amount of work that will likely
be required. I think that means that when it does come into the tree, it
will be a much healthier experience.
-Chandler
On Tue, Jul 7, 2015 at 8:04 AM Neil Henning <llvm at duskborn.com> wrote:
> Hey Tom,
>
> Really it was at the behest of the replies - we got a lot of feedback
> from the mailing list that indicated we'd be putting extra workload of
> people changing features of the IR if we didn't follow the same
> mechanisms of the other backends (mostly led by Chandler's very astute
> comments on the subject).
>
> Cheers,
> -Neil.
>
> On 07/07/15 14:43, Tom Stellard wrote:
> > 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
>
>
> _______________________________________________
> 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/81ba914a/attachment.html>
More information about the llvm-dev
mailing list