[RFC] Opt-in vector of bool type

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
Hi,

We would like to extend Clang to allow 'bool' as a valid vector element
type in C/C++ code for select targets.

This is the natural type for SIMD masks and would facilitate clean SIMD
intrinsic declarations in C/C++ code.
Vectors of i1 are supported on IR level and below down to many SIMD
ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
We understand the historical reasons for not supporting this (gcc
complicance).
However, this would be an opt-in feature and toolchains/targets that do
not want this will be unaffected by the change.

Looking forward to your feedback.

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.

I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?

-----Original Message-----
From: cfe-dev <[hidden email]> On Behalf Of Simon Moll via cfe-dev
Sent: Thursday, May 14, 2020 6:39 AM
To: [hidden email]
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: [cfe-dev] [RFC] Opt-in vector of bool type

Hi,

We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.

This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
We understand the historical reasons for not supporting this (gcc complicance).
However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.

Looking forward to your feedback.

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
On 5/14/20 3:57 PM, Keane, Erich wrote:
> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.
Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
I'd say that some targets may value strict gcc compliance higher than
supporting this type (ie if they have no use for it). Making it an
opt-in simply means less disturbance. In any case, it's again completely
in line with the wording of the gcc documentation to scalarize the type
for targets that do not support it.

> -----Original Message-----
> From: cfe-dev <[hidden email]> On Behalf Of Simon Moll via cfe-dev
> Sent: Thursday, May 14, 2020 6:39 AM
> To: [hidden email]
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>
> Hi,
>
> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>
> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
> We understand the historical reasons for not supporting this (gcc complicance).
> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>
> Looking forward to your feedback.
>
> - Simon
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:09 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 3:57 PM, Keane, Erich wrote:
> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.
Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.

> -----Original Message-----
> From: cfe-dev <[hidden email]> On Behalf Of Simon Moll
> via cfe-dev
> Sent: Thursday, May 14, 2020 6:39 AM
> To: [hidden email]
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>
> Hi,
>
> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>
> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
> We understand the historical reasons for not supporting this (gcc complicance).
> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>
> Looking forward to your feedback.
>
> - Simon
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and
it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1>
could be problematic. I wonder, shouldn't _ExtInt have the exact same
problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon Moll
>> via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
_ExtInt doesn't occur in vectors, for which we've seen the problems, only in the vector types from the frontend.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

The extended vector types also support operator[] which probably assumes the elements are individually addressable?

~Craig


On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:
Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

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

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Simon Moll via cfe-dev <[hidden email]> writes:

> We would like to extend Clang to allow 'bool' as a valid vector element
> type in C/C++ code for select targets.
>
> This is the natural type for SIMD masks and would facilitate clean SIMD
> intrinsic declarations in C/C++ code.
> Vectors of i1 are supported on IR level and below down to many SIMD
> ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
> We understand the historical reasons for not supporting this (gcc
> complicance).
> However, this would be an opt-in feature and toolchains/targets that do
> not want this will be unaffected by the change.
>
> Looking forward to your feedback.

FWIW, this would also be useful for SVE predicates when generating
fixed-length code.

It's convenient that both GCC and clang reject boolean element types
as thing stand, e.g.:

    typedef bool foo __attribute__((vector_size(32)));

I think this means that it should be possible to treat packed boolean
vectors as a pure extension to what exists today.  Compatibility with
older compilers shouldn't be a concern, it would just be a new feature.

GCC is a moving target too, and I don't know of any reason in principle
why GCC would never support this.  A lot of the necessary plumbing
already exists.

So far the principle has been that vector_size should work the same
way regardless of the current target, with the compiler deciding
how best to implement the code.  I think it would be good to follow
that for any extension too, rather than making the feature opt-in and
introducing a new target dependency.

Thanks,
Richard
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper <[hidden email]>
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich <[hidden email]>
Cc: Simon Moll <[hidden email]>; Clang Dev <[hidden email]>; MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

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


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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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



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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
On 5/14/20 6:23 PM, Richard Sandiford wrote:
> FWIW, this would also be useful for SVE predicates when generating
> fixed-length code.
Yes, i imagine that a lot of SIMD/vector targets would benefit from this.

