[cfe-dev] [RFC] Opt-in vector of bool type

Fri May 15 07:06:05 PDT 2020

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. <hfinkel at anl.gov>
Sent: Friday, May 15, 2020 7:02 AM
To: Keane, Erich <erich.keane at intel.com>; Craig Topper <craig.topper at gmail.com>; Simon Moll <Simon.Moll at EMEA.NEC.COM>
Cc: MARUKAWA KAZUSHI <marukawa at nec.com>; Clang Dev <cfe-dev at lists.llvm.org>; ISHIZAKA KAZUHISA <ishizaka at nec.com>; Erich Focht <Erich.Focht at EMEA.NEC.COM>
Subject: Re: [cfe-dev] [RFC] Opt-in vector of bool type

________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Simon Moll via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: Friday, May 15, 2020 8:31 AM
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>>
Cc: MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; Clang Dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>; ISHIZAKA KAZUHISA <ishizaka at nec.com<mailto:ishizaka at nec.com>>; Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>
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 <Simon.Moll at EMEA.NEC.COM><mailto:Simon.Moll at EMEA.NEC.COM>
Sent: Friday, May 15, 2020 6:14 AM
To: Keane, Erich <erich.keane at intel.com><mailto:erich.keane at intel.com>; Craig Topper <craig.topper at gmail.com><mailto:craig.topper at gmail.com>
Cc: Clang Dev <cfe-dev at lists.llvm.org><mailto:cfe-dev at lists.llvm.org>; MARUKAWA KAZUSHI <marukawa at nec.com><mailto:marukawa at nec.com>; ISHIZAKA KAZUHISA <ishizaka at nec.com><mailto:ishizaka at nec.com>; Erich Focht <Erich.Focht at EMEA.NEC.COM><mailto:Erich.Focht at EMEA.NEC.COM>
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 <craig.topper at gmail.com><mailto:craig.topper at gmail.com>
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich <erich.keane at intel.com><mailto:erich.keane at intel.com>
Cc: Simon Moll <Simon.Moll at emea.nec.com><mailto:Simon.Moll at emea.nec.com>; Clang Dev <cfe-dev at lists.llvm.org><mailto:cfe-dev at lists.llvm.org>; MARUKAWA KAZUSHI <marukawa at nec.com><mailto:marukawa at nec.com>; ISHIZAKA KAZUHISA <ishizaka at nec.com><mailto:ishizaka at nec.com>; Erich Focht <Erich.Focht at emea.nec.com><mailto:Erich.Focht at emea.nec.com>
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 <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

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

-----Original Message-----
From: Simon Moll <Simon.Moll at EMEA.NEC.COM<mailto:Simon.Moll at EMEA.NEC.COM>>
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Clang Dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; ISHIZAKA KAZUHISA <ishizaka at nec.com<mailto:ishizaka at nec.com>>; Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>
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 <Simon.Moll at EMEA.NEC.COM<mailto:Simon.Moll at EMEA.NEC.COM>>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Clang Dev
> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
> Cc: MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; ISHIZAKA KAZUHISA
> <ishizaka at nec.com<mailto:ishizaka at nec.com>>; Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>
> 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 <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> On Behalf Of Simon
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
>> Cc: MARUKAWA KAZUSHI <marukawa at nec.com<mailto:marukawa at nec.com>>; ISHIZAKA KAZUHISA
>> <ishizaka at nec.com<mailto:ishizaka at nec.com>>; Erich Focht <Erich.Focht at EMEA.NEC.COM<mailto:Erich.Focht at EMEA.NEC.COM>>
>> 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
>> cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200515/722f4c02/attachment-0001.html>