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

[Nick Lewycky]

On 17 May 2015 at 00:13, Owen Anderson <resistor at mac.com> wrote:

>
> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <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.
>

What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get
identical .bc back? Can I take spir-V -> .bc -> spir-V and get identical
spir-V back? If both of these are not true, in what way is it a
serialization format? Or put another way, even if we call it a
serialization format, it wouldn't be a serialization format of LLVM IR.

Note that even the CPPBackend is in lib/Target, and that does guarantee
perfect round-trip reproduction of everything in LLVM IR, while SPIR-V
afaik does not.

If it makes sense share to share code (opcode tables, etc.) between the
spir-v frontend and backend, then I have no real problem putting them in a
single directory. I just want it to be clear that we can continue to freely
evolve LLVM IR and that there may be explicit steps to convert future LLVM
IR to SPIR-V and vice versa, and a place to put that code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/9a7f61c3/attachment.html>