[cfe-dev] [RFC] Opt-in vector of bool type
Keane, Erich via cfe-dev
cfe-dev at lists.llvm.org
Thu May 14 07:38:25 PDT 2020
_ExtInt doesn't occur in vectors, for which we've seen the problems, only in the vector types from the frontend.
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
>> 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
> Click https://www.mailcontrol.com/sr/oQwtyXcdX53GX2PQPOmvUg0Q1FXI7Aab-QzHJ7UWIjRMq5T1zXvuPMqYcAgplusgzyhEqfNeWhrp5oVq8TaMKA== to report this email as spam.
More information about the cfe-dev