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

[Neil Hickey via llvm-dev]

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.

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.

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
 * 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
 * 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
 * Challenges of implementing SPIR-V backend can influence LLVM backend development, to improve LLVM usability by less conventional targets
 * Benefits LLVM by improving support for GPU code generation specifically

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170620/c94a2b9b/attachment.html>