<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 21, 2015, at 8:03 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On May 20, 2015, at 7:13 AM, Neil Henning <<a href="mailto:llvm@duskborn.com" class="">llvm@duskborn.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">On 20/05/15 08:37, Owen Anderson wrote:<br class=""><blockquote cite="mid:32C1F8A8-DC99-4EC5-8C25-6A611BF38E08@mac.com" type="cite" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2015, at 7:32 PM, Sean Silva <<a moz-do-not-send="true" href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 19, 2015 at 4:05 PM, Owen Anderson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:resistor@mac.com" target="_blank" class="">resistor@mac.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2015, at 9:48 AM, Neil Henning <<a moz-do-not-send="true" href="mailto:llvm@duskborn.com" target="_blank" class="">llvm@duskborn.com</a>> wrote:</div><br class=""><div class=""><span class="" 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;">The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.</span><br class="" 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;"></div></blockquote></div><br class=""></span><div class="">This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM. The clang driver is part of the LLVM project. If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that. If a particular frontend vendor wants to customize the flags, they can always do so themselves.</div></div></blockquote><div class=""><br class=""></div><div class="">What do you envision as the triple and datalayout when a frontend is compiling to SPIR-V?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’d recommend having its own Triple. Not that triples are *not* linked to targets in LLVM. My understanding of SPIR-V (and a look through the documentation seems to confirm) that it doesn’t specify anything about data layouts, presumably because it needs to accommodate both many GPUs with varying ideas of what sizes and alignments should be. If anything this pushes me even more strongly that you do *not* want to run SPIR-V-destined IR through any more of LLVM (and particularly the CodeGen infrastructure) than you have to, since a lot of that will want to bake in DataLayout knowledge.</div></div></blockquote><br class="">At present in SPIR-V we have a decoration for alignment, so a user could decorate a type to specify a required alignment (which I would have thought in turn would become part of the data layout). Also if we are using a non-logical addressing mode the data layout would have a different pointer width specified (similar to the SPIR/SPIR64 targets in Clang at present). I'll bring it up with the SPIR group at Khronos what the expected behaviour of the alignment decoration is in this context, but at present I would say it would be legal for an LLVM module that is being turned into SPIR-V to have a user-defined data layout.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?</div></div></div></blockquote><div><br class=""></div><div>Sorry, I’m just catching up on this thread, but I wanted to answer this question. I think it is reasonable that you could go frontend->IR->optimizer->IR->SPIR-V with one big caveat.</div><div><br class=""></div><div>If I understand correctly from the SPIR-V spec, SPIR-V has some strict requirements. One of them is that control flow needs to be minimally structured. IR doesn’t have the same requirement, and some of our optimization passes may not preserve control flow structure (I’m looking at you jump threading). This means that prior to writing SPIR-V there will probably need to be either a verification step to ensure that the IR can be serialized to SPRI-V, or a fix-up step to make it serializable.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.</div><div class=""><br class=""></div><div class="">If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?</div><div class="">The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><br class=""><blockquote cite="mid:32C1F8A8-DC99-4EC5-8C25-6A611BF38E08@mac.com" type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">I'm pretty sure that a wide class of frontends for SPIR-V will literally be interested in just generating SPIR-V, with no knowledge about what the ultimate GPU target is; it is in that sense that they are "targeting" SPIR-V. That is, their frontend isn't generating $SPECIFICGPU targeted IR, and then being merely asking to have it serialized in a specific way (a la -emit-llvm); they are generating IR that is meant to be turned into SPIR-V. That is fundamentally different from -emit-llvm (on the other hand, it may not be a target; but it sure smells like one).</div></div></div></div></div></blockquote><div class=""><br class=""></div>I completely agree with you… except for the last sentence.</div><div class=""><br class=""></div><div class="">Honestly, the command line option aspect of this seems like a complete red herring to me. We are talking about adding support to a data format which we will need to support both serializing IR to and deserializing IR from. This is exactly the same as the bitcode use case, and not at all like the use case of a target. We should structure the implementation according to the ways it will actually be used; rewiring a clang driver command line flag to “make it look pretty” is the most trivial part of the entire process.</div></blockquote><br class="">So it seems to me that we can at least agree on the location of the mainstay of the code - it should reside in lib/SPIRV and be both a<span class="Apple-converted-space"> </span> <span class="Apple-converted-space"> </span> <span class="Apple-converted-space"> </span>reader and writer akin to the Bitcode reader/writer pair. Why don't we at Khronos work on a patch to tip LLVM that will do that, and then we can revisit how a user actually uses our code after that. We should be able to easily follow Owen's approach and see how that works out, worst case if it turns out to not work it would then be trivial to turn that into a thin backend. Seem reasonable?<br class=""><br class="">Cheers,<br class="">-Neil.<br class=""></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:LLVMdev@cs.uiuc.edu" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">LLVMdev@cs.uiuc.edu</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span> </span><a href="http://llvm.cs.uiuc.edu/" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://llvm.cs.uiuc.edu</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br class=""></body></html>