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

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
>>
>>
>

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

Hi Neil
> On Jul 17, 2017, at 6:55 AM, Neil Henning via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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).
Out of curiosity, can you elaborate on this?  What is clang doing wrong, and why
does a new triple solve it?

Also, we have loads of triple's for targets not in LLVM.  You should just
add one for SPIRV if you need it.  I can't imagine that being controversial
to folks.

Cheers,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170717/7b95b7a8/attachment.html>

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

On Mon, Jul 17, 2017, at 03:55 PM, Neil Henning via llvm-dev
wrote:
> Hey all,
> 
> Code finally got through legal, but the repo is live here 
> https://github.com/google/clspv
Nice, congratulations!

Best,
Tobias
 
> 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