<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</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 21 Jun 2017, at 8:20 am, Tom Stellard <<a href="mailto:tstellar@redhat.com" class="">tstellar@redhat.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On 06/20/2017 05:41 PM, Neil Hickey wrote:<br class="">
<blockquote type="cite" class="">Hi all, I'd like to kick this discussion off again, and summarise the points that have been expressed so far.<br class="">
<br class="">
Firstly, as a member of Khronos, I'd like to state that this would be a very interesting development.<br class="">
<br class="">
</blockquote>
<br class="">
Hi Neil,<br class="">
<br class="">
I am very interested in having a good LLVM IR -> SPIR-V solution, and I<br class="">
think it's great that Khronos is interested in putting effort into making<br class="">
this happen, however, I disagree with the approach you have outlined<br class="">
mostly because I don't think it is the most effective use of developer<br class="">
resources.<br class="">
<br class="">
<blockquote type="cite" class="">Khronos, for those who don't know, is a standards body developing open standards for accelerating rich media content on a wide variety of platforms, including GPUs as an example.<br class="">
<br class="">
Khronos is made up of a large number of companies across a range of industries, but as an example, ARM, Google, Intel, Imagination are all members.<br class="">
<br class="">
Khronos members are already working on writing backend for llvm that retarget SPIR-V, for example, taking LLVM-IR compiled from OpenCL and targeting this at something that can accept Vulkan, so there is clear interest within the community to see this happen.<br class="">
<br class="">
</blockquote>
<br class="">
Is this code available anywhere?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><a href="https://github.com/KhronosGroup/SPIRV-LLVM" class="">https://github.com/KhronosGroup/SPIRV-LLVM</a> for a dated version (LLVM 3.6.1 and 3.8)</div>
<div>and <a href="https://github.com/thewilsonator/llvm-target-spirv" class="">llvm-target-spirv</a> and <a href="https://github.com/thewilsonator/llvm" class="">llvm</a> for my up to date (w.r.t LLVM) version.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">Firstly, there are a number of benefits to having SPIR-V in LLVM as a backend, both to SPIR-V, the ecosystem and to LLVM.<br class="">
<br class="">
* Allows any frontend targeting llvm to also target SPIR-V<br class="">
</blockquote>
<br class="">
I think people over estimate the difficulty of integrating a direct LLVM IR<br class="">
to SPIR-V translator with frontends that emit LLVM IR. All a direct<br class="">
translator does is take LLVM IR as an input and produce SPIR-V as an output,<br class="">
interacting with it is not that complicated. I think whatever challenges<br class="">
this presents would be much easier to solve than implementing a full GlobalIsel<br class="">
based backend.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I think he means in the general sense, as compared to no backend at all.</div>
<div>The only thing difficult with it is it currently stands is getting the metadata right and thats mostly lack f documentation.<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">* Improves robustness of open source tooling for SPIR-V<br class="">
* Single place for toolchain - People don't need to knit repositories together from multiple locations<br class="">
* Compatibility between LLVM and SPIR-V - As SPIR-V is integrated it will always track top of tree<br class="">
</blockquote>
<br class="">
These are advantages of having an LLVM IR to SPIR-V translator in tree,<br class="">
but you get these same advantages no matter what type of translator it is<br class="">
(e.g. direct LLVM IR to SPIR-V or GlobalISel SPIR-V backend).<br class="">
<br class="">
<blockquote type="cite" class="">* We can create a target triple to subset what dialect of SPIR-V we are targeting<br class="">
* Using the aforementioned triple we can guide optimisations that take target information<br class="">
</blockquote>
<br class="">
Defining a triple does not require a backend.<br class="">
<br class="">
<blockquote type="cite" class="">* Challenges of implementing SPIR-V backend can influence LLVM backend development, to improve LLVM usability by less conventional targets<br class="">
</blockquote>
<br class="">
SPIR-V isn't just unconventional, it's also a higher-level language than<br class="">
all the other targets, which are all closer to assembly languages.<br class="">
<br class="">
<blockquote type="cite" class="">* Benefits LLVM by improving support for GPU code generation specifically<br class="">
</blockquote>
<br class="">
I agree with this.<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
I'd also like to touch specifically on a point that I believe was originally made by Tom.<br class="">
<br class="">
If the initial implementation of the SPIR-V backend went straight for GlobalISel and only GlobalISel then we would remove the need to worry about SelectionDAG and would remove some of the complexity from the translation step.<br class="">
<br class="">
</blockquote>
<br class="">
While I think GlobalISel would be better than SelectionDAG it still is not<br class="">
a good fit for a language like SPIR-V. The main problem with both GlobalISel<br class="">
and SelectionDAG is that you are taking a high-level IR (LLVM IR), translating<br class="">
it to an low level, assembly-like IR (MachineInstr) and then translating it back to a<br class="">
high-level IR (SPIR-V). From a technical perspective, this is a much inferior<br class="">
solution than generating SPIR-V from LLVM IR directly, because you will be losing<br class="">
information in the translation that will be very difficult, if not impossible, to<br class="">
recover. It's also much more work than a direct translation to SPIR-V, so you<br class="">
will be investing extra engineering effort in order to generate worse SPIR-V.<br class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yay!</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">So as a proposal, could I suggest the following next steps?<br class="">
1) Add a dummy SPIR-V target machine to llvm, replete with target triple<br class="">
2) Implement an experimental backend making use of globalisel to target SPIR-V code generation<br class="">
3) Add tests to verify correct execution<br class="">
<br class="">
Moving forward, the plan would be to develop this into a fully featured and complete backend, with a complete set of tests, but targeting GlobalISel exclusively.<br class="">
<br class="">
</blockquote>
<br class="">
As I said before, I disagree with this approach. I don't think doing<br class="">
a GlobalIsel based SPIR-V backend is a good use of engineering resources<br class="">
nor will it produce the best quality of code.<br class="">
<br class="">
I think you should re-evaluate your goals and decide, which of your goals<br class="">
can be met by having an in-tree solution (no matter what that solution is<br class="">
direct translator, GlobalISel backend or something else), and which of your<br class="">
goals are met by having a GlobalISel-based backend. I think it's important<br class="">
to separate those two ideas, because my observation is that the reason people<br class="">
favor doing a GlobalISel or SelectionDAG based backend is because it is the<br class="">
easiest way to get something in tree, and not because it is the best technical<br class="">
solution, which is a not a good reason to make this kind of decision.<br class="">
<br class="">
>From past discussions, one of the main reasons some LLVM developers did not want<br class="">
a direct LLVM IR to SPIR-V translator in tree is that it would essentially<br class="">
be introducing a second legalization framework (or third now that we have<br class="">
GlobalIsel), which would place an increased maintenance burden on the community.<br class="">
<br class="">
There wasn't a unanimous objection from the community, however, and I think<br class="">
there is enough interest in this project that we could come up with some<br class="">
kind of solution for an in-tree direct LLVM IR translator. However, it's<br class="">
really hard to argue for a big change like this without any code or existing<br class="">
user base to show the community how the benefits of this outweigh the costs.<br class="">
<br class="">
I think a direct LLVM IR to SPIR-V translator is the best technical solution,<br class="">
this is why my recommendation is to start by taking the existing<br class="">
code that implements a direct LLVM IR to SPIR-V translator and develop it<br class="">
as its own out-of-tree project, and by out-of-tree I mean a complete separate<br class="">
project from LLVM not just a fork of it. Having an out-of-tree project<br class="">
will allow you to improve the code and build up a community, without getting<br class="">
bogged down by lengthy mailing list discussions or trying to integrate<br class="">
major changes to core LLVM infrastructure in order to accommodate your<br class="">
translator.<br class="">
<br class="">
Once you have a good solution with a strong userbase, I think you will be in<br class="">
a much better position to work with the community to come up with a solution<br class="">
to integrate your translator into the official tree.<br class="">
<br class="">
-Tom<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>