[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Philip Reames]

After following the thread through the rounds of discussion that have 
happened, I have serious concern about this proposal and believe that it 
should not land as proposed.  I am not opposed to the idea of SPIR, but 
the current proposal is lacking key details and could be construed to 
imply maintenance and support obligations on the community as a whole 
which are not clearly defined, much less widely discussed and agreed to.

I would suggest that interested parties need to settle on a usage model, 
what the model implies for the rest of LLVM, and come back with a more 
detailed specific proposal.

 From what I've gathered so far, it really sounds like there are two 
proposals within one here.

The first is a SPIR-frontend targeting arbitrary backends.  The usage 
model sounds like an existing SPIR program being compiled to either x86 
(say for testing purposes) or one of the existing GPU focused backends.  
To me, this sounds like the less invasive part since none of the 
concerns about data layout (or lack there of) apply.  By the time we're 
compiling a SPIR program to a particular target, we should be able to 
optimize using target specific information.  My suggestion would be to 
establish a new repository (hosted on llvm.org) which holds this 
frontend.  I have seen no reason this should live in the main llvm or 
clang repositories in the discussion to date.

The second sounds like it's a proposal to have Clang support an SPIR 
backend.  Exactly what form this would take appears to be really unclear 
and the implications for the project have not be spelled out.  In 
particular, it's not clear to me that preserving all the invariants 
needed to emit SPIR through the optimizer is even possible with our 
current IR and type system.  I would be actively opposed to seeing 
changes in this direction land without substaintial further discussion 
and active contribution/ownership by an existing active member of the 
LLVM community.

Philip

On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) wrote:
> Khronos Group SPIR WG is working on a bi-way converter between LLVM bitcode and SPIR-V (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and is willing to upstream it to the LLVM project.
>
> The bi-way converter uses a common in-memory representation of SPIR-V. It works by breaking down a module to instructions and construct the translated module in memory then output it. Currently it supports SPIR-V common instructions and OpenCL specific instructions. Supporting of other languages is under consideration.
>
> We plan to refactor the LLVM to SPIR-V converter as a backend at llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in an unconventional backend which does not use SelectionDAG/MC, we would like to know whether it is acceptable. We are open to the SelectionDAG/MC approach if the community recommends it.
>
> For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project.
>
> Any comments are welcome. Thanks.
>
> Yaxun Liu
> AMD
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev