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

Pete Cooper
Mon, 18 May 2015 21:35:50 -0000

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