Richard Smith via llvm-dev
2018-Sep-12 21:54 UTC
[llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
On Tue, 11 Sep 2018 at 19:40, 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.I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.> 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. >The nice thing about code is that it's malleable. If there's a limitation that prevents SPIR-V being written as an LLVM target, we should just fix that. -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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/6cfabd03/attachment.html>
Matthias Braun via llvm-dev
2018-Sep-12 22:21 UTC
[llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
> On Sep 12, 2018, at 2:54 PM, Richard Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 11 Sep 2018 at 19:40, 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. > > I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.Using lib/CodeGen and going to MIR makes sense if you have to solve instruction selection, legalization, scheduling, register/resource allocation problems, manage a callstack etc. if you don't need any (or most) of that then I think it makes sense to just build a custom IR pass rather than invoking the whole codegen machinery.> > 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. > > The nice thing about code is that it's malleable. If there's a limitation that prevents SPIR-V being written as an LLVM target, we should just fix that.Indeed we should still be able to implement the TargetMachine interface and get the thing into the TargetMachine registry. - 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 <http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html> > > [2]: https://github.com/thewilsonator/llvm-target-spirv <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/b5a4bf14/attachment.html>
Hal Finkel via llvm-dev
2018-Sep-12 22:25 UTC
[llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
On 09/12/2018 05:21 PM, Matthias Braun via llvm-dev wrote:> > >> On Sep 12, 2018, at 2:54 PM, Richard Smith via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> On Tue, 11 Sep 2018 at 19:40, 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. >> >> >> I don't see how SPIR-V is any different from WebAssembly or PTXAS in >> this regard. I also don't see why a "whole backend" is a different >> amount of work from a separate program that implements a whole backend. > Using lib/CodeGen and going to MIR makes sense if you have to solve > instruction selection, legalization, scheduling, register/resource > allocation problems, manage a callstack etc. if you don't need any (or > most) of that then I think it makes sense to just build a custom IR > pass rather than invoking the whole codegen machinery. > >> >> >> 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. >> >> >> The nice thing about code is that it's malleable. If there's a >> limitation that prevents SPIR-V being written as an LLVM target, we >> should just fix that. > Indeed we should still be able to implement the TargetMachine > interface and get the thing into the TargetMachine registry.I agree. Isn't this the way that the C backend used to work? -Hal> > - 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 >> <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 <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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/1011aa83/attachment.html>
Derek Schuff via llvm-dev
2018-Sep-12 22:25 UTC
[llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
On Wed, Sep 12, 2018 at 2:55 PM Richard Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > I don't see how SPIR-V is any different from WebAssembly or PTXAS in this > regard. I also don't see why a "whole backend" is a different amount of > work from a separate program that implements a whole backend. > >Our experience with WebAssembly (or really with its predecessors PNaCl and asm.js) was that it certainly is possible to do a reasonable implementation of TargetMachine and the related interfaces without using all of the common bits in lib/CodeGen that aren't suitable. However it does mean duplicating some of the functionality; for example when you skip SelectionDAG you end up having to re-implement a lot of the type legalization that happens during that stage. This was one of the top concerns we heard when we proposed upstreaming: people didn't want that duplication (and confusion about there being 2 different ways to do the same thing) even if the duplicated functionality was itself shared between projects. My observation was that one of the key things that got WebAssembly greater acceptance was our decision to use the lib/CodeGen pipeline. (I can't really say about NVPTX). I think if you were principled about the design you could probably support a use case like SPIR-V in a reasonable way, but you'd need to convince stakeholders that things have changed (a lot changes over the period of years) and that the benefits justify the costs, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/2428935b/attachment-0001.html>