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

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.
>
>
> 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>