> It's convenient that both GCC and clang reject boolean element types
> as thing stand, e.g.:
>
>     typedef bool foo __attribute__((vector_size(32)));
>
> I think this means that it should be possible to treat packed boolean
> vectors as a pure extension to what exists today.  Compatibility with
> older compilers shouldn't be a concern, it would just be a new feature.
>
> GCC is a moving target too, and I don't know of any reason in principle
> why GCC would never support this.  A lot of the necessary plumbing
> already exists.
>
> So far the principle has been that vector_size should work the same
> way regardless of the current target, with the compiler deciding
> how best to implement the code.  I think it would be good to follow
> that for any extension too, rather than making the feature opt-in and
> introducing a new target dependency.

I have to say i am pleasantly surprised by the positive feedback for
this proposal :) If there are no principal reservations against going
ahead with this, i'll submit a patch on Phabricator that enables 'bool'
in vector_size by default for all targets, so, basically a revert of:

    commit 8c9795d9fa94a7478d18e3906dff2408f379e8d9
    Author: Aaron Ballman <[hidden email]>
    Date:   Fri Sep 13 20:43:08 2013 +0000

        vector_size cannot be applied to Booleans.  Updated the semantic
checking logic, as well as the comment and added a test case.  Fixes PR12649
   
        llvm-svn: 190721

We can flesh out the details during review.

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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

 

From: Simon Moll <[hidden email]>
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>
Cc: Clang Dev <[hidden email]>; MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 


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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
On 5/15/20 3:18 PM, Keane, Erich wrote:

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.

 

From: Simon Moll [hidden email]
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich [hidden email]; Craig Topper [hidden email]
Cc: Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 



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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev

I’m not sure how open the group are to adding ANOTHER new vector type, but I’d want an RFC that properly defines the semantics of such a type. 

 

From: Simon Moll <[hidden email]>
Sent: Friday, May 15, 2020 6:31 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>
Cc: Clang Dev <[hidden email]>; MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

On 5/15/20 3:18 PM, Keane, Erich wrote:

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.


 

From: Simon Moll [hidden email]
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich [hidden email]; Craig Topper [hidden email]
Cc: Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 

 


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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev


From: cfe-dev <[hidden email]> on behalf of Simon Moll via cfe-dev <[hidden email]>
Sent: Friday, May 15, 2020 8:31 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type
 
On 5/15/20 3:18 PM, Keane, Erich wrote:

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.

Why would we not treat these like bit fields?

I think that we should support this. I've worked with several architectures that have native vector predicate registers and it seems reasonable to support these directly.

 -Hal


 

From: Simon Moll [hidden email]
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich [hidden email]; Craig Topper [hidden email]
Cc: Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 



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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev

That is an option, its just different from the rest of the vector types so it is a decision we should make intentionally.  I’d also expect said patch/RFC to define what this means in the case of all of the operations.  For example:

 

Bool1 + Bool2 (I’m told) has a different meaning in the case of vector hardware than normal bools.  I’d expect those to be clarified.

 

This isn’t as simple as reverting Aaron’s patch, there is some thought that needs to go into how that works in the case of the variety of operators.

 

From: Finkel, Hal J. <[hidden email]>
Sent: Friday, May 15, 2020 7:02 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>; Simon Moll <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

 


From: cfe-dev <[hidden email]> on behalf of Simon Moll via cfe-dev <[hidden email]>
Sent: Friday, May 15, 2020 8:31 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

On 5/15/20 3:18 PM, Keane, Erich wrote:

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.

 

Why would we not treat these like bit fields?

 

I think that we should support this. I've worked with several architectures that have native vector predicate registers and it seems reasonable to support these directly.

 

 -Hal

 

 

 

From: Simon Moll [hidden email]
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich [hidden email]; Craig Topper [hidden email]
Cc: Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 

 


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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev


From: Keane, Erich <[hidden email]>
Sent: Friday, May 15, 2020 9:06 AM
To: Finkel, Hal J. <[hidden email]>; Craig Topper <[hidden email]>; Simon Moll <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: RE: [cfe-dev] [RFC] Opt-in vector of bool type
 

That is an option, its just different from the rest of the vector types so it is a decision we should make intentionally.  I’d also expect said patch/RFC to define what this means in the case of all of the operations.  For example:

 

