<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hey Chandler!<br>
<br>
I think one of the issues we have from a SPIR-V side is that we
don't have any of the usual LLVM community heavyweights on-board to
work with us, which in turn means the community is more likely to be
resistant to any of the changes we would need to make that would
affect every backend, which is understandable.<br>
<br>
Given that the WebAssembly effort seems to have more of the usual
suspects in the LLVM community invested in working on it, and they
are likely to encounter at least some of the same problems that an
eventual SPIR-V backend would also have to deal with, I sincerely
hope that when we do come to integrate a SPIR-V backend in the
future some of the harder refactors are already done ;]<br>
<br>
Cheers,<br>
-Neil.<br>
<br>
<div class="moz-cite-prefix">On 07/07/15 17:55, Chandler Carruth
wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KghcMVwsLB0Yt+AvLex94jXsb-R8AJ=NCUiW=1qU61FDA@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" 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
moz-do-not-send="true" 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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
>>> <mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a><br>
>>> <mailto:<a moz-do-not-send="true"
href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>>>
wrote:<br>
>>><br>
>>> *From:* Mehdi Amini [mailto:<a
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>
<mailto:<a moz-do-not-send="true"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>
<mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" rel="noreferrer"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" rel="noreferrer"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a> <a
moz-do-not-send="true" href="http://llvm.cs.uiuc.edu"
rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>