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

[Pete Cooper]

> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> On Sun, May 17, 2015 at 12:13 AM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
> 
>> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com <mailto:Yaxun.Liu at amd.com>> wrote:
>> 
>> I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V target allows Clang and other LLVM front ends to target generic OpenCL/Vulkan platforms.
> 
> I don’t think Chris was suggesting lib/Bitcode/SPIRV.  That wouldn’t make a lot of sense, since Bitcode != SPIR-V.
> 
> FWIW, I agree with Chris that it makes sense as a parallel to lib/Bitcode.  SPIR-V is (almost) an alternate encoding of LLVM IR, with a few things added/removed, and it makes sense to treat it in a similar manner to our normal serialization format.
> 
> 
> From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV).
> 
> So it sounds like having some "target-like" component for SPIR-V will be necessary to ease integration with regular clang flow. It might be that we have generic SPIR-V support factored out into lib/SPIRV, and then lib/Target/SPIRV for the logic that integrates with clang.
I agree.  I haven’t looked in to the SPIRV spec, but if its only intended to support GPU graphics/compute workloads then i doubt it supports everything the IR bitcode/ll code supports.  That makes it feel more like a target to me.

That is, is it appropriate to add lib/SPIRV as a serialization format when it doesn’t support all of LLVM IR?  Targets can crash if they are fed code they don’t support, but I don’t like the sound of the file emitter crashing because the IR contained a function pointer.

BTW, i’m not arguing against SPIRV in LLVM.  I think it would be a great addition, just that we should be careful in making sure that everyone is ok with it not supporting all IR constructs but still being a first class serialization format.

Cheers,
Pete
> 
> -- Sean Silva
>  
> —Owen
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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