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

[Craig Topper via cfe-dev]

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> 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>
> 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.
> >
>
> _______________________________________________
> cfe-dev mailing list
> 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/55950fdf/attachment-0001.html>