Chris Lattner via llvm-dev
2018-Mar-01 01:52 UTC
[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> 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
Nicholas Wilson via llvm-dev
2018-Mar-01 02:42 UTC
[llvm-dev] SPIRV-LLVM as an external tool
On 1 Mar 2018, at 9:52 am, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: 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: 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). While what Tom has said may be true for clang, it is not the only frontend that wants to use this. LDC currently uses a fork of LLVM to generate SPIR-V it would be much nicer to be able to use the regular LLVM releases. The converter (the tool being proposed) is effectively both a backend (LLVM IR -> SPIR-V), albeit not a conventional one, and a frontend (SPIR-V -> LLVM IR) and therefore needs a number of things from the LLVM repo such as its own triples (and intrinsics when we move away from the current system). It being proposed as a tool is an intermediate step to a backend and a tool that calls some of the backends passes. The rationale is to: Provide a standard LLVM tooling with SPIR-V that benefits frontends through the SPIR-V backend to produce SPIR-V, and backends (CPU and GPU) through the SPIR-V frontend so that intrinsics can be translated (possibly a lá libclc?) and the triple changed and fed through the backend. Reduce the fragmentation of the SPIR-V ecosystem, I know of at least three projects aiming to provide SPIR-V tooling for LLVM. Having one central project allows coordinated effort and ensures that the SPIR-V tooling stays up to date with LLVM. Nic -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180301/f361d0b5/attachment.html>
Anastasia Stulova via llvm-dev
2018-Mar-06 18:54 UTC
[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> Sent: 01 March 2018 01:52 To: tstellar at redhat.com Cc: Anastasia Stulova; Tomeu Vizoso; 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> 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/1f58dfa7/attachment.html>
Martin J. O'Riordan via llvm-dev
2018-Mar-06 21:17 UTC
[llvm-dev] SPIRV-LLVM as an external tool
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>
Philip Reames via llvm-dev
2018-Mar-06 23:07 UTC
[llvm-dev] SPIRV-LLVM as an external tool
I've only been skimming the discussion thread so far, but so far, I see no strong reason for this to be a LLVM subproject in it's current form. I would recommend pursing a standalone open source project, building a community around the common development, and then return to this proposal once there is an existing community around an existing codebase. Until that time, I see lots of downside for LLVM in accepting this project and little benefit. Philip On 03/06/2018 10:54 AM, Anastasia Stulova via llvm-dev wrote:> > 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> > *Sent:* 01 March 2018 01:52 > *To:* tstellar at redhat.com > *Cc:* Anastasia Stulova; Tomeu Vizoso; 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> 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 > > > > > _______________________________________________ > 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/20180306/d69ef2bb/attachment-0001.html>
Thanks for your feedback Philip. Could you perhaps explain what the downsides to LLVM are of accepting this as a subproject as I can't really see any myself. Neil ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> Sent: 06 March 2018 23:07:54 To: Anastasia Stulova; Chris Lattner Cc: llvm-dev at lists.llvm.org; nd; Tomeu Vizoso Subject: Re: [llvm-dev] SPIRV-LLVM as an external tool I've only been skimming the discussion thread so far, but so far, I see no strong reason for this to be a LLVM subproject in it's current form. I would recommend pursing a standalone open source project, building a community around the common development, and then return to this proposal once there is an existing community around an existing codebase. Until that time, I see lots of downside for LLVM in accepting this project and little benefit. Philip On 03/06/2018 10:54 AM, Anastasia Stulova via llvm-dev wrote: 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 _______________________________________________ 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180308/cc90887b/attachment.html>
Philip Reames via llvm-dev
2018-Mar-14 20:46 UTC
[llvm-dev] SPIRV-LLVM as an external tool
All code requires maintenance. Additional users of existing API tends to limit their evolution. If there is not a community around a particular portion of code, that code is purely a drag on the project and community as a whole. We have a strong expectation that contributors "pay their way" in maintenance costs. At a minimum, new code must be net neutral from the communities perspective. This is a fairly high bar to clear in practice. (All of the above is generic and not specific to this particular proposal, but does address the specific question below.) On 03/08/2018 04:30 AM, Neil Hickey via llvm-dev wrote:> Thanks for your feedback Philip. Could you perhaps explain what the > downsides to LLVM are of accepting this as a subproject as I can't > really see any myself. > > > Neil > > ------------------------------------------------------------------------ > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Philip > Reames via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* 06 March 2018 23:07:54 > *To:* Anastasia Stulova; Chris Lattner > *Cc:* llvm-dev at lists.llvm.org; nd; Tomeu Vizoso > *Subject:* Re: [llvm-dev] SPIRV-LLVM as an external tool > > I've only been skimming the discussion thread so far, but so far, I > see no strong reason for this to be a LLVM subproject in it's current > form. I would recommend pursing a standalone open source project, > building a community around the common development, and then return to > this proposal once there is an existing community around an existing > codebase. Until that time, I see lots of downside for LLVM in > accepting this project and little benefit. > > > Philip > > > On 03/06/2018 10:54 AM, Anastasia Stulova via llvm-dev wrote: >> >> 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 >> >> >> >> >> _______________________________________________ >> 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 > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > _______________________________________________ > 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/20180314/57b73ecc/attachment.html>