llvm dev - Sep 2018 - [cfe-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

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

I was going to wait until Neil Trevett got back to me about becoming a SPIR-V
TSG advisor but this seems like just as good an opportunity. Please see the
previous discussion [1] if you have not already, there were many relevant points
made.

First, I’d like to note that while clang may be the primary motivator for many
of the readers here it is not the only frontend that would like to make use of
proper SPIR-V support in LLVM. In particular, the current implementation of
builtins as Itanium with extensions mangled C++ is much more difficult to use
(even if those frontends have a C++ mangler, the extensions make it unusable),
compared to intrinsics which is _the_ way backends for LLVM expose builtins.
This is an absolute requirement for me for SPIR-V support in upstream LLVM.

I’d much rather have this as a target than as an external library, but if it
means I get intrinsics faster then I’m all for it.

Could you please link the thread mentioned?

Thanks,
Nic

P.S. Feel free to use the tablegen descriptions of the SPIR-V format from [2]

[1]: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html
[2]: https://github.com/thewilsonator/llvm-target-spirv

On 10 Sep 2018, at 11:10 pm, Anastasia Stulova via llvm-dev <llvm-dev at
lists.llvm.org<mailto: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/20180911/734ed262/attachment.html>

On 11.09.2018 03:47, Nicholas Wilson via llvm-dev wrote:
> First, I’d like to note that while clang may be the primary motivator 
> for many of the readers here it is not the only frontend that would like 
> to make use of proper SPIR-V support in LLVM.
Even more than that, it's not only frontends that are interested :)

The AMDGPU backend is used to compile SPIR-V into machine code, and this 
comes with occasional pains due to subtle semantics mismatches. My hope 
would be that getting a better alignment of SPIR-V and LLVM would reduce 
those pains.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

On 9/10/2018 8:10 AM, Anastasia Stulova via cfe-dev
wrote:
> 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
Even if llvm-spirv is technically a separate binary, it's still tightly 
coupled to the clang version because the bitcode format changes over 
time; it would be a support nightmare if clang shipped by llvm.org 
passes bitcode to some binary which isn't shipped by llvm.org.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I was going to wait until Neil Trevett got back to me about becoming a
> SPIR-V TSG advisor but this seems like just as good an opportunity. Please
> see the previous discussion [1] if you have not already, there were many
> relevant points made.
>
> First, I’d like to note that while clang may be the primary motivator for
> many of the readers here it is not the only frontend that would like to
> make use of proper SPIR-V support in LLVM. In particular, the current
> implementation of builtins as Itanium with extensions mangled C++ is much
> more difficult to use (even if those frontends have a C++ mangler, the
> extensions make it unusable), compared to intrinsics which is _the_ way
> backends for LLVM expose builtins. This is an absolute requirement for me
> for SPIR-V support in upstream LLVM.
>
> I’d much rather have this as a target than as an external library, but if
> it means I get intrinsics faster then I’m all for it.
>
+1. What would be the justification for using an external binary for this
rather than treating it like any other LLVM backend?

> Could you please link the thread mentioned?
>
> Thanks,
> Nic
>
> P.S. Feel free to use the tablegen descriptions of the SPIR-V format from
> [2]
>
> [1]: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html
> [2]: https://github.com/thewilsonator/llvm-target-spirv
>
> 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
>
>
> _______________________________________________
> 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/20180911/8483d4d9/attachment.html>

On 09/11/2018 12:31 PM, Friedman, Eli via llvm-dev
wrote:
> On 9/10/2018 8:10 AM, Anastasia Stulova via cfe-dev wrote:
>> 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
> 
> Even if llvm-spirv is technically a separate binary, it's still tightly
coupled to the clang version because the bitcode format changes over time; it
would be a support nightmare if clang shipped by llvm.org passes bitcode to some
binary which isn't shipped by llvm.org.
> 
Are you concerned about the support burden for the LLVM maintainers
or the llvm-spirv maintainers?
> -Eli
>

On 10 September 2018 at 16:10, Anastasia Stulova via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> 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
>
>
Hi,

At a high level, one can view the output of backends as being "lower"
than
LLVM IR.
If we wish to output representations that are at a similar level to LLVM
IR, then it might be sensible not to use the backends method.
How about a new output method.
e.g.
Instead of:
(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
Use:
clang -cc1 -triple spirv[32|64]-unknown-unknown test.cl -emit-spirv -o
test.spv
With -emit-xxxx  being plugins that do not fit well with the existing
backend api.
This could also be used for output representations that are higher than
LLVM IR, e.g. C
We could treat them as a final LLVM IR Module pass, that results in some
file output

Kind Regards

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180916/e6fcbd79/attachment.html>

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

This would work for us!


________________________________
From: James Courtier-Dutton <james.dutton at gmail.com>
Sent: 16 September 2018 12:11
To: Anastasia Stulova
Cc: clang developer list; llvm-dev at lists.llvm.org; nd; Brian.Sumner at
amd.com
Subject: Re: [cfe-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

On 10 September 2018 at 16:10, Anastasia Stulova via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

An example of how Clang can be used to target SPIR-V:

clang -c test.cl<http://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<http://test.cl> -emit-llvm-bc -o test.bc

(2) llvm-spirv test.bc -o test.spv


Hi,

At a high level, one can view the output of backends as being "lower"
than LLVM IR.
If we wish to output representations that are at a similar level to LLVM IR,
then it might be sensible not to use the backends method.
How about a new output method.
e.g.
Instead of:
(1) clang -cc1 -triple spirv[32|64]-unknown-unknown
test.cl<http://test.cl> -emit-llvm-bc -o test.bc
(2) llvm-spirv test.bc -o test.spv
Use:
clang -cc1 -triple spirv[32|64]-unknown-unknown test.cl<http://test.cl>
-emit-spirv -o test.spv
With -emit-xxxx  being plugins that do not fit well with the existing backend
api.
This could also be used for output representations that are higher than LLVM IR,
e.g. C
We could treat them as a final LLVM IR Module pass, that results in some file
output

Kind Regards

James



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180917/dd9591e1/attachment.html>

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:

- Generation of SPIR-V binaries in LLVM.

- Importing and linking SPIR-V libraries/binaries.

- Generic target in Clang for the next OpenCL C and C++ features.

- Use of external tools.



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/20180917/e4a6a84c/attachment-0001.html>