[llvm-dev] SPIRV-LLVM as an external tool
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Wed Mar 14 13:46:41 PDT 2018
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.
> *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.
> 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.
>> *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
>> > 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).
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev