[llvm-dev] [SPIR-V] SPIR-V in LLVM

Mon Jul 17 20:18:13 PDT 2017

Yet another implementation of the backend, heh.

I’d just started in earnest writing a tablegen based one, with the main goal of fixing the intrinsics to actually be intrinsics. 
I think it would be a good idea to join forces with the folk at KhronosGroup and consolidate the work done for inclusion into LLVM.

Nic

> On 17 Jul 2017, at 9:55 pm, Neil Henning via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hey all,
> 
> Code finally got through legal, but the repo is live here https://github.com/google/clspv
> 
> This codebase is somewhere between alpha/beta as an estimate, but we've pushed a 1 million line OpenCL C codebase through it and got fully formed Vulkan SPIR-V out the other end.
> 
> I did not want to make the mistake of forking LLVM/Clang - so there are a bunch of passes in there that are us undoing things that Clang has options for (if we had a SPIRV triple).
> 
> Most of the meat of the producer is in https://github.com/google/clspv/blob/master/lib/SPIRVProducerPass.cpp
> 
> Hope this helps aid any decisions by the list.
> 
> Cheers,
> -Codeplay Neil.
> 
> On 2017-06-22 03:08, Tom Stellard via llvm-dev wrote:
>> On 06/21/2017 09:18 AM, Neil Hickey wrote:
>>> Hi Tom,
>>> I don't disagree, on a technical level, with any of your points. This is, as you have already pointed out, not the first time we have had this discussion and so far, two years after these discussions were first opened we are not any nearer to a solution that makes sense for all stake holders, hence why I think it prudent to explore other approaches, approaches that may not be the most efficient engineering solution, but approaches that allow us to make some kind of forward progress.
>>> My motivation in this is having a solution that is well integrated with tooling that the ecosystem already uses and is comfortable with. Certainly coming from OpenCL C and C++, clang is an often used tool for compiling, and this already lives within the llvm project, allowing an option in clang that anyone can add to their compile line, which seamlessly generates SPIR-V for further consumption by an OpenCL or Vulkan runtime is, in my mind, the lowest barrier for adoption, and as such, likely to be the one that gets the most traction.
>>> The barrier to getting the translator integrated into LLVM revolves around the ties that it creates between the future evolution of LLVM-IR and SPIR-V, two specifications that are controlled by different communities, whereas recasting the translator as a backend removes that tie, or at least forces the LLVM-IR to go through a lowering/ legalisation step, and also, if it breaks can be more easily disabled.
>>> Assuming the objective is to keep this in llvm for ease of use by end users, and we do not want to pursue the full backend approach, there are a number of other options we could explore.
>>> 1) Allow something like a backend to exist in LLVM, which can be switched off if it breaks, that allows for these types of translations between different intermediate languages, but doesn't have the requirement of going through MachineInstructions, i.e. it isn't really a backend. This mechanism could also have been used to target WebAssembly for example, and any other IR/ILs that we would like LLVM-IR to have a route to going forward.
>>> 2) Create a tool, in llvm/tools similar to clang that creates a library and separate tool to provide the same functionality as the LLVM<->SPIR-V translator discussed previously. This could be officially hosted, like clang, if the community felt that appropriate, and would allow easy integration of the different tools, or being called as a library, to generate SPIR-V from LLVM.
>> I think these are both possible solutions, but we aren't going to be able
>> to know which is best until there is some code to look at and review.
>> This is why I suggest moving whatever existing code there is into its own
>> public repository while it is cleaned up and improved.  I'm not suggesting
>> this as a long term solution, but just for a few months or however long it
>> takes to get clean code that builds against trunk, so that people can start
>> looking at and reviewing.
>> -Tom
>>> P.S.
>>> The OpenCL over Vulkan work I mentioned is not yet open sourced but I believe the intention is to do so "soon".
>>>> -----Original Message-----
>>>> From: Tom Stellard [mailto:tstellar at redhat.com]
>>>> Sent: 21 June 2017 01:21
>>>> To: Neil Hickey; llvm-dev at lists.llvm.org
>>>> Cc: Nicholas Wilson; nd
>>>> Subject: Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM
>>>> On 06/20/2017 05:41 PM, Neil Hickey wrote:
>>>>> Hi all, I'd like to kick this discussion off again, and summarise the points that
>>>> have been expressed so far.
>>>>> Firstly, as a member of Khronos, I'd like to state that this would be a very
>>>> interesting development.
>>>> Hi Neil,
>>>> I am very interested in having a good LLVM IR -> SPIR-V solution, and I think
>>>> it's great that Khronos is interested in putting effort into making this happen,
>>>> however, I disagree with the approach you have outlined mostly because I
>>>> don't think it is the most effective use of developer resources.
>>>>> 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.
>>>>> 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.
>>>>> 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.
>>>> Is this code available anywhere?
>>>>> 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.
>>>>> * Allows any frontend targeting llvm to also target SPIR-V
>>>> I think people over estimate the difficulty of integrating a direct LLVM IR to
>>>> SPIR-V translator with frontends that emit LLVM IR.  All a direct translator
>>>> does is take LLVM IR as an input and produce SPIR-V as an output, interacting
>>>> with it is not that complicated.  I think whatever challenges this presents
>>>> would be much easier to solve than implementing a full GlobalIsel based
>>>> backend.
>>>>> * Improves robustness of open source tooling for SPIR-V
>>>>> * Single place for toolchain - People don't need to knit repositories
>>>>> together from multiple locations
>>>>> * Compatibility between LLVM and SPIR-V - As SPIR-V is integrated it
>>>>> will always track top of tree
>>>> These are advantages of having an LLVM IR to SPIR-V translator in tree, but
>>>> you get these same advantages no matter what type of translator it is (e.g.
>>>> direct LLVM IR to SPIR-V or GlobalISel SPIR-V backend).
>>>>> * We can create a target triple to subset what dialect of SPIR-V we
>>>>> are targeting
>>>>> * Using the aforementioned triple we can guide optimisations that
>>>>> take target information
>>>> Defining a triple does not require a backend.
>>>>> * Challenges of implementing SPIR-V backend can influence LLVM
>>>>> backend development, to improve LLVM usability by less conventional
>>>>> targets
>>>> SPIR-V isn't just unconventional, it's also a higher-level language than all the
>>>> other targets, which are all closer to assembly languages.
>>>>> * Benefits LLVM by improving support for GPU code generation
>>>>> specifically
>>>> I agree with this.
>>>>> I'd also like to touch specifically on a point that I believe was originally made
>>>> by Tom.
>>>>> 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.
>>>> While I think GlobalISel would be better than SelectionDAG it still is not a
>>>> good fit for a language like SPIR-V.  The main problem with both GlobalISel
>>>> and SelectionDAG is that you are taking a high-level IR (LLVM IR), translating
>>>> it to an low level, assembly-like IR (MachineInstr) and then translating it back
>>>> to a high-level IR (SPIR-V).  From a technical perspective, this is a much
>>>> inferior solution than generating SPIR-V from LLVM IR directly, because you
>>>> will be losing information in the translation that will be very difficult, if not
>>>> impossible, to recover.  It's also much more work than a direct translation to
>>>> SPIR-V, so you will be investing extra engineering effort in order to generate
>>>> worse SPIR-V.
>>>>> So as a proposal, could I suggest the following next steps?
>>>>> 1) Add a dummy SPIR-V target machine to llvm, replete with target
>>>>> triple
>>>>> 2) Implement an experimental backend making use of globalisel to
>>>>> target SPIR-V code generation
>>>>> 3) Add tests to verify correct execution
>>>>> 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.
>>>> As I said before, I disagree with this approach.  I don't think doing a GlobalIsel
>>>> based SPIR-V backend is a good use of engineering resources nor will it
>>>> produce the best quality of code.
>>>> I think you should re-evaluate your goals and decide, which of your goals can
>>>> be met by having an in-tree solution (no matter what that solution is direct
>>>> translator, GlobalISel backend or something else), and which of your goals
>>>> are met by having a GlobalISel-based backend.  I think it's important to
>>>> separate those two ideas, because my observation is that the reason people
>>>> favor doing a GlobalISel or SelectionDAG based backend is because it is the
>>>> easiest way to get something in tree, and not because it is the best technical
>>>> solution, which is a not a good reason to make this kind of decision.
>>>> From past discussions, one of the main reasons some LLVM developers did
>>>> not want a direct LLVM IR to SPIR-V translator in tree is that it would
>>>> essentially be introducing a second legalization framework (or third now that
>>>> we have GlobalIsel), which would place an increased maintenance burden on
>>>> the community.
>>>> There wasn't a unanimous objection from the community, however, and I
>>>> think there is enough interest in this project that we could come up with
>>>> some kind of solution for an in-tree direct LLVM IR translator. However, it's
>>>> really hard to argue for a big change like this without any code or existing
>>>> user base to show the community how the benefits of this outweigh the
>>>> costs.
>>>> I think a direct LLVM IR to SPIR-V translator is the best technical solution, this
>>>> is why my recommendation is to start by taking the existing code that
>>>> implements a direct LLVM IR to SPIR-V translator and develop it as its own
>>>> out-of-tree project, and by out-of-tree I mean a complete separate project
>>>> from LLVM not just a fork of it.  Having an out-of-tree project will allow you
>>>> to improve the code and build up a community, without getting bogged
>>>> down by lengthy mailing list discussions or trying to integrate major changes
>>>> to core LLVM infrastructure in order to accommodate your translator.
>>>> Once you have a good solution with a strong userbase, I think you will be in a
>>>> much better position to work with the community to come up with a solution
>>>> to integrate your translator into the official tree.
>>>> -Tom
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev