[llvm-dev] [cfe-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang (original) (raw)

Anastasia Stulova via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 30 05:01:09 PDT 2018

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org> Sent: 29 October 2018 16:54 To: clang developer list Cc: Nicholas Wilson; nd; Brian.Sumner at amd.com Subject: Re: [cfe-dev] [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Thanks to everyone who participated in the Round Table discussion during the LLVM Dev Meeting. Below is a brief summary.

First of all, a number of concerns were raised again regarding the backend implementation. The implementation effort of developing the backend is significant and it's not clear to the SPIR-V developers if it results in the comparable or better quality generated binaries compared to the current solution using the IR translation [1]. This has been discussed earlier on llvm-dev as well [2], [3]. Another big concern was about the code duplication between the translation from/to SPIR-V that would have to be separated out into different flows.

The opinion of the developers attending the meeting was that we would prefer to continue using the translation tool [1]; but we would still like to improve the integration with LLVM as much as possible. There are a number of options that we have discussed briefly: external translator tool invocation via fork of Clang, adding SPIR-V triple w/o any external tool, adding translator as an official tool to the LLVM project (suggested earlier [4]).

To address concerns and suggestions from the LLVM community on this thread I am planning to look at the following topics with some help from Neil Hickey (in CC), before getting back with an updated proposal:

A. We will prototype a SPIR-V backend using the Global ISel in order to understand further the development effort and the quality of the code produced by the backend (+ potentially compilation time) compared to the simple IR translation.

B. I will look at how external tools are currently used with LLVM and try to suggest reasonable flow/process for the translator tool [1] that we would like to integrate at least for the purpose of importing SPIR-V modules to LLVM [5].

Please, let me know if you would like to be involved with any of the investigation activities I am planning or if you have any additional information that should be considered.

Cheers, Anastasia

[1] https://github.com/KhronosGroup/SPIRV-LLVM-Translator [2] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112651.html [3] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112550.html

[4] https://lists.llvm.org/pipermail/llvm-dev/2018-February/121317.html

<https://github.com/KhronosGroup/SPIRV-LLVM-Translator>[5] <https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang> http://lists.llvm.org/pipermail/cfe-dev/2018-September/059368.html

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Anastasia Stulova via llvm-dev <llvm-dev at lists.llvm.org> Sent: 17 September 2018 10:00 To: Nicholas Wilson Cc: llvm-dev at lists.llvm.org; nd; clang developer list; Brian.Sumner at amd.com Subject: Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Hi Nicholas,

A number of developers that are interested in the SPIR-V support will be attending the conference. Sounds good to have a round table. It is important to involve relevant developers outside of Khronos that are affected too!

So far there are the following topics to address:

My only concern now is about the OpenCL C++ implementation that might be stalled while we are waiting for the decisions. But it's probably important to make sure we are going the right route to fit all requirements.

Anastasia

From: Nicholas Wilson <iamthewilsonator at hotmail.com> Sent: 17 September 2018 04:42:32 To: Anastasia Stulova Cc: clang developer list; llvm-dev at lists.llvm.org; nd; Brian.Sumner at amd.com Subject: Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Given the amount of discussion that has gone on (and in past threads) and the size of the proposal, should we do a roundtable at the dev meeting in October to make sure everyone is on the same page going forward? I would come along for that if there is sufficient participation from Khronos to make good progress.

Nic

On 10 Sep 2018, at 11:10 pm, Anastasia Stulova via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Hello, Since 2015 Khronos has switched to the new portable intermediate format SPIR-V, which has replaced the original SPIR. The advantage is that it offers higher portability across different toolchains. There was a talk about it at a Dev Meeting: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#17 LLVM currently only supports SPIR format for OpenCL in Clang. Several Khronos vendors (ARM, AMD, Intel, Xilinx, Codeplay and others) are interested in adding support for SPIR-V, which should gradually replace the old SPIR once products are no longer shipped with the old format. Here is the detailed description: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang To summarize, the idea is to add a SPIR-V target triple to Clang that can be used to generate a SPIR-V binary for OpenCL code. There was a separate thread regarding generation of SPIR-V binary and the community suggested that a translator from LLVM IR to SPIR-V can be used as an external tool, called llvm-spirv. This can be invoked similar to such tools as ptxas and fatbinary for the CUDA toolchain: http://lists.llvm.org/pipermail/llvm-dev/2018-February/121440.html An example of how Clang can be used to target SPIR-V: clang -c test.cl -target spirv[32|64]-unknown-unknown -o test.spv This will result in the following Clang actions: (1) clang -cc1 -triple spirv[32|64]-unknown-unknown test.cl -emit-llvm-bc -o test.bc (2) llvm-spirv test.bc -o test.spv SPIR-V generation is essential for completion of OpenCL C++ support in Clang, as newer OpenCL standards require frontend invocation to be performed offline, producing the SPIR-V binary that can be then loaded at application execution time. Besides that, it will also allow Clang to be used as a complete standalone tool to generate portable binaries that can then be consumed by different proprietary toolchains. In addition, this will open a path to the LLVM backends for various languages and frontends that already generate SPIR-V. A more detailed explanation of the complete design proposal is given in this Wiki page: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/wiki/SPIRV-Toolchain-for-Clang Looking forward to any feedback about the proposal or possible collaborations, Thanks! Anastasia

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/20181030/0b6b1ea2/attachment.html>

More information about the llvm-dev mailing list