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

[Keane, Erich 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 <Simon.Moll at EMEA.NEC.COM> 
Sent: Thursday, May 14, 2020 7:36 AM
To: Keane, Erich <erich.keane at intel.com>; Clang Dev <cfe-dev at lists.llvm.org>
Cc: MARUKAWA KAZUSHI <marukawa at nec.com>; ISHIZAKA KAZUHISA <ishizaka at nec.com>; Erich Focht <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>
> Sent: Thursday, May 14, 2020 7:09 AM
> To: Keane, Erich <erich.keane at intel.com>; Clang Dev 
> <cfe-dev at lists.llvm.org>
> Cc: MARUKAWA KAZUSHI <marukawa at nec.com>; ISHIZAKA KAZUHISA 
> <ishizaka at nec.com>; Erich Focht <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> On Behalf Of Simon 
>> Moll via cfe-dev
>> Sent: Thursday, May 14, 2020 6:39 AM
>> To: cfe-dev at lists.llvm.org
>> Cc: MARUKAWA KAZUSHI <marukawa at nec.com>; ISHIZAKA KAZUHISA 
>> <ishizaka at nec.com>; Erich Focht <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
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>  Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA==  to report this email as spam.
>