Bool1 + Bool2 (I’m told) has a different meaning in the case of vector hardware than normal bools.  I’d expect those to be clarified.

 

This isn’t as simple as reverting Aaron’s patch, there is some thought that needs to go into how that works in the case of the variety of operators.


I definitely agree that these should have well-defined/documented semantics.


 -Hal


 

From: Finkel, Hal J. <[hidden email]>
Sent: Friday, May 15, 2020 7:02 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>; Simon Moll <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

 


From: cfe-dev <[hidden email]> on behalf of Simon Moll via cfe-dev <[hidden email]>
Sent: Friday, May 15, 2020 8:31 AM
To: Keane, Erich <[hidden email]>; Craig Topper <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; Clang Dev <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

On 5/15/20 3:18 PM, Keane, Erich wrote:

> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

 

I don’t take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn’t individually addressable.  Unless you have a way to produce an address for each individual element (which we don’t, and is why std::vector<bool> uses a proxy return type), I don’t think this fits in the type system.

Ok, thanks for clarifying your position. If this is a concern, couldn't we just introduce a new attribute, similar to 'vector_size' or 'ext_vector_type' that simply does not allow element addressing, ie its values are more or less opaque and will only be consumed and produced as a whole (eg by intrinsics)? This would be good enough for SIMD builtins since those will only assemble and take masks apart outside of C/C++ language semantics.

 

Why would we not treat these like bit fields?

 

I think that we should support this. I've worked with several architectures that have native vector predicate registers and it seems reasonable to support these directly.

 

 -Hal

 

 

 

From: Simon Moll [hidden email]
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich [hidden email]; Craig Topper [hidden email]
Cc: Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

That's interesting, i wasn't aware of those bug reports.

The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).

We will use the bool vector feature exclusively in our intrinsic headers to declare bool vectors that cleanly map to our ISA, so in a very controlled way. Of course, once the bool vector feature for Clang is out there people will use it with a certain expectation. Then again, it is already possible to generate arbitrary <N x i1> types in LLVM today, just not using Clang.

- Simon


On 5/14/20 6:33 PM, Keane, Erich wrote:

Ah, the result of operator[] should be an LValue, so it should be addressable.  Unfortunately, I don’t think we currently implement that correctly (and consider that a bug).  See:

 

https://godbolt.org/z/Coo8Ai

 

Note we don’t allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.

 

 

From: Craig Topper [hidden email]
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich [hidden email]
Cc: Simon Moll [hidden email]; Clang Dev [hidden email]; MARUKAWA KAZUSHI [hidden email]; ISHIZAKA KAZUHISA [hidden email]; Erich Focht [hidden email]
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

 

The main issue were various issues in SelectionDAG with loads/store of vectors that aren't byte sized. For example PR42803 and PR44902.

 

The extended vector types also support operator[] which probably assumes the elements are individually addressable?


~Craig

 

 

On Thu, May 14, 2020 at 7:41 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

Craig Topper is the one who will know better, he should be along in a few hours.

-----Original Message-----
From: Simon Moll <[hidden email]>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [RFC] Opt-in vector of bool type

On 5/14/20 4:14 PM, Keane, Erich wrote:
>> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
> I'm having trouble recalling the specifics, but we tried it on SYCL (a downstream) and had a ton of problems to the point we removed it.  There isn't a good way to handle it from the ABI perspective, there is no good memory representation as a result, and many of the passes were not handling it correctly.  It makes it a huge undertaking.
That's actually a point in favor of making it opt out.
We do use <256 x i1> and <512 x i1> in our LLVM fork for SX-Aurora and it is working fine for us. I guess that there could be issues with 'i1'
being smaller than the smallest addressable unit so things like <3 x i1> could be problematic. I wonder, shouldn't _ExtInt have the exact same problem?

