<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 15, 2015 at 11:50 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 May 2015, at 17:53, Chris Bieneman <<a href="mailto:beanz@apple.com">beanz@apple.com</a>> wrote:<br>
><br>
> +1 to lib/Target/SPIRV/(Reader|Writer)<br>
><br>
> I really like this idea. I’ve talked with some people on both the LLVM and Khronos sides and I really think adding SPIR-V support to LLVM as an optional program serialization format would be fantastic. I think it would make it even easier for LLVM-based tools to be integrated into GPU authoring and execution pipelines.<br>
<br>
</span>Agreed.  Unlike HSAIL, SPIR-V looks like a very sane design and having an in-tree serialisation format that’s stable across LLVM versions is likely to make SPIR-V useful for a number of things outside of its initial scope.<br></blockquote><div><br></div><div>I want to point out that being stable across LLVM versions means that LLVM will be able to express things that SPIRV cannot. Any new IR feature we add to LLVM may not be expressable in SPIRV. EH landingpads, for example, are probably not supported by SPIRV and must be stripped or rejected.</div><div><br></div><div>So, the process of writing SPIRV will strip, lower, or reject some LLVM IR bits. However, roundtripping IR through SPIRV should probably be idempotent. The first translation will change the program, but repeating the roundtrip should produce the same IR and SPIRV from then on. If that's achievable, then I agree, this is definitely a serialization format and not something lower-level (x86) or higher-level (C).</div><div><br></div><div>Sounds useful. :)</div></div></div></div>