[llvm-dev] [cfe-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
Richard Smith via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 12 18:08:04 PDT 2018
On Wed, 12 Sep 2018 at 17:15, Tom Stellard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On 09/12/2018 05:04 PM, Richard Smith wrote:
> > On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > On 09/12/2018 02:32 PM, Matthias Braun wrote:
> > >
> > >
> > >> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > >>
> > >> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
> > >>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote:
> > >>>
> > >>> I was going to wait until Neil Trevett got back to me about
> becoming a SPIR-V TSG advisor but this seems like just as good an
> opportunity. Please see the previous discussion [1] if you have not
> already, there were many relevant points made.
> > >>>
> > >>> First, I’d like to note that while clang may be the primary
> motivator for many of the readers here it is not the only frontend that
> would like to make use of proper SPIR-V support in LLVM. In particular, the
> current implementation of builtins as Itanium with extensions mangled C++
> is much more difficult to use (even if those frontends have a C++ mangler,
> the extensions make it unusable), compared to intrinsics which is _the_ way
> backends for LLVM expose builtins. This is an absolute requirement for me
> for SPIR-V support in upstream LLVM.
> > >>>
> > >>> I’d much rather have this as a target than as an external
> library, but if it means I get intrinsics faster then I’m all for it.
> > >>>
> > >>>
> > >>> +1. What would be the justification for using an external binary
> for this rather than treating it like any other LLVM backend?
> > >>>
> > >>
> > >> This has been discussed in the past, but I don't think SPIR-V
> > >> is a good fit for an LLVM backend. It is very similar to LLVM
> > >> IR and it seems like overkill to write a whole backend just to
> > >> do a simple translation. Not to mention the fact that I don't
> > >> see how it's possible with the current backend infrastructure
> > >> to preserve type information for complex types like structs all
> > >> the way through the codegen pipeline.
> > >
> > > Note that even when not using lib/CodeGen (which is indeed a bad
> fit here), you should still be able to implement the TargetMachine
> interface (and return nullptr for most of the methods in there) so it
> behaves like the other LLVM backend on the outside API.
> > >
> >
> > In the past one of the arguments against doing this is that when you
> > have a target that doesn't use the common legalization/lowering
> framework
> > then it makes changes to the IR that much more burdensome, because
> > you now have one more thing to update in addition to SelectionDAG,
> > GlobalISel, and FastISel. And then what happens if we end up with
> > multiple targets like this?
> >
> >
> > We have to pay that cost regardless of whether it's part of maintaining
> llvm-spirv or part of maintaining a SPIR-V backend, though, don't we?
> >
>
> This all depends on if llvm-spirv becomes an official sub-project or not,
> which
> is a whole other discussion, but if it does then yes the cost would be the
> same.
>
If compiling to SPIR-V is not officially something that LLVM can do, then
supporting that target in Clang *at all* is whole other discussion we need
to have.
> -Tom
>
> > I do think having some having some kind of TargeMachine wrapper
> > around an IR pass(es) would be a good technical solution, though, if
> > we can find a way to keep the support burden minimal, especially
> > since the LLVM IR -> SPIR-V translation code already exists.
> >
> > -Tom
> >
> > > - Matthias
> > >
> > >>
> > >> -Tom
> > >>
> > >>
> > >>>
> > >>> Could you please link the thread mentioned?
> > >>>
> > >>> Thanks,
> > >>> Nic
> > >>>
> > >>> P.S. Feel free to use the tablegen descriptions of the SPIR-V
> format from [2]
> > >>>
> > >>> [1]:
> http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html
> > >>> [2]: https://github.com/thewilsonator/llvm-target-spirv
> > >>>
> > >>>> On 10 Sep 2018, at 11:10 pm, Anastasia Stulova via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote:
> > >>>>
> > >>>> Hello,
> > >>>>
> > >>>> Since 2015 Khronos has switched to the new portable
> intermediate format SPIR-V, which has replaced the original SPIR. The
> advantage is that it offers higher portability across different toolchains.
> There was a talk about it at a Dev Meeting:
> > >>>>
> http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#17
> > >>>>
> > >>>> LLVM currently only supports SPIR format for OpenCL in
> Clang. Several Khronos vendors (ARM, AMD, Intel, Xilinx, Codeplay and
> others) are interested in adding support for SPIR-V, which should gradually
> replace the old SPIR once products are no longer shipped with the old
> format. Here is the detailed description:
> > >>>>
> https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang
> > >>>>
> > >>>> To summarize, the idea is to add a SPIR-V target triple to
> Clang that can be used to generate a SPIR-V binary for OpenCL code. There
> was a separate thread regarding generation of SPIR-V binary and the
> community suggested that a translator from LLVM IR to SPIR-V can be used as
> an external tool, called llvm-spirv. This can be invoked similar to such
> tools as ptxas and fatbinary for the CUDA toolchain:
> > >>>>
> http://lists.llvm.org/pipermail/llvm-dev/2018-February/121440.html
> > >>>>
> > >>>> An example of how Clang can be used to target SPIR-V:
> > >>>>
> > >>>> clang -c test.cl <http://test.cl> <http://test.cl> -target
> spirv[32|64]-unknown-unknown -o test.spv
> > >>>>
> > >>>> This will result in the following Clang actions:
> > >>>>
> > >>>> (1) clang -cc1 -triple spirv[32|64]-unknown-unknown test.cl
> <http://test.cl> <http://test.cl> -emit-llvm-bc -o test.bc
> > >>>>
> > >>>> (2) llvm-spirv test.bc -o test.spv
> > >>>>
> > >>>> SPIR-V generation is essential for completion of OpenCL C++
> support in Clang, as newer OpenCL standards require frontend invocation to
> be performed offline, producing the SPIR-V binary that can be then loaded
> at application execution time. Besides that, it will also allow Clang to be
> used as a complete standalone tool to generate portable binaries that can
> then be consumed by different proprietary toolchains. In addition, this
> will open a path to the LLVM backends for various languages and frontends
> that already generate SPIR-V.
> > >>>>
> > >>>> A more detailed explanation of the complete design proposal
> is given in this Wiki page:
> > >>>>
> https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang
> > >>>>
> > >>>> Looking forward to any feedback about the proposal or
> possible collaborations,
> > >>>>
> > >>>> Thanks!
> > >>>>
> > >>>> Anastasia
> > >>>> _______________________________________________
> > >>>> LLVM Developers mailing list
> > >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> > >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>>
> > >>> _______________________________________________
> > >>> LLVM Developers mailing list
> > >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> LLVM Developers mailing list
> > >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>>
> > >>
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/6d6ca97b/attachment.html>
More information about the llvm-dev
mailing list