[LLVMdev] [RFC] Proposal for Adding SPIRV Target

[Chandler Carruth]

On Wed, Jun 17, 2015 at 5:47 AM Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote:

>  Here is the revised proposal for the LLVM/SPIR-V converter. Please
> comment. Thanks.
>
>
>
> Proposal of Adding SPIRV Target
>
>
>
> Background
>
>
>
> SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A
> typical use case of SPIR-V is as follows:
>
>
>
> 1.      An application developer uses Clang to compile an OpenCL kernel
> source code to a SPIR-V binary which is common for all OpenCL platforms.
>
> 2.      The application developer ships the application containing the
> SPIR-V binary to customers.
>
> 3.      A customer runs the application on an OpenCL platform, which
> loads the SPIR-V binary through an OpenCL API function.
>
> 4.      The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR,
> changes the target triple and data layout to suit the device which will
> execute the kernel, performs target specific optimizations, generates the
> ISA and executes the ISA on the device.
>
>
>
> For OpenCL kernels, there is implicit data layout dependence when
> compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms,
> a common data layout accepted by different OpenCL vendors is required. We
> choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V,
> since it has been successfully used for supporting consumption of SPIR
> 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under
> discussion whether to choose the same data layout as OpenCL, or a different
> data layout, or no data layout at all.
>
>
>
> Location
>
>
>
> From feedback of the previous version of the proposal, there are several
> suggestions about the location for the LLVM/SPIR-V converter:
>
>
>
> 1.      llvm/lib/SPIRV only, adding an option to Clang for outputting
> SPIR-V. The advantage is ease of use for bi-way translation. However it
> does not reflect the fact that only LLVM IR with specific target triple and
> data layout can be translated to SPIR-V.
>
> 2.      llvm/lib/SPIRV containing the main functionality of bi-way
> translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a
> thin wrapper as a target machine to allow Clang targeting SPIR-V. The
> advantage compared with 1 is that it allows a more conventional way of
> using Clang to produce SPIR-V. However it is subject to the same issue as 1
> about not reflecting the requirement on the LLVM IR which can be translated
> to SPIR-V.
>
> 3.      llvm/lib/Target/SPIRV only. The advantage is that it reflects the
> requirement on the target triple and data layout for LLVM IR which can be
> translated to SPIR-V. However putting the SPIR-V to LLVM converter in the
> same directory is unconventional. Leaving the SPIR-V to LLVM converter out
> of LLVM source tree is also not desirable since OpenCL vendors need this
> functionality.
>
>
>
> Our proposal is to take approach 3 and keep the bi-way converter in
> llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed
> through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is
> also provided to allow Clang targeting SPIR-V. The rationale is that this
> directory structure better reflects the nature of SPIR-V. SPIR-V is not an
> alternative representation for arbitrary LLVM IR. Instead, it is an
> alternative representation for LLVM IR targeting generic OpenCL or Vulkan
> platforms. It has its own specific target triple and data layout. Therefore
> it makes sense for the functionality to be put under llvm/lib/Target. Also,
> as an alternative representation of LLVM IR, it makes sense to have a
> bi-way convertor.
>
>
>
> Implementation
>
>
>
> About the implementation of the converter, although there are suggestions
> to take the SelectionDAG/MC approach, it seems not a major concern in
> general.
>
I think you failed to understand my email then.

For me, not using the common and shared legalization framework is a
complete deal breaker. As you say, this is not a stable representation for
*any* generic IR, only for the subset targeting a specific platform. But
without a legalization layer that maps from generic IR to that specific
platform's representation, we would be unable to change the canonical form
that the middle end optimizers produce from IR (including the IR generated
by an OpenCL frontend) without updating your legalization layer. If that
legalization layer in turn is a completely separate layer from the
SelectionDAG legalization layer, you've added a whole new burden on the
LLVM community that doesn't seem reasonable.


I think it is important that this effort shift to thinking of SPIR-V as a
virtual ISA (admittedly a very special purpose one) and use common
infrastructure for lowering and targeting it.

At the same time, I freely acknowledge that the current infrastructure in
LLVM may not be ideal for this purpose today. I think it is incumbent on
your group[1] to undertake the effort of making LLVM's infrastructure
better suited to your usecase rather than introducing a new set of
infrastructure that is not shared with any other targets.

-Chandler

[1]: A footnote that is really a meta point, and not specifically about
this proposal. When I say "you will have to make <whatever> significant
changes to the LLVM infrastructure that you need", I'm not saying you
should go away and start writing patches to this effect. Changing the core
code generation infrastructure of LLVM is a really huge undertaking. If you
want to do this, you'll need to first build up a reputation within the LLVM
community, trust of the various developers, etc. Don't dive into the
infrastructure first, you need to start with bugs, fixes, and small
improvements. I realize this is a huge challenge for a lot of contributors,
but changing heavily used infrastructure in really invasive ways is an
extremely high-risk endeavor and I think it is reasonable that the
community has a relatively high bar for contributors proposing to do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/6c14bbe2/attachment.html>