<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<font size="2"><span style="font-size:11pt;"><br>
> I also think that having it in an external project will greatly reduce the visibility in comparison to a target. How many of you have cloned libclc for example?
</span></font><br>
<br>
The idea is to have it as a tool in the LLVM project space. This means it will become a part of the overall LLVM project but as an optional code base to the main LLVM backend code base. I don't think this affect visibility that much. For example, Clang is also
a tool project of LLVM and it's just as popular as LLVM. It is only a matter of how useful it would be. We are convinced there are enough users of SPIRV converter at the moment for this to be adopted as a component of the LLVM overall infrastructure.<br>
<br>
Cheers,<br>
Anastasia<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Nicholas Wilson via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> 21 February 2018 09:58<br>
<b>To:</b> Tomeu Vizoso<br>
<b>Cc:</b> LLVM Developers<br>
<b>Subject:</b> Re: [llvm-dev] SPIRV-LLVM as an external tool</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">I agree that having the conversion live as part of LLVM is the best option going forward.<br>
<br>
libclc is an library implementation of the OpenCL builtins and I think its fine for that aspect of the converter,<br>
i.e. consumption of SPIR-V into LLVM IR in preparation for code generation by LLVM by its various backends as a library<br>
to link the generated code to, to live in an external repo.<br>
<br>
This is fine because SPIR<->LLVM IR is trivial, SPIR-V<->LLVM is not.<br>
<br>
Having the SPIR-V <-> LLVM-IR conversion part of the tool as an external repo as opposed to the llvm would<br>
make it very difficult to use as a fontend:<br>
<br>
First the changes to the build pipeline are a hinderance. In my fork of SPIRV-LLVM the backend is a target<br>
because I couldn’t get CMake to link the libraries to LDC as a support library. This would be made even more
<br>
complicated with at external project. I would probably resort to invoking an external program despite integrated
<br>
conversion being the best solution.<br>
<br>
Secondly (unless you've changed things) all of the builtins are not intrinsics, but C++ Itanium with extensions mangled.<br>
This makes it so that anyone not implementing a C++ frontend has to deal with it, presumably by hardcoding the
<br>
names since C++ is very non-trivial. Even for projects like LDC (the LLVM based D compiler) which have a C++ mangler,<br>
we still have to hardcode the names because Windows does not use Itanium and the compiler is not set up to do two<br>
different forms of C++ mangling, and even if that were possible the non-standard extensions make it infeasible.<br>
Whereas any LLVM frontend worth is salt has a way of exposing intrinsics.<br>
<br>
The backend as it currently stands is not based on tablegen and that is required AFAIU to support intrinsics.<br>
I have tablegen descriptions of the SPIR-V format mostly complete (all core instruction relevant to OpenCL +<br>
most of the ones for Vulkan, + all the OpenCL extension instructions) though not the intrinsics.
<br>
However I didn’t get around to using them because I have more important things to work on in the front end.<br>
<br>
Then there is the question of what to do about Vulkan? I would love to have support for Vulkan in LLVM.<br>
That would be relatively simple to set up for with SPIRV as a target, even more so with a tablegen based
<br>
infrastructure. I have no idea how that would work as an external project.<br>
<br>
I also think that having it in an external project will greatly reduce the visibility in comparison to a target.<br>
How many of you have cloned libclc for example? Not many I suspect. Probably because you are not
<br>
working on implementing OpenCL for a backend. And while libclc is useful to those implementing OpenCL<br>
they are vastly outnumbered by those using OpenCL i.e. producing SPIR/SPIR-V. My usage of SPIR-V is<br>
I generate it from my source files though LDC/LLVM then I hand it off to the OpenCL implementation.
<br>
Nowhere in that pipeline do I need something like libclc. Now libclc may be used in the implementation
<br>
but that’s a different copy of LLVM to the one that produced it.<br>
<br>
TL;DR.<br>
<br>
This really needs to be a target so that we can use intrinsics, have it as part of regular LLVM releases<br>
so that it can be used by many frontends. Having an external project for assisting backends consuming<br>
SPIR-V (a la libclc) is fine but that shouldn’t mean that the processes used for generating SPIR-V need to go<br>
into a separate project.<br>
<br>
Nic <br>
<br>
> On 21 Feb 2018, at 4:15 pm, Tomeu Vizoso via llvm-dev <llvm-dev@lists.llvm.org> wrote:<br>
> <br>
> Hi,<br>
> <br>
> for a few months already I have been asking around for opinions on how<br>
> people could best work together on Khronos' SPIR-V <-> LLVM-IR converter<br>
> and some consensus seems to have formed.<br>
> <br>
> Most of the people I talked to favored having the converter become an<br>
> external tool within the LLVM project, similar to libclc. I think that<br>
> the LLVM project's processes, infrastructure and community form the best<br>
> place for this collaboration to happen.<br>
> <br>
> I hope that having the converter as part of LLVM can help expand LLVM's<br>
> value proposition in heterogeneous computing, in part by complementing<br>
> the OpenCL C backend in clang.<br>
> <br>
> Thus I would like to ask what the LLVM community needs to see from us<br>
> before SPIRV-LLVM can be accepted as an external tool, if at all.<br>
> <br>
> Thanks,<br>
> <br>
> Tomeu<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> llvm-dev@lists.llvm.org<br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>