[cfe-dev] [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang
Justin Lebar via cfe-dev
cfe-dev at lists.llvm.org
Fri Sep 14 09:47:55 PDT 2018
> Currently llvm-spirv completely aligns development process with the main
LLVM. And we even started the same release structure starting from the last
release 7.0. I assume similar problems arise with the other external tools,
for example with CUDA tools - ptxas and fatbinary? And yet it seems the
solutions have been found. If that is the main issue I am happy to have
discussion with people working on CUDA to understand their process better
and adapt whatever necessary.
Hi, LLVM CUDA person here.
We treat ptxas and fatbinary as external tools, akin to an assembler and
linker. As far as clang/llvm is concerned, we have a "proper LLVM backend"
targeting PTX. You don't need ptxas at all in order to compile and run a
CUDA file (the GPU driver will happily compile ptx -> machine code at
runtime), although today you do need fatbinary.
Without taking a position on the question of whether SPIR-V should or
should not happen via proper LLVM backend or a separate tool, I don't see
the connection between CUDA support in clang/llvm and an argument that we
should use a separate tool.
-Justin
On Fri, Sep 14, 2018 at 5:06 AM Anastasia Stulova via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> > For example, for a user who builds a particular SVN revision of Clang
> and LLVM, how are they to determine the corresponding revision of
> llvm-spirv that accepts the LLVM IR produced by that version of LLVM? How
> often will such a version of llvm-spirv even exist? If llvm-spirv is
> lagging behind LLVM trunk (as I would expect it to if it's maintained
> out-of-tree), would that mean that people who track clang and LLVM trunk
> (which is a thing we encourage people to do) can't use it?
>
> Currently llvm-spirv completely aligns development process with the main
> LLVM. And we even started the same release structure starting from the last
> release 7.0. I assume similar problems arise with the other external tools,
> for example with CUDA tools - ptxas and fatbinary? And yet it seems the
> solutions have been found. If that is the main issue I am happy to have
> discussion with people working on CUDA to understand their process better
> and adapt whatever necessary.
>
> Another question is how will we handle other use cases - like importing
> SPIR-V modules and compiling into let's say AMD GPU binary? Can we use the
> external tool for these cases?
>
> >As an alternative, you could maintain your SPIR-V target entirely out of
> tree as your own fork of Clang. That way, you get to ensure that your Clang
> fork and the version of LLVM IR that your tool accepts stay in sync.
>
> As for the current OpenCL C++ support and development of other new
> features in OpenCL, what target can we use to develop new code? My team
> doesn't work for AMD so targeting AMD is not an option for us and some
> other teams have the same problem with out of tree backends. Old SPIR is
> discontinued by Khronos to be replaced by SPIR-V eventually. Would adding
> Clang triple at least be something acceptable in the main code base? This
> would allow us to continue developing the main frontend features in the
> main code base.
>
> Cheers,
> Anastasia
>
> ------------------------------
> *From:* Richard Smith <richard at metafoo.co.uk>
> *Sent:* 14 September 2018 00:04
> *To:* Anastasia Stulova
> *Cc:* Tom Stellard; Clang Dev; nd; Sumner, Brian
> *Subject:* Re: [cfe-dev] [llvm-dev] [RfC] A proposal of adding SPIR-V
> Toolchain in Clang
>
> Clang is the C language family frontend for LLVM. You will need extremely
> strong justification if you want Clang to support a target that LLVM does
> not support.
>
> An external tool seems to provide a *vastly* worse experience for our
> users than an integrated LLVM backend. For example, for a user who builds a
> particular SVN revision of Clang and LLVM, how are they to determine the
> corresponding revision of llvm-spirv that accepts the LLVM IR produced by
> that version of LLVM? How often will such a version of llvm-spirv even
> exist? If llvm-spirv is lagging behind LLVM trunk (as I would expect it to
> if it's maintained out-of-tree), would that mean that people who track
> clang and LLVM trunk (which is a thing we encourage people to do) can't use
> it?
>
> I still don't see why SPIR-V should be treated as being any different from
> any other target that Clang can compile for. Everyone wants to believe that
> their own target or feature or build mode is special and different, but if
> we actually go down that path the result will be an unmaintainable mess. We
> have infrastructure for the precise purpose of allowing targets to specify
> how to lower LLVM IR to their desired format. You should use it rather than
> inventing a new approach. And if it doesn't fit your target, you should
> generalize it until it does. Yes, this is more work for you, but the end
> result is better for everyone.
>
> As an alternative, you could maintain your SPIR-V target entirely out of
> tree as your own fork of Clang. That way, you get to ensure that your Clang
> fork and the version of LLVM IR that your tool accepts stay in sync. I'd
> prefer you don't take that path, and that you make SPIR-V a proper LLVM
> backend instead.
>
> On Thu, 13 Sep 2018 at 12:00, Anastasia Stulova via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> I feel this thread is now diverging into various directions. I agree that
> exploring available alternatives is important. But at this point I would
> like to be clear first about the problems with the current solution in the
> format of an external tool proposed here?
>
>
> Just to highlight, after the last discussion on llvm-dev
> http://lists.llvm.org/pipermail/llvm-dev/2018-February/121440.html we
> were working on this last idea that seems to be extremely light weight and
> nearly transparent for the LLVM community:
>
> - The tool is a part of an external repo and doesn't reside in the LLVM
> space at all.
>
> - Clang will have a thin layer of extra toolchain with the translator tool
> invocation bypassing the backend stage (only driver actions will be tested
> and generated IR if needed, no installation of the tool in the LLVM
> workspace will be required).
>
>
> Also to highlight some extra points to consider:
>
> - Producing SPIR-V binary is only one set of the use cases we would like
> to cover. We also would like to be able to import SPIR-V modules and
> further perform the end binary generation (for example for AMD GPU), for
> which we still need to invoke the tool for reverse translation
> (SPIR-V2LLVMIR). More details are in
> https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang
>
> - Clang users need a target that opens a path to proprietary backends for
> OpenCL (which most of backends are!) without going into vendor toolchains. Current
> SPIR triple is unsupported by the new OpenCL standards.
> - SPIR-V is a higher level format than PTX because it doesn't target just
> one GPU family but a number of very different devices: GPUs, DSPs, FPGAs,
> custom accelerators. In fact in some cases it's even higher level than LLVM
> IR (It doesn't have any target info, for example).
> - Several vendors were looking into SPIR-V backend and even prototyped
> this approach. The conclusion was it is not very suitable conceptually and
> therefore has extra complications if compared to traditional backend (not
> to say about the implementation effort). The benefits are very unclear to
> us apart from the integration with the rest of LLVM (OpenCL frontend
> mainly). But for this we would like to get some flexibility in order not to
> be forced to do something that might not be suitable to us.
>
> Let me know if any further elaboration is needed for those topics. Also we
> had a number of threads about the SPIR-V backend before. Here is the link
> to one of the old ones:
> http://lists.llvm.org/pipermail/llvm-dev/2015-June/086905.html
>
> Cheers,
> Anastasia
>
>
> ------------------------------
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Richard
> Smith via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* 13 September 2018 02:08:04
> *To:* Tom Stellard
> *Cc:* llvm-dev; nd; Clang Dev; Sumner, Brian
> *Subject:* Re: [llvm-dev] [cfe-dev] [RfC] A proposal of adding SPIR-V
> Toolchain in Clang
>
> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-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/cfe-dev/attachments/20180914/27bdb390/attachment.html>
More information about the cfe-dev
mailing list