[llvm-dev] [SPIR-V] SPIR-V in LLVM
Neil Henning via llvm-dev
llvm-dev at lists.llvm.org
Tue Jul 18 02:30:54 PDT 2017
Hey Nicolas,
Yup - one thing to note is that for the clspv project the only target we
care about is Vulkan SPIR-V. It's quite a bit more difficult to target
Vulkan SPIR-V because there are a ton of extra restrictions on top of
what OpenCL SPIR-V has.
For us, doing a clean-room implementation on tip of tree with no patches
to Clang/LLVM was a requirement.
Cheers,
-Codeplay Neil.
On 2017-07-18 04:18, Nicholas Wilson via llvm-dev wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list