[llvm-dev] SPIRV-LLVM as an external tool

Martin J. O'Riordan via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 6 13:17:58 PST 2018


I am one of these users.

 

Ideally (for my audience), I would like to be able to emit SPIR-V from the
Front-End natively, and then consume SPIR-V in the back-end natively.

 

While working with an intermediate externalised tool that converts between
LLVM-IR and SPIR-V is workable, it is not at all convenient.  At the very
least, it would be desirable to have an option; '-emit-spirv' for example;
that allowed the FE to produce SPIR-V analogous to how '-emit-llvm' works
today.

 

And on the other end, it would also be convenient if the Back-End could
accept SPIR-V as an accepted source format, perhaps using an community
agreed convention for the file's extension.

 

But even if CLang/LLVM were merely to invoke the external conversion
automatically, this would be more-or-less adequate to ensure a seamless
SPIR-V development pipeline (my preference is integrated).

 

It also opens up the opportunity for 3rd party DSL front-end developers to
engage with LLVM without being concerned about future versionability.

 

            MartinO

 

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Anastasia Stulova via llvm-dev
Sent: 06 March 2018 18:54
To: Chris Lattner <clattner at nondot.org>
Cc: llvm-dev at lists.llvm.org; nd <nd at arm.com>; Tomeu Vizoso
<tomeu.vizoso at collabora.com>
Subject: Re: [llvm-dev] SPIRV-LLVM as an external tool

 

Hi Chris,

 

The main benefit for LLVM to include SPIRV support directly is to increase
the number of users and developers in the area of heterogeneous computing,
e.g. GPUs, FPGAs, DSPs. 

 

We want to increase the number of such devices that LLVM natively supports
by adding compilation to SPIRV due to the shortage of proprietary backends
in upstream LLVM.


Just to clarify we are currently suggesting to integrate the converter as a
subproject of LLVM, similar to Clang or libclc, to reduce the overhead for
the overall community in maintaining it and running tests. 

 

One more thing to be mentioned, the latest OpenCL standards evolve towards
off-line compilation from OpenCL C++ to SPIRV. So having SPIRV generation
directly in LLVM would allow us to deliver fully complete and compliant
OpenCL C++ support, without using any external tools. See discussion with
Tom earlier.

 

Thanks!

Anastasia

 

  _____  

From: Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org> >
Sent: 01 March 2018 01:52
To: tstellar at redhat.com <mailto:tstellar at redhat.com> 
Cc: Anastasia Stulova; Tomeu Vizoso; llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org> ; nd
Subject: Re: [llvm-dev] SPIRV-LLVM as an external tool 

 

On Feb 27, 2018, at 10:25 AM, Tom Stellard via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:
> On 02/27/2018 05:07 AM, Anastasia Stulova wrote:
>>> SPIR-V does not have to be a part of LLVM for you to do this.  You can
add
>>> the SPIR-V target to clang and then define a SPIR-V toolchain (i.e.
clang/Driver/Toolchains)
>>> that uses the external tool to translate LLVM IR to SPIR-V.
>> 
>> 
>> Ok. I guess if Clang community accepts this way, it would be better to
set up the SPIRV converter as a tool of LLVM.
>> 
>> So the question is are there any downsides of this? Or would anyone
object if we add the converter to the LLVM project as an optional tool? We
would of course take care of configuring and maintaining it ourselves.
> 
> There is no requirement that the tool needs to be an official part of the
LLVM
> project to implement to use it this way  For example, the cuda toolchain
> in clang relies on a few proprietary tools from NVIDIA.
> 
> I think too much emphasis is being placed on having this tool be part of
the
> LLVM project.

Agreed.  Why is it good for LLVM to include this tool?

If there was a strong rationale for doing so, it would probably make sense
to be a new subproject of some sort rather than included in the main llvm
repo (not sure if that is what was being proposed).

-Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/6ae8f58d/attachment.html>


More information about the llvm-dev mailing list