[LLVMdev] [RFC] Proposal for Adding SPIRV Target
Neil Henning
llvm at duskborn.com
Wed Jul 8 01:46:14 PDT 2015
Hey Chandler!
I think one of the issues we have from a SPIR-V side is that we don't
have any of the usual LLVM community heavyweights on-board to work with
us, which in turn means the community is more likely to be resistant to
any of the changes we would need to make that would affect every
backend, which is understandable.
Given that the WebAssembly effort seems to have more of the usual
suspects in the LLVM community invested in working on it, and they are
likely to encounter at least some of the same problems that an eventual
SPIR-V backend would also have to deal with, I sincerely hope that when
we do come to integrate a SPIR-V backend in the future some of the
harder refactors are already done ;]
Cheers,
-Neil.
On 07/07/15 17:55, Chandler Carruth wrote:
> 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
> <mailto: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
> <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
> <mailto: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>
> >>> <mailto: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>
> >>> <mailto:Yaxun.Liu at amd.com <mailto:Yaxun.Liu at amd.com>>> wrote:
> >>>
> >>> *From:* Mehdi Amini [mailto:mehdi.amini at apple.com
> <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>
> <mailto: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>
> <mailto: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
> <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> <mailto: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>
> <mailto: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 <mailto: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 <mailto: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 <mailto: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/20150708/478aa44c/attachment.html>
More information about the llvm-dev
mailing list