[cfe-dev] [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
Richard Smith via cfe-dev
cfe-dev at lists.llvm.org
Wed Sep 12 17:04:31 PDT 2018
On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev <
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> 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>> 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?
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>> 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> -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> -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>
> >>>> 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
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180912/55368491/attachment.html>
More information about the cfe-dev
mailing list