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
> Neil
>
>
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* 10 May 2017 15:05:22
> *To:* tstellar at redhat.com
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM
>
> 2017-05-03 21:04 GMT+02:00 Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org>:
>> So there are really two questions here:
>> 1. Should targets be required to use SelectionDAG/GlobalISEL ?
>
> In the past we also had a C and an LLVM-IR builder-backend (also known
> as Cpp backend) which did not use instruction selection. That is,
> there are other uses cases for non-SelectionDAG/GlobalISEL backends.
>
> I have no use for the Cpp backend, but a revival of the C backend
> could be interesting.
>
> Michael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev