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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
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]


On 10 Sep 2018, at 11:10 pm, Anastasia Stulova via llvm-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email]> 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]


On 10 Sep 2018, at 11:10 pm, Anastasia Stulova via llvm-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:

> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>

This has been discussed in the past, but I don't think SPIR-V
is a good fit for an LLVM backend.  It is very similar to LLVM
IR and it seems like overkill to write a whole backend just to
do a simple translation.  Not to mention the fact that I don't
see how it's possible with the current backend infrastructure
to preserve type information for complex types like structs all
the way through the codegen pipeline.

-Tom

 

>
>     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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
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
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
On 9/11/2018 7:43 PM, Tom Stellard wrote:

> 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?

When someone runs into an issue with a clang shipped by llvm.org and an
llvm-spirv shipped by someone else, I would guess they'll basically
choose randomly whether to blame clang or the llvm-spirv tool.

Thinking about it a bit more, maybe the issue isn't unsolvable... if we
make sure to specifically only invoke llvm-spirv installed beside clang
(so we aren't grabbing a random binary from the PATH), and binary
releases of llvm-spirv project ship a complete sysroot so people are
never directed to mix llvm-spirv releases and llvm.org releases, and we
print high-quality error messages if llvm-spirv is missing or
mismatches, it's probably not too confusing.

I'm still not really happy that we can't manage to integrate a SPIR-V
backend into LLVM instead, but I guess if that changes in the future it
would be mostly transparent to users.

-Eli

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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev


> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email]> wrote:
>
> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>>
>
> This has been discussed in the past, but I don't think SPIR-V
> is a good fit for an LLVM backend.  It is very similar to LLVM
> IR and it seems like overkill to write a whole backend just to
> do a simple translation.  Not to mention the fact that I don't
> see how it's possible with the current backend infrastructure
> to preserve type information for complex types like structs all
> the way through the codegen pipeline.

Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.

- Matthias

>
> -Tom
>
>
>>
>>    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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>>
>>>    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
>>>    [hidden email] <mailto:[hidden email]>
>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>    _______________________________________________
>>    LLVM Developers mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
On Tue, 11 Sep 2018 at 19:40, Tom Stellard via llvm-dev <[hidden email]> wrote:
On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>

This has been discussed in the past, but I don't think SPIR-V
is a good fit for an LLVM backend.  It is very similar to LLVM
IR and it seems like overkill to write a whole backend just to
do a simple translation.

I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.
 
Not to mention the fact that I don't
see how it's possible with the current backend infrastructure
to preserve type information for complex types like structs all
the way through the codegen pipeline.

The nice thing about code is that it's malleable. If there's a limitation that prevents SPIR-V being written as an LLVM target, we should just fix that.

-Tom


>
>     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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev


On Sep 12, 2018, at 2:54 PM, Richard Smith via llvm-dev <[hidden email]> wrote:

On Tue, 11 Sep 2018 at 19:40, Tom Stellard via llvm-dev <[hidden email]> wrote:
On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:

> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
> 

This has been discussed in the past, but I don't think SPIR-V
is a good fit for an LLVM backend.  It is very similar to LLVM
IR and it seems like overkill to write a whole backend just to
do a simple translation.

I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.
Using lib/CodeGen and going to MIR makes sense if you have to solve instruction selection, legalization, scheduling, register/resource allocation problems, manage a callstack etc. if you don't need any (or most) of that then I think it makes sense to just build a custom IR pass rather than invoking the whole codegen machinery.

 
Not to mention the fact that I don't
see how it's possible with the current backend infrastructure
to preserve type information for complex types like structs all
the way through the codegen pipeline.

The nice thing about code is that it's malleable. If there's a limitation that prevents SPIR-V being written as an LLVM target, we should just fix that.
Indeed we should still be able to implement the TargetMachine interface and get the thing into the TargetMachine registry.

- Matthias


-Tom


> 
>     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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev

On 09/12/2018 05:21 PM, Matthias Braun via llvm-dev wrote:


On Sep 12, 2018, at 2:54 PM, Richard Smith via llvm-dev <[hidden email]> wrote:

On Tue, 11 Sep 2018 at 19:40, Tom Stellard via llvm-dev <[hidden email]> wrote:
On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
> 

This has been discussed in the past, but I don't think SPIR-V
is a good fit for an LLVM backend.  It is very similar to LLVM
IR and it seems like overkill to write a whole backend just to
do a simple translation.

I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.
Using lib/CodeGen and going to MIR makes sense if you have to solve instruction selection, legalization, scheduling, register/resource allocation problems, manage a callstack etc. if you don't need any (or most) of that then I think it makes sense to just build a custom IR pass rather than invoking the whole codegen machinery.

 
Not to mention the fact that I don't
see how it's possible with the current backend infrastructure
to preserve type information for complex types like structs all
the way through the codegen pipeline.

The nice thing about code is that it's malleable. If there's a limitation that prevents SPIR-V being written as an LLVM target, we should just fix that.
Indeed we should still be able to implement the TargetMachine interface and get the thing into the TargetMachine registry.

I agree. Isn't this the way that the C backend used to work?

 -Hal


- Matthias


-Tom


> 
>     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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev


On Wed, Sep 12, 2018 at 2:55 PM Richard Smith via llvm-dev <[hidden email]> wrote:

I don't see how SPIR-V is any different from WebAssembly or PTXAS in this regard. I also don't see why a "whole backend" is a different amount of work from a separate program that implements a whole backend.
 

Our experience with WebAssembly (or really with its predecessors PNaCl and asm.js) was that it certainly is possible to do a reasonable implementation of TargetMachine and the related interfaces without using all of the common bits in lib/CodeGen that aren't suitable. However it does mean duplicating some of the functionality; for example when you skip SelectionDAG you end up having to re-implement a lot of the type legalization that happens during that stage. This was one of the top concerns we heard when we proposed upstreaming: people didn't want that duplication (and confusion about there being 2 different ways to do the same thing) even if the duplicated functionality was itself shared between projects. My observation was that one of the key things that got WebAssembly greater acceptance was our decision to use the lib/CodeGen pipeline. (I can't really say about NVPTX).

I think if you were principled about the design you could probably support a use case like SPIR-V in a reasonable way, but you'd need to convince stakeholders that things have changed (a lot changes over the period of years) and that the benefits justify the costs, etc.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
On 09/12/2018 02:32 PM, Matthias Braun wrote:

>
>
>> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email]> wrote:
>>
>> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>>>
>>
>> This has been discussed in the past, but I don't think SPIR-V
>> is a good fit for an LLVM backend.  It is very similar to LLVM
>> IR and it seems like overkill to write a whole backend just to
>> do a simple translation.  Not to mention the fact that I don't
>> see how it's possible with the current backend infrastructure
>> to preserve type information for complex types like structs all
>> the way through the codegen pipeline.
>
> Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.
>

In the past one of the arguments against doing this is that when you
have a target that doesn't use the common legalization/lowering framework
then it makes changes to the IR that much more burdensome, because
you now have one more thing to update in addition to SelectionDAG,
GlobalISel, and FastISel.  And then what happens if we end up with
multiple targets like this?

I do think having some having some kind of TargeMachine wrapper
around an IR pass(es) would be a good technical solution, though, if
we can find a way to keep the support burden minimal, especially
since the LLVM IR -> SPIR-V translation code already exists.

-Tom

> - Matthias
>
>>
>> -Tom
>>
>>
>>>
>>>    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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>>>
>>>>    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
>>>>    [hidden email] <mailto:[hidden email]>
>>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>>    [hidden email] <mailto:[hidden email]>
>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev <[hidden email]> wrote:
On 09/12/2018 02:32 PM, Matthias Braun wrote:
>
>
>> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email]> wrote:
>>
>> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>>>
>>
>> This has been discussed in the past, but I don't think SPIR-V
>> is a good fit for an LLVM backend.  It is very similar to LLVM
>> IR and it seems like overkill to write a whole backend just to
>> do a simple translation.  Not to mention the fact that I don't
>> see how it's possible with the current backend infrastructure
>> to preserve type information for complex types like structs all
>> the way through the codegen pipeline.
>
> Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.
>

In the past one of the arguments against doing this is that when you
have a target that doesn't use the common legalization/lowering framework
then it makes changes to the IR that much more burdensome, because
you now have one more thing to update in addition to SelectionDAG,
GlobalISel, and FastISel.  And then what happens if we end up with
multiple targets like this?

We have to pay that cost regardless of whether it's part of maintaining llvm-spirv or part of maintaining a SPIR-V backend, though, don't we?

I do think having some having some kind of TargeMachine wrapper
around an IR pass(es) would be a good technical solution, though, if
we can find a way to keep the support burden minimal, especially
since the LLVM IR -> SPIR-V translation code already exists.

-Tom

> - Matthias
>
>>
>> -Tom
>>
>>
>>>
>>>    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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>>>
>>>>    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
>>>>    [hidden email] <mailto:[hidden email]>
>>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>>    [hidden email] <mailto:[hidden email]>
>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev


On 09/12/2018 04:52 PM, Tom Stellard via llvm-dev wrote:

> On 09/12/2018 02:32 PM, Matthias Braun wrote:
>>
>>> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email]> wrote:
>>>
>>> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>>>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?
>>>>
>>> This has been discussed in the past, but I don't think SPIR-V
>>> is a good fit for an LLVM backend.  It is very similar to LLVM
>>> IR and it seems like overkill to write a whole backend just to
>>> do a simple translation.  Not to mention the fact that I don't
>>> see how it's possible with the current backend infrastructure
>>> to preserve type information for complex types like structs all
>>> the way through the codegen pipeline.
>> Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.
>>
> In the past one of the arguments against doing this is that when you
> have a target that doesn't use the common legalization/lowering framework
> then it makes changes to the IR that much more burdensome, because
> you now have one more thing to update in addition to SelectionDAG,
> GlobalISel, and FastISel.  And then what happens if we end up with
> multiple targets like this?
Possibly silly question, but could we reuse any of the GlobalIsel
infrastructure for this problem?  My (uniformed) perspective was that
GlobalIsel factored out the various stages much more cleanly. Could we
leverage the legalization aspects of GlobalIsel and then convert from a
legalized G_MI to SPIR IR?

>
> I do think having some having some kind of TargeMachine wrapper
> around an IR pass(es) would be a good technical solution, though, if
> we can find a way to keep the support burden minimal, especially
> since the LLVM IR -> SPIR-V translation code already exists.
>
> -Tom
>
>> - Matthias
>>
>>> -Tom
>>>
>>>
>>>>     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 <[hidden email] <mailto:[hidden email]>> 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 <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
>>>>>
>>>>>     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
>>>>>     [hidden email] <mailto:[hidden email]>
>>>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>     _______________________________________________
>>>>     LLVM Developers mailing list
>>>>     [hidden email] <mailto:[hidden email]>
>>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
On 09/12/2018 05:04 PM, Richard Smith wrote:

> On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 09/12/2018 02:32 PM, Matthias Braun wrote:
>     >
>     >
>     >> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>     >>
>     >> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>     >>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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?
>     >>>
>     >>
>     >> This has been discussed in the past, but I don't think SPIR-V
>     >> is a good fit for an LLVM backend.  It is very similar to LLVM
>     >> IR and it seems like overkill to write a whole backend just to
>     >> do a simple translation.  Not to mention the fact that I don't
>     >> see how it's possible with the current backend infrastructure
>     >> to preserve type information for complex types like structs all
>     >> the way through the codegen pipeline.
>     >
>     > Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.
>     >
>
>     In the past one of the arguments against doing this is that when you
>     have a target that doesn't use the common legalization/lowering framework
>     then it makes changes to the IR that much more burdensome, because
>     you now have one more thing to update in addition to SelectionDAG,
>     GlobalISel, and FastISel.  And then what happens if we end up with
>     multiple targets like this?
>
>
> We have to pay that cost regardless of whether it's part of maintaining llvm-spirv or part of maintaining a SPIR-V backend, though, don't we?
>

This all depends on if llvm-spirv becomes an official sub-project or not, which
is a whole other discussion, but if it does then yes the cost would be the same.

-Tom

>     I do think having some having some kind of TargeMachine wrapper
>     around an IR pass(es) would be a good technical solution, though, if
>     we can find a way to keep the support burden minimal, especially
>     since the LLVM IR -> SPIR-V translation code already exists.
>
>     -Tom
>
>     > - Matthias
>     >
>     >>
>     >> -Tom
>     >>
>     >>
>     >>>
>     >>>    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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 <http://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> <http://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
>     >>>>    [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>>    _______________________________________________
>     >>>    LLVM Developers mailing list
>     >>>    [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> LLVM Developers mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>
>     >> _______________________________________________
>     >> LLVM Developers mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
On Wed, 12 Sep 2018 at 17:15, Tom Stellard via cfe-dev <[hidden email]> wrote:
On 09/12/2018 05:04 PM, Richard Smith wrote:
> On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 09/12/2018 02:32 PM, Matthias Braun wrote:
>     >
>     >
>     >> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>     >>
>     >> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote:
>     >>> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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?
>     >>>
>     >>
>     >> This has been discussed in the past, but I don't think SPIR-V
>     >> is a good fit for an LLVM backend.  It is very similar to LLVM
>     >> IR and it seems like overkill to write a whole backend just to
>     >> do a simple translation.  Not to mention the fact that I don't
>     >> see how it's possible with the current backend infrastructure
>     >> to preserve type information for complex types like structs all
>     >> the way through the codegen pipeline.
>     >
>     > Note that even when not using lib/CodeGen (which is indeed a bad fit here), you should still be able to implement the TargetMachine interface (and return nullptr for most of the methods in there) so it  behaves like the other LLVM backend on the outside API.
>     >
>
>     In the past one of the arguments against doing this is that when you
>     have a target that doesn't use the common legalization/lowering framework
>     then it makes changes to the IR that much more burdensome, because
>     you now have one more thing to update in addition to SelectionDAG,
>     GlobalISel, and FastISel.  And then what happens if we end up with
>     multiple targets like this?
>
>
> We have to pay that cost regardless of whether it's part of maintaining llvm-spirv or part of maintaining a SPIR-V backend, though, don't we?
>

This all depends on if llvm-spirv becomes an official sub-project or not, which
is a whole other discussion, but if it does then yes the cost would be the same.

If compiling to SPIR-V is not officially something that LLVM can do, then supporting that target in Clang *at all* is whole other discussion we need to have.
 
-Tom

>     I do think having some having some kind of TargeMachine wrapper
>     around an IR pass(es) would be a good technical solution, though, if
>     we can find a way to keep the support burden minimal, especially
>     since the LLVM IR -> SPIR-V translation code already exists.
>
>     -Tom
>
>     > - Matthias
>     >
>     >>
>     >> -Tom
>     >>
>     >>
>     >>>
>     >>>    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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 <http://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> <http://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
>     >>>>    [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>>    _______________________________________________
>     >>>    LLVM Developers mailing list
>     >>>    [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> LLVM Developers mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>
>     >> _______________________________________________
>     >> LLVM Developers mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
On 10 September 2018 at 16:10, Anastasia Stulova via cfe-dev <[hidden email]> 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




_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang

Peter Smith via llvm-dev
In reply to this post by Peter Smith via llvm-dev
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 <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
12