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

[Keane, Erich 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 <craig.topper at gmail.com>
Sent: Thursday, May 14, 2020 9:17 AM
To: Keane, Erich <erich.keane at intel.com>
Cc: Simon Moll <Simon.Moll at emea.nec.com>; Clang Dev <cfe-dev at lists.llvm.org>; MARUKAWA KAZUSHI <marukawa at nec.com>; 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

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
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>

_______________________________________________
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/20200514/ebc84ee7/attachment-0001.html>