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

Fri May 15 06:31:24 PDT 2020

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