<div dir="ltr">Sorry I've not updated this thread more often.<br><br><div>One thing I want to clarify something for other (possibly future) readers of the email thread to avoid confusion. I don't think the SPIR folks have misunderstood, but context is always hard to convey. =]</div><div><br></div><div>I'm not pushing for using the machinery for the sake of using it. That wouldn't make sense. I think there are specific reasons why the *legalization* machinery (in whatever form that takes) should be common across backends. This primarily to help ensure that a growing number of LLVM backends doesn't make changing the core or common parts of LLVM intractably hard by consolidating and unifying the infrastructure which provides minimally correct functionality for a backend.</div><div><br></div><div>I worry there are similar maintenance concerns with not having an MC-based encoding layer, but I'm not as deeply familiar with MC so I would defer to others there.</div><div><br></div><div>I also want to make it clear that I'm not under any illusion that these layers are really in good shape to serve the needs of SPIR-V, or other virtual ISAs. I think that *any* of the virtual ISA backends currently being developed will end up needing to do non-trivial work to refactor and improve these layers of LLVM in order to make them a better fit.</div><div><br></div><div>As much as I'd like to have SPIR-V in the tree (and I would), I'm honestly happier to see appropriate planning for the amount of work that will likely be required. I think that means that when it does come into the tree, it will be a much healthier experience.</div><div><br></div><div>-Chandler</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 7, 2015 at 8:04 AM Neil Henning <<a href="mailto:llvm@duskborn.com">llvm@duskborn.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Tom,<br>
<br>
Really it was at the behest of the replies - we got a lot of feedback<br>
from the mailing list that indicated we'd be putting extra workload of<br>
people changing features of the IR if we didn't follow the same<br>
mechanisms of the other backends (mostly led by Chandler's very astute<br>
comments on the subject).<br>
<br>
Cheers,<br>
-Neil.<br>
<br>
On 07/07/15 14:43, Tom Stellard wrote:<br>
> On Tue, Jul 07, 2015 at 10:17:20AM +0100, Neil Henning wrote:<br>
>> So we have been in discussions within the Khronos SPIR-V work group on<br>
>> our push to get our SPIR-V code into tip LLVM and have drawn the<br>
>> following conclusions;<br>
>><br>
>> * We absolutely must create a fully fledged backend that uses all the<br>
>> machinery that target backends are expected to use.<br>
> Can you give details on how you reached this conclusion? Why was this<br>
> determined to be better than the alternatives?<br>
><br>
> Thanks,<br>
> Tom<br>
><br>
>> * We probably have to split out the SPIR-V -> LLVM IR into a separate<br>
>> project from LLVM ala Clang et al.<br>
>><br>
>> As we want to allow developers to use the SPIR-V production/consumption<br>
>> code now, and the time sink doing the above approach would incur, we are<br>
>> going to open source the current work on the Khronos GitHub page as a<br>
>> first step.<br>
>><br>
>> We intend to revisit introducing a SPIR-V backend to LLVM in the future.<br>
>><br>
>> Cheers,<br>
>> -Neil.<br>
>><br>
>> On 18/06/15 20:25, Liu, Yaxun (Sam) wrote:<br>
>>> *From:*Eli Bendersky [mailto:<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>]<br>
>>> *Sent:* Thursday, June 18, 2015 1:43 PM<br>
>>> *To:* Mehdi Amini<br>
>>> *Cc:* Liu, Yaxun (Sam); <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a><br>
>>> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target<br>
>>><br>
>>> On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
>>> <mailto:<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>>> wrote:<br>
>>><br>
>>> On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a><br>
>>> <mailto:<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>>> wrote:<br>
>>><br>
>>> *From:* Mehdi Amini [mailto:<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>]<br>
>>> *Sent:* Thursday, June 18, 2015 11:24 AM<br>
>>> *To:* Liu, Yaxun (Sam)<br>
>>> *Cc:* <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a> <mailto:<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
>>> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target<br>
>>><br>
>>> On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam)<br>
>>> <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a> <mailto:<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>>> wrote:<br>
>>><br>
>>> Hi Mehdi,<br>
>>><br>
>>> Thank you for your comments. My comments are below.<br>
>>><br>
>>> Sam<br>
>>><br>
>>> *From:* Mehdi Amini [mailto:<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>]<br>
>>> *Sent:* Wednesday, June 17, 2015 12:43 PM<br>
>>> *To:* Liu, Yaxun (Sam)<br>
>>> *Cc:* <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a> <mailto:<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
>>> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target<br>
>>><br>
>>> Hi Liu,<br>
>>><br>
>>> Thanks for the detailed proposal.<br>
>>><br>
>>> On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam)<br>
>>> <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a> <mailto:<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>>> wrote:<br>
>>><br>
>>> Here is the revised proposal for the LLVM/SPIR-V<br>
>>> converter. Please comment. Thanks.<br>
>>><br>
>>> Proposal of Adding SPIRV Target<br>
>>><br>
>>> Background<br>
>>><br>
>>> SPIR-V is a portable binary format for OpenCL kernels and<br>
>>> GLSL shaders. A typical use case of SPIR-V is as follows:<br>
>>><br>
>>> 1.An application developer uses Clang to compile an OpenCL<br>
>>> kernel source code to a SPIR-V binary which is common for<br>
>>> all OpenCL platforms.<br>
>>><br>
>>> 2.The application developer ships the application<br>
>>> containing the SPIR-V binary to customers.<br>
>>><br>
>>> 3.A customer runs the application on an OpenCL platform,<br>
>>> which loads the SPIR-V binary through an OpenCL API function.<br>
>>><br>
>>> 4.The vendor-specific OpenCL runtime translates SPIR-V to<br>
>>> LLVM IR, changes the target triple and data layout to suit<br>
>>> the device which will execute the kernel, performs target<br>
>>> specific optimizations, generates the ISA and executes the<br>
>>> ISA on the device.<br>
>>><br>
>>> Step 4 of your “typical use case” includes "changes the target<br>
>>> triple and data layout to suit the device which will execute<br>
>>> the kernel”. It implies that SPIR-V is data layout agnostic<br>
>>> since you can load it with any data layout, or there are (to<br>
>>> be specified) constraint on what a “compatible” data layout<br>
>>> is, or you considered that it is up to the OpenCL vendor to<br>
>>> figure out what will work or not, with the drawback that any<br>
>>> LLVM update can break its use case.<br>
>>><br>
>>> + For OpenCL, LLVM IR translated from SPIR-V has specific data<br>
>>> layouts, which are the data layouts for target spir/spir64.<br>
>>> OpenCL vendor’s target data layout are assumed to be<br>
>>> consistent with them.<br>
>>><br>
>>> For OpenCL kernels, there is implicit data layout dependence<br>
>>> when compiling the source to LLVM. Since SPIR-V is for common<br>
>>> OpenCL platforms, a common data layout accepted by different<br>
>>> OpenCL vendors is required. We choose the data layout which<br>
>>> has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been<br>
>>> successfully used for supporting consumption of SPIR 1.2/2.0<br>
>>> on various OpenCL platforms. For GLSL shaders, it is still<br>
>>> under discussion whether to choose the same data layout as<br>
>>> OpenCL, or a different data layout, or no data layout at all.<br>
>>><br>
>>> Location<br>
>>><br>
>>> From feedback of the previous version of the proposal, there<br>
>>> are several suggestions about the location for the LLVM/SPIR-V<br>
>>> converter:<br>
>>><br>
>>> 1.llvm/lib/SPIRV only, adding an option to Clang for<br>
>>> outputting SPIR-V. The advantage is ease of use for bi-way<br>
>>> translation. However it does not reflect the fact that only<br>
>>> LLVM IR with specific target triple and data layout can be<br>
>>> translated to SPIR-V.<br>
>>><br>
>>> How important is it to “reflect it”?<br>
>>><br>
>>> The SPIR-V emitter could just assert on the data layout<br>
>>> matching what is expected.<br>
>>><br>
>>> + Putting the converter at llvm/lib/SPIRV may encourage misuse<br>
>>> of the converter, i.e., using the converter to convert LLVM IR<br>
>>> of arbitrary target, whereas the converter can only convert<br>
>>> LLVM IR with spir/spir64 target.<br>
>>><br>
>>> I don’t know how the discussion about SelectionDAG impact your plan.<br>
>>><br>
>>> If the IR -> SPIR-V path is implemented as a “regular” target<br>
>>> using the legalization framework and so on, almost all the code<br>
>>> will be in lib/Target/SPIRV.<br>
>>><br>
>>> However it is not clear to me why the SPIR-V -> IR path would<br>
>>> benefit in any way to be there as well?<br>
>>><br>
>>> Conceptually I should be able to compile LLVM and disable the<br>
>>> SPIR-V backend but still be able to read-in SPIR-V and target my<br>
>>> fancy OpenCL compliant device with my backend.<br>
>>><br>
>>> + The rationale is that SPIR-V is an alternative representation of<br>
>>> LLVM IR for spir/spir64 target. Therefore bi-way translation<br>
>>> between LLVM and SPIR-V is possible. Such functionality naturally<br>
>>> belongs to the target. The user who needs the translation<br>
>>> functionality needs to link to the SPIRV target library.<br>
>>><br>
>>> It doesn’t not seem “natural” to me that a “target” backend would<br>
>>> operate as a “source”.<br>
>>><br>
>>> It is not clear also what piece of the target infrastructure would be<br>
>>> helpful to convert from SPIR-V to IR.<br>
>>><br>
>>> At some point there was a C target backend, it still would seem silly<br>
>>> to implement clang as a target.<br>
>>><br>
>>> +1<br>
>>><br>
>>> It's highly unusual for lib/Target to implement X-to-LLVM-IR conversions.<br>
>>><br>
>>> Eli<br>
>>><br>
>>> OK how about let’s keep the original location. Keep the converter in<br>
>>> lib/SPIRV and add a thin wrapper in lib/Target/SPIRV for now. As<br>
>>> refactoring work goes on and lib/Target/SPIRV becomes full-fledged,<br>
>>> phase out the SPIRV writer in lib/SPIRV. This also helps keep the<br>
>>> SelectionDAG/MC implementation cleaner.<br>
>>><br>
>>> Sam<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div>