> -----Original Message-----
> From: Simon Moll <[hidden email]>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <[hidden email]>; Clang Dev
> <[hidden email]>
> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
> <[hidden email]>; Erich Focht <[hidden email]>
> Subject: Re: [RFC] Opt-in vector of bool type
>
> On 5/14/20 3:57 PM, Keane, Erich wrote:
>> There is a temptation when doing this to try to represent these as a vector of i1 in IR.  Don't do this, it still has to be i8s, otherwise it causes a number of problems.   
> Ok, we specifically want to lower it to <N x i1>.. what could go wrong?
>> I'll leave it to the rest of the mailing list to judge whether the GCC incompatibility is justified.  However, I'm curious as to why this would be opt-in on a target basis?  Are there some targets that wouldn't be able to legalize this?
> I'd say that some targets may value strict gcc compliance higher than supporting this type (ie if they have no use for it). Making it an opt-in simply means less disturbance. In any case, it's again completely in line with the wording of the gcc documentation to scalarize the type for targets that do not support it.
>> -----Original Message-----
>> From: cfe-dev <[hidden email]> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: [hidden email]
>> Cc: MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA
>> <[hidden email]>; Erich Focht <[hidden email]>
>> Subject: [cfe-dev] [RFC] Opt-in vector of bool type
>>
>> Hi,
>>
>> We would like to extend Clang to allow 'bool' as a valid vector element type in C/C++ code for select targets.
>>
>> This is the natural type for SIMD masks and would facilitate clean SIMD intrinsic declarations in C/C++ code.
>> Vectors of i1 are supported on IR level and below down to many SIMD ISAs, such as AVX512 or the VE target (NEC SX-Aurora TSUBASA).
>> We understand the historical reasons for not supporting this (gcc complicance).
>> However, this would be an opt-in feature and toolchains/targets that do not want this will be unaffected by the change.
>>
>> Looking forward to your feedback.
>>
>> - Simon
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

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

 

 


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

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
"Keane, Erich via cfe-dev" <[hidden email]> writes:
>> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).
>
> I don't take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn't individually addressable.  Unless you have a way to produce an address for each individual element (which we don't, and is why std::vector<bool> uses a proxy return type), I don't think this fits in the type system.

FWIW, I think taking the address of a vector_size element is already
an error in clang.  E.g.

-----------------------------------------------------------------
typedef unsigned int vec __attribute__((vector_size(16)));
vec v;
unsigned int *foo(void) { return &v[1]; }
-----------------------------------------------------------------

gives:

-----------------------------------------------------------------
foo.c:3:34: error: address of vector element requested
unsigned int *foo(void) { return &v[1]; }
                                 ^~~~~
1 error generated.
-----------------------------------------------------------------

GCC does accept this, but like others have said, I think the natural
thing would be to make it an error for bools even if it isn't for
other types.  The set of operations supported by a vector type is
inevitably going to be influenced by the element type.

Definitely agree that the semantics need to be spelled out though. :-)

Thanks,
Richard
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Opt-in vector of bool type

Fangrui Song via cfe-dev
Right, I mentioned that:
> Note we don't allow taking a non-const ref or address of a vector element, but  GCC does, though presumably that is something we should fix.



-----Original Message-----
From: Richard Sandiford <[hidden email]>
Sent: Friday, May 15, 2020 7:41 AM
To: Keane, Erich via cfe-dev <[hidden email]>
Cc: Simon Moll <[hidden email]>; Craig Topper <[hidden email]>; Keane, Erich <[hidden email]>; MARUKAWA KAZUSHI <[hidden email]>; ISHIZAKA KAZUHISA <[hidden email]>; Erich Focht <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

"Keane, Erich via cfe-dev" <[hidden email]> writes:
>> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).
>
> I don't take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn't individually addressable.  Unless you have a way to produce an address for each individual element (which we don't, and is why std::vector<bool> uses a proxy return type), I don't think this fits in the type system.

FWIW, I think taking the address of a vector_size element is already an error in clang.  E.g.

-----------------------------------------------------------------
typedef unsigned int vec __attribute__((vector_size(16))); vec v; unsigned int *foo(void) { return &v[1]; }
-----------------------------------------------------------------

gives:

-----------------------------------------------------------------
foo.c:3:34: error: address of vector element requested unsigned int *foo(void) { return &v[1]; }
                                 ^~~~~
1 error generated.
-----------------------------------------------------------------

GCC does accept this, but like others have said, I think the natural thing would be to make it an error for bools even if it isn't for other types.  The set of operations supported by a vector type is inevitably going to be influenced by the element type.

Definitely agree that the semantics need to be spelled out though. :-)

Thanks,
Richard
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
12