<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 May 2015 at 00:13, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></div></blockquote></div><br></span><div>I don’t think Chris was suggesting lib/Bitcode/SPIRV.  That wouldn’t make a lot of sense, since Bitcode != SPIR-V.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>