<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 1 May 2017, at 11:53 pm, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
</blockquote>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class="">> First of all you may want to review the thread from a few years ago about putting a SPIR-V target into LLVM: </font></pre>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica;" class="">> </span><a href="http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html" style="font-family: Helvetica;" class="">http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html</a></pre>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class="">Thanks I will take a look.</font></pre>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class="">> The fact that the SPIR-V target translates LLVM IR to SPIR-V directly and
> does not use SelectionDAG/MachineInstrs or any of the standard lowering
> mechanism is a strong case against having it in lib/Target. </font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" style="white-space: pre-wrap;" class="">Can you even use tablegen as a not target for generating binary format descriptions and intrinsics (serious question)?</font><span style="white-space: pre-wrap; font-family: Helvetica;" class=""> I think it will require a custom tablegen backend anyway though. One of the primary reasons for being a target is that we can have intrinsics that map directly to core and OpenCL/Vulkan extension </span><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">instructions, as opposed to the mangling hacks used at the moment, which hurt use by anyone who can’t mangle C++ and windows users because it doesn’t make ANY sense to mangle some stuff as Itanuinm and some stuff as MS.</span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">I am in the process of trying to make it “more traditional” where possible and it makes sense to do so, </span></font><span style="white-space: pre-wrap; font-family: Helvetica;" class="">but I do not fully understand the backend pipeline and am just trying to express the intrinsics and binary format with tablegen at the moment. Regardless of the actual transformation pipeline used I think it should go in target for the advantages stated above, and the one that I missed was, it has its own target </span><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">triples! Also IIRC the Mill CPUs will/(do?) only use one or two of the backend passes and I can’t imagine them not being considered targets.</span></font></pre>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class="">>There are
> two solutions for this: have the code live outside of lib/Target or as an
> out-of-tree project(maybe as part of SPIRV-Tools[1]) or rewrite it to use
> the standard lowering mechanism of LLVM.</font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">The first loses the advantages of being a target, the second loses that and the advantages of more eyes of LLVM devs AND staying in sync with the rest of the codebase, not to mention releases! And I can’t see any advantages gained from either of those two possibilities.
>In my opinion, doing LLVM IR->SPIR-V directly is a better option than
>trying to convert it to a proper LLVM target. SPIR-V is too high level
>to be able to gain any advantage from using LLVM's standard lowering
>mechanism.
>
>You will lose a lot of the type information going through the
>SelectionDAG/MachineInstr layers, which is a major disadvantage. Also,
>since almost everything is legal in SPIR-V, you won't be getting the
>same kind of advantages from it as other targets.
>
>SPIR-V and LLVM IR are actually fairly similar in terms of what level of the
>compiler stack the were designed for, so I think doing a simple
>LLVM IR -> SPIR-V conversion will be the easiest and give you the best
>results in the the end.</span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">Perhaps, I do not understand the backend pipeline, but that is entirely orthogonal to targethood.
>Also, if you are able to integrate it into SPIR-V Tools you will be able
>to re-use the existing SPIR-V in memory representation and the
>reader/writer APIs.</span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">The in memory representation is already there (inherited from SPIRV-LLVM) and will be refined once the tablegen work is complete, i.e. redundant code removed and integration with the tables. </span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">>I realize that having a separate library will make this more difficult to
>integrate into clang, but there are other targets that use external tools
>for linking/assembling so, you may be able to find a way to write a SPIR-V
>driver for clang that called out to this external tool for the
>LLVM IR -> SPIR-V phase.</span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap; font-family: Helvetica;" class="">An external library looks to get the worst of all worlds. I have no interest in clang, as my work is for LDC. The external library approach would require me writing a driver for LDC and then someone else writing a driver for clang, duplicating both code AND effort/bug fixes across multiple projects. There is already enough to do w.r.t metadata for the producer without having to alter their compilation pipeline as well. I plan to reduce the dependance on metadata as much as possible, but still. </span><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">
</span></font></pre>
<pre style="background-color: rgb(255, 255, 255);" class=""><font face="Helvetica" class=""><span style="white-space: pre-wrap;" class="">Nic</span></font></pre>
<div class=""><br class="">
</div>
</div>
</body>
</html>