Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Wednesday, 26 July 2023 06:33:41 MDT Richard Biener wrote: > Btw, how the experimental SIMD C++ standard library handles > these issue might be also interesting to research (author CCed) I only skimmed over this thread now. FWIW, I would really like better support for AVX-512 bitmasks for the std::experimental::simd implementation (std::simd for C++26). I probably want better support for all the other targets that use bitmasks - but so far I only have experience with AVX512. To make the AVX512 implementation of std::experimental::simd efficient I have to call intrinsics/builtins instead of directly expressing what I want to do using the [[gnu::vector_size]] types. There are some instances where I have to convert between bitmask and element-sized mask vectors - and to make that efficient I call all kinds of intrinsics/builtins. And from what I've seen, a bitmask -> mask vector -> bitmask conversion won't be recognized as a no-op (the other way around, as well). At this point I have no technical input to this thread. But if there's anything you want me to test - whether it helps in the simd implementation - let me know. -Matthias -- ── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Center for Heavy Ion Research https://gsi.de std::simd ──
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Wed, Jul 26, 2023 at 2:26 PM Richard Biener wrote: > > On Wed, Jul 26, 2023 at 9:21 AM Tejas Belagod wrote: > > > > On 7/17/23 5:46 PM, Richard Biener wrote: > > > On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod > > > wrote: > > >> > > >> On 7/13/23 4:05 PM, Richard Biener wrote: > > >>> On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod > > >>> wrote: > > >>>> > > >>>> On 7/3/23 1:31 PM, Richard Biener wrote: > > >>>>> On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod > > >>>>> wrote: > > >>>>>> > > >>>>>> On 6/29/23 6:55 PM, Richard Biener wrote: > > >>>>>>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> From: Richard Biener > > >>>>>>>> Date: Tuesday, June 27, 2023 at 12:58 PM > > >>>>>>>> To: Tejas Belagod > > >>>>>>>> Cc: gcc-patches@gcc.gnu.org > > >>>>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > >>>>>>>> > > >>>>>>>> On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> From: Richard Biener > > >>>>>>>>> Date: Monday, June 26, 2023 at 2:23 PM > > >>>>>>>>> To: Tejas Belagod > > >>>>>>>>> Cc: gcc-patches@gcc.gnu.org > > >>>>>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > >>>>>>>>> > > >>>>>>>>> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > > >>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> Packed Boolean Vectors > > >>>>>>>>>> -- > > >>>>>>>>>> > > >>>>>>>>>> I'd like to propose a feature addition to GNU Vector extensions > > >>>>>>>>>> to add packed > > >>>>>>>>>> boolean vectors (PBV). This has been discussed in the past > > >>>>>>>>>> here[1] and a variant has > > >>>>>>>>>> been implemented in Clang recently[2]. > > >>>>>>>>>> > > >>>>>>>>>> With predication features being added to vector architectures > > >>>>>>>>>> (SVE, MVE, AVX), > > >>>>>>>>>> it is a useful feature to have to model predication on targets. > > >>>>>>>>>> This could > > >>>>>>>>>> find its use in intrinsics or just used as is as a GNU vector > > >>>>>>>>>> extension being > > >>>>>>>>>> mapped to underlying target features. For example, the packed > > >>>>>>>>>> boolean vector > > >>>>>>>>>> could directly map to a predicate register on SVE. > > >>>>>>>>>> > > >>>>>>>>>> Also, this new packed boolean type GNU extension can be used > > >>>>>>>>>> with SVE ACLE > > >>>>>>>>>> intrinsics to replace a fixed-length svbool_t. > > >>>>>>>>>> > > >>>>>>>>>> Here are a few options to represent the packed boolean vector > > >>>>>>>>>> type. > > >>>>>>>>> > > >>>>>>>>> The GIMPLE frontend uses a new 'vector_mask' attribute: > > >>>>>>>>
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Wed, Jul 26, 2023 at 9:21 AM Tejas Belagod wrote: > > On 7/17/23 5:46 PM, Richard Biener wrote: > > On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod > > wrote: > >> > >> On 7/13/23 4:05 PM, Richard Biener wrote: > >>> On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod > >>> wrote: > >>>> > >>>> On 7/3/23 1:31 PM, Richard Biener wrote: > >>>>> On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod > >>>>> wrote: > >>>>>> > >>>>>> On 6/29/23 6:55 PM, Richard Biener wrote: > >>>>>>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> From: Richard Biener > >>>>>>>> Date: Tuesday, June 27, 2023 at 12:58 PM > >>>>>>>> To: Tejas Belagod > >>>>>>>> Cc: gcc-patches@gcc.gnu.org > >>>>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>>>>>> > >>>>>>>> On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: Richard Biener > >>>>>>>>> Date: Monday, June 26, 2023 at 2:23 PM > >>>>>>>>> To: Tejas Belagod > >>>>>>>>> Cc: gcc-patches@gcc.gnu.org > >>>>>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>>>>>>> > >>>>>>>>> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> Packed Boolean Vectors > >>>>>>>>>> -- > >>>>>>>>>> > >>>>>>>>>> I'd like to propose a feature addition to GNU Vector extensions to > >>>>>>>>>> add packed > >>>>>>>>>> boolean vectors (PBV). This has been discussed in the past > >>>>>>>>>> here[1] and a variant has > >>>>>>>>>> been implemented in Clang recently[2]. > >>>>>>>>>> > >>>>>>>>>> With predication features being added to vector architectures > >>>>>>>>>> (SVE, MVE, AVX), > >>>>>>>>>> it is a useful feature to have to model predication on targets. > >>>>>>>>>> This could > >>>>>>>>>> find its use in intrinsics or just used as is as a GNU vector > >>>>>>>>>> extension being > >>>>>>>>>> mapped to underlying target features. For example, the packed > >>>>>>>>>> boolean vector > >>>>>>>>>> could directly map to a predicate register on SVE. > >>>>>>>>>> > >>>>>>>>>> Also, this new packed boolean type GNU extension can be used with > >>>>>>>>>> SVE ACLE > >>>>>>>>>> intrinsics to replace a fixed-length svbool_t. > >>>>>>>>>> > >>>>>>>>>> Here are a few options to represent the packed boolean vector type. > >>>>>>>>> > >>>>>>>>> The GIMPLE frontend uses a new 'vector_mask' attribute: > >>>>>>>>> > >>>>>>>>> typedef int v8si __attribute__((vector_size(8*sizeof(int; > >>>>>>>>> typedef v8si v8sib __attribute__((vector_mask)); > >>>>>>>>> > >>>>>>>>> it get's you a vector type that's the appropriate (dependent on the > >>>>>>>>> target) vector > >>>>>>>>> mask type for the vector data type (
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On 7/17/23 5:46 PM, Richard Biener wrote: On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod wrote: On 7/13/23 4:05 PM, Richard Biener wrote: On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote: On 7/3/23 1:31 PM, Richard Biener wrote: On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote: On 6/29/23 6:55 PM, Richard Biener wrote: On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: From: Richard Biener Date: Tuesday, June 27, 2023 at 12:58 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote: From: Richard Biener Date: Monday, June 26, 2023 at 2:23 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches wrote: Hi, Packed Boolean Vectors -- I'd like to propose a feature addition to GNU Vector extensions to add packed boolean vectors (PBV). This has been discussed in the past here[1] and a variant has been implemented in Clang recently[2]. With predication features being added to vector architectures (SVE, MVE, AVX), it is a useful feature to have to model predication on targets. This could find its use in intrinsics or just used as is as a GNU vector extension being mapped to underlying target features. For example, the packed boolean vector could directly map to a predicate register on SVE. Also, this new packed boolean type GNU extension can be used with SVE ACLE intrinsics to replace a fixed-length svbool_t. Here are a few options to represent the packed boolean vector type. The GIMPLE frontend uses a new 'vector_mask' attribute: typedef int v8si __attribute__((vector_size(8*sizeof(int; typedef v8si v8sib __attribute__((vector_mask)); it get's you a vector type that's the appropriate (dependent on the target) vector mask type for the vector data type (v8si in this case). Thanks Richard. Having had a quick look at the implementation, it does seem to tick the boxes. I must admit I haven't dug deep, but if the target hook allows the mask to be defined in way that is target-friendly (and I don't know how much effort it will be to migrate the attribute to more front-ends), it should do the job nicely. Let me go back and dig a bit deeper and get back with questions if any. Let me add that the advantage of this is the compiler doesn't need to support weird explicitely laid out packed boolean vectors that do not match what the target supports and the user doesn't need to know what the target supports (and thus have an #ifdef maze around explicitely specified layouts). Sorry for the delayed response – I spent a day experimenting with vector_mask. Yeah, this is what option 4 in the RFC is trying to achieve – be portable enough to avoid having to sprinkle the code with ifdefs. It does remove some flexibility though, for example with -mavx512f -mavx512vl you'll get AVX512 style masks for V4SImode data vectors but of course the target sill supports SSE2/AVX2 style masks as well, but those would not be available as "packed boolean vectors", though they are of course in fact equal to V4SImode data vectors with -1 or 0 values, so in this particular case it might not matter. That said, the vector_mask attribute will get you V4SImode vectors with signed boolean elements of 32 bits for V4SImode data vectors with SSE2/AVX2. This sounds very much like what the scenario would be with NEON vs SVE. Coming to think of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the ‘base’ vector type and a ‘w’ specified for the type. Given its current implementation, if vector_mask is exposed to the CFE, would there be any major challenges wrt implementation or defining behaviour semantics? I played around with a few examples from the testsuite and wrote some new ones. I mostly tried operations that the new type would have to support (unary, binary bitwise, initializations etc) – with a couple of exceptions most of the ops seem to be supported. I also triggered a couple of ICEs in some tests involving implicit conversions to wider/narrower vector_mask types (will raise reports for these). Correct me if I’m wrong here, but we’d probably have to support a couple of new ops if vector_mask is exposed to the CFE – initialization and subscript operations? Yes, either that or restrict how the mask vectors can be used, thus properly diagnose improper uses. Indeed. A question would be for example how to write common mask test operations like if (any (mask)) or if (all (mask)). I see 2 options here. New builtins could support new types - they'd provide a target independent way to test any and all conditions. Another would be to let the target use its intrinsics to do them in the most efficient way possible (which the builtins would get lowered down
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod wrote: > > On 7/13/23 4:05 PM, Richard Biener wrote: > > On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod > > wrote: > >> > >> On 7/3/23 1:31 PM, Richard Biener wrote: > >>> On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod > >>> wrote: > >>>> > >>>> On 6/29/23 6:55 PM, Richard Biener wrote: > >>>>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: Richard Biener > >>>>>> Date: Tuesday, June 27, 2023 at 12:58 PM > >>>>>> To: Tejas Belagod > >>>>>> Cc: gcc-patches@gcc.gnu.org > >>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>>>> > >>>>>> On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: Richard Biener > >>>>>>> Date: Monday, June 26, 2023 at 2:23 PM > >>>>>>> To: Tejas Belagod > >>>>>>> Cc: gcc-patches@gcc.gnu.org > >>>>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>>>>> > >>>>>>> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Packed Boolean Vectors > >>>>>>>> -- > >>>>>>>> > >>>>>>>> I'd like to propose a feature addition to GNU Vector extensions to > >>>>>>>> add packed > >>>>>>>> boolean vectors (PBV). This has been discussed in the past here[1] > >>>>>>>> and a variant has > >>>>>>>> been implemented in Clang recently[2]. > >>>>>>>> > >>>>>>>> With predication features being added to vector architectures (SVE, > >>>>>>>> MVE, AVX), > >>>>>>>> it is a useful feature to have to model predication on targets. > >>>>>>>> This could > >>>>>>>> find its use in intrinsics or just used as is as a GNU vector > >>>>>>>> extension being > >>>>>>>> mapped to underlying target features. For example, the packed > >>>>>>>> boolean vector > >>>>>>>> could directly map to a predicate register on SVE. > >>>>>>>> > >>>>>>>> Also, this new packed boolean type GNU extension can be used with > >>>>>>>> SVE ACLE > >>>>>>>> intrinsics to replace a fixed-length svbool_t. > >>>>>>>> > >>>>>>>> Here are a few options to represent the packed boolean vector type. > >>>>>>> > >>>>>>> The GIMPLE frontend uses a new 'vector_mask' attribute: > >>>>>>> > >>>>>>> typedef int v8si __attribute__((vector_size(8*sizeof(int; > >>>>>>> typedef v8si v8sib __attribute__((vector_mask)); > >>>>>>> > >>>>>>> it get's you a vector type that's the appropriate (dependent on the > >>>>>>> target) vector > >>>>>>> mask type for the vector data type (v8si in this case). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks Richard. > >>>>>>> > >>>>>>> Having had a quick look at the implementation, it does seem to tick > >>>>>>> the boxes. > >>>>>>> > >>>>>>> I must admit I haven't dug deep, but if the target hook allows the > >>>>>>> mask to be > >>>>>>> > >>>>>>> defined in way that is target-friendly (and I don't know how much > >>>>>>> effort it will >
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On 7/13/23 4:05 PM, Richard Biener wrote: On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote: On 7/3/23 1:31 PM, Richard Biener wrote: On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote: On 6/29/23 6:55 PM, Richard Biener wrote: On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: From: Richard Biener Date: Tuesday, June 27, 2023 at 12:58 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote: From: Richard Biener Date: Monday, June 26, 2023 at 2:23 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches wrote: Hi, Packed Boolean Vectors -- I'd like to propose a feature addition to GNU Vector extensions to add packed boolean vectors (PBV). This has been discussed in the past here[1] and a variant has been implemented in Clang recently[2]. With predication features being added to vector architectures (SVE, MVE, AVX), it is a useful feature to have to model predication on targets. This could find its use in intrinsics or just used as is as a GNU vector extension being mapped to underlying target features. For example, the packed boolean vector could directly map to a predicate register on SVE. Also, this new packed boolean type GNU extension can be used with SVE ACLE intrinsics to replace a fixed-length svbool_t. Here are a few options to represent the packed boolean vector type. The GIMPLE frontend uses a new 'vector_mask' attribute: typedef int v8si __attribute__((vector_size(8*sizeof(int; typedef v8si v8sib __attribute__((vector_mask)); it get's you a vector type that's the appropriate (dependent on the target) vector mask type for the vector data type (v8si in this case). Thanks Richard. Having had a quick look at the implementation, it does seem to tick the boxes. I must admit I haven't dug deep, but if the target hook allows the mask to be defined in way that is target-friendly (and I don't know how much effort it will be to migrate the attribute to more front-ends), it should do the job nicely. Let me go back and dig a bit deeper and get back with questions if any. Let me add that the advantage of this is the compiler doesn't need to support weird explicitely laid out packed boolean vectors that do not match what the target supports and the user doesn't need to know what the target supports (and thus have an #ifdef maze around explicitely specified layouts). Sorry for the delayed response – I spent a day experimenting with vector_mask. Yeah, this is what option 4 in the RFC is trying to achieve – be portable enough to avoid having to sprinkle the code with ifdefs. It does remove some flexibility though, for example with -mavx512f -mavx512vl you'll get AVX512 style masks for V4SImode data vectors but of course the target sill supports SSE2/AVX2 style masks as well, but those would not be available as "packed boolean vectors", though they are of course in fact equal to V4SImode data vectors with -1 or 0 values, so in this particular case it might not matter. That said, the vector_mask attribute will get you V4SImode vectors with signed boolean elements of 32 bits for V4SImode data vectors with SSE2/AVX2. This sounds very much like what the scenario would be with NEON vs SVE. Coming to think of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the ‘base’ vector type and a ‘w’ specified for the type. Given its current implementation, if vector_mask is exposed to the CFE, would there be any major challenges wrt implementation or defining behaviour semantics? I played around with a few examples from the testsuite and wrote some new ones. I mostly tried operations that the new type would have to support (unary, binary bitwise, initializations etc) – with a couple of exceptions most of the ops seem to be supported. I also triggered a couple of ICEs in some tests involving implicit conversions to wider/narrower vector_mask types (will raise reports for these). Correct me if I’m wrong here, but we’d probably have to support a couple of new ops if vector_mask is exposed to the CFE – initialization and subscript operations? Yes, either that or restrict how the mask vectors can be used, thus properly diagnose improper uses. Indeed. A question would be for example how to write common mask test operations like if (any (mask)) or if (all (mask)). I see 2 options here. New builtins could support new types - they'd provide a target independent way to test any and all conditions. Another would be to let the target use its intrinsics to do them in the most efficient way possible (which the builtins would get lowered down to anyway). Likewise writing merge operations - do those as a = a | (mask ? b : 0); thus u
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote: > > On 7/3/23 1:31 PM, Richard Biener wrote: > > On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote: > >> > >> On 6/29/23 6:55 PM, Richard Biener wrote: > >>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod > >>> wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Richard Biener > >>>> Date: Tuesday, June 27, 2023 at 12:58 PM > >>>> To: Tejas Belagod > >>>> Cc: gcc-patches@gcc.gnu.org > >>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>> > >>>> On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> From: Richard Biener > >>>>> Date: Monday, June 26, 2023 at 2:23 PM > >>>>> To: Tejas Belagod > >>>>> Cc: gcc-patches@gcc.gnu.org > >>>>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>>>> > >>>>> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > >>>>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Packed Boolean Vectors > >>>>>> -- > >>>>>> > >>>>>> I'd like to propose a feature addition to GNU Vector extensions to add > >>>>>> packed > >>>>>> boolean vectors (PBV). This has been discussed in the past here[1] > >>>>>> and a variant has > >>>>>> been implemented in Clang recently[2]. > >>>>>> > >>>>>> With predication features being added to vector architectures (SVE, > >>>>>> MVE, AVX), > >>>>>> it is a useful feature to have to model predication on targets. This > >>>>>> could > >>>>>> find its use in intrinsics or just used as is as a GNU vector > >>>>>> extension being > >>>>>> mapped to underlying target features. For example, the packed boolean > >>>>>> vector > >>>>>> could directly map to a predicate register on SVE. > >>>>>> > >>>>>> Also, this new packed boolean type GNU extension can be used with SVE > >>>>>> ACLE > >>>>>> intrinsics to replace a fixed-length svbool_t. > >>>>>> > >>>>>> Here are a few options to represent the packed boolean vector type. > >>>>> > >>>>> The GIMPLE frontend uses a new 'vector_mask' attribute: > >>>>> > >>>>> typedef int v8si __attribute__((vector_size(8*sizeof(int; > >>>>> typedef v8si v8sib __attribute__((vector_mask)); > >>>>> > >>>>> it get's you a vector type that's the appropriate (dependent on the > >>>>> target) vector > >>>>> mask type for the vector data type (v8si in this case). > >>>>> > >>>>> > >>>>> > >>>>> Thanks Richard. > >>>>> > >>>>> Having had a quick look at the implementation, it does seem to tick the > >>>>> boxes. > >>>>> > >>>>> I must admit I haven't dug deep, but if the target hook allows the mask > >>>>> to be > >>>>> > >>>>> defined in way that is target-friendly (and I don't know how much > >>>>> effort it will > >>>>> > >>>>> be to migrate the attribute to more front-ends), it should do the job > >>>>> nicely. > >>>>> > >>>>> Let me go back and dig a bit deeper and get back with questions if any. > >>>> > >>>> > >>>> Let me add that the advantage of this is the compiler doesn't need > >>>> to support weird explicitely laid out packed boolean vectors that do > >>>> not match what the target supports and the user doesn't need to know > >>>> what the target supports (and thus have an #ifdef maze around explicitely > >>>> specified layouts). > >>>> > >>>> Sorry for the delay
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On 7/3/23 1:31 PM, Richard Biener wrote:
On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
On 6/29/23 6:55 PM, Richard Biener wrote:
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
From: Richard Biener
Date: Tuesday, June 27, 2023 at 12:58 PM
To: Tejas Belagod
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote:
From: Richard Biener
Date: Monday, June 26, 2023 at 2:23 PM
To: Tejas Belagod
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches
wrote:
Hi,
Packed Boolean Vectors
--
I'd like to propose a feature addition to GNU Vector extensions to add packed
boolean vectors (PBV). This has been discussed in the past here[1] and a
variant has
been implemented in Clang recently[2].
With predication features being added to vector architectures (SVE, MVE, AVX),
it is a useful feature to have to model predication on targets. This could
find its use in intrinsics or just used as is as a GNU vector extension being
mapped to underlying target features. For example, the packed boolean vector
could directly map to a predicate register on SVE.
Also, this new packed boolean type GNU extension can be used with SVE ACLE
intrinsics to replace a fixed-length svbool_t.
Here are a few options to represent the packed boolean vector type.
The GIMPLE frontend uses a new 'vector_mask' attribute:
typedef int v8si __attribute__((vector_size(8*sizeof(int;
typedef v8si v8sib __attribute__((vector_mask));
it get's you a vector type that's the appropriate (dependent on the
target) vector
mask type for the vector data type (v8si in this case).
Thanks Richard.
Having had a quick look at the implementation, it does seem to tick the boxes.
I must admit I haven't dug deep, but if the target hook allows the mask to be
defined in way that is target-friendly (and I don't know how much effort it will
be to migrate the attribute to more front-ends), it should do the job nicely.
Let me go back and dig a bit deeper and get back with questions if any.
Let me add that the advantage of this is the compiler doesn't need
to support weird explicitely laid out packed boolean vectors that do
not match what the target supports and the user doesn't need to know
what the target supports (and thus have an #ifdef maze around explicitely
specified layouts).
Sorry for the delayed response – I spent a day experimenting with vector_mask.
Yeah, this is what option 4 in the RFC is trying to achieve – be portable enough
to avoid having to sprinkle the code with ifdefs.
It does remove some flexibility though, for example with -mavx512f -mavx512vl
you'll get AVX512 style masks for V4SImode data vectors but of course the
target sill supports SSE2/AVX2 style masks as well, but those would not be
available as "packed boolean vectors", though they are of course in fact
equal to V4SImode data vectors with -1 or 0 values, so in this particular
case it might not matter.
That said, the vector_mask attribute will get you V4SImode vectors with
signed boolean elements of 32 bits for V4SImode data vectors with
SSE2/AVX2.
This sounds very much like what the scenario would be with NEON vs SVE. Coming
to think
of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the
‘base’ vector type
and a ‘w’ specified for the type.
Given its current implementation, if vector_mask is exposed to the CFE, would
there be any
major challenges wrt implementation or defining behaviour semantics? I played
around with a
few examples from the testsuite and wrote some new ones. I mostly tried
operations that
the new type would have to support (unary, binary bitwise, initializations etc)
– with a couple of exceptions
most of the ops seem to be supported. I also triggered a couple of ICEs in some
tests involving
implicit conversions to wider/narrower vector_mask types (will raise reports
for these). Correct me
if I’m wrong here, but we’d probably have to support a couple of new ops if
vector_mask is exposed
to the CFE – initialization and subscript operations?
Yes, either that or restrict how the mask vectors can be used, thus
properly diagnose improper
uses.
Indeed.
A question would be for example how to write common mask test
operations like
if (any (mask)) or if (all (mask)).
I see 2 options here. New builtins could support new types - they'd
provide a target independent way to test any and all conditions. Another
would be to let the target use its intrinsics to do them in the most
efficient way possible (which the builtins would get lowered down to
anyway).
Likewise writing merge operations
- do those as
a = a | (mask ? b : 0);
thus use ternary ?: for this?
Yes, like now, the ternary could just translate to
{mask[0] ? b[0] : 0, mask[1]
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote: > > On 6/29/23 6:55 PM, Richard Biener wrote: > > On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: > >> > >> > >> > >> > >> > >> From: Richard Biener > >> Date: Tuesday, June 27, 2023 at 12:58 PM > >> To: Tejas Belagod > >> Cc: gcc-patches@gcc.gnu.org > >> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >> > >> On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod > >> wrote: > >>> > >>> > >>> > >>> > >>> > >>> From: Richard Biener > >>> Date: Monday, June 26, 2023 at 2:23 PM > >>> To: Tejas Belagod > >>> Cc: gcc-patches@gcc.gnu.org > >>> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > >>> > >>> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Packed Boolean Vectors > >>>> -- > >>>> > >>>> I'd like to propose a feature addition to GNU Vector extensions to add > >>>> packed > >>>> boolean vectors (PBV). This has been discussed in the past here[1] and > >>>> a variant has > >>>> been implemented in Clang recently[2]. > >>>> > >>>> With predication features being added to vector architectures (SVE, MVE, > >>>> AVX), > >>>> it is a useful feature to have to model predication on targets. This > >>>> could > >>>> find its use in intrinsics or just used as is as a GNU vector extension > >>>> being > >>>> mapped to underlying target features. For example, the packed boolean > >>>> vector > >>>> could directly map to a predicate register on SVE. > >>>> > >>>> Also, this new packed boolean type GNU extension can be used with SVE > >>>> ACLE > >>>> intrinsics to replace a fixed-length svbool_t. > >>>> > >>>> Here are a few options to represent the packed boolean vector type. > >>> > >>> The GIMPLE frontend uses a new 'vector_mask' attribute: > >>> > >>> typedef int v8si __attribute__((vector_size(8*sizeof(int; > >>> typedef v8si v8sib __attribute__((vector_mask)); > >>> > >>> it get's you a vector type that's the appropriate (dependent on the > >>> target) vector > >>> mask type for the vector data type (v8si in this case). > >>> > >>> > >>> > >>> Thanks Richard. > >>> > >>> Having had a quick look at the implementation, it does seem to tick the > >>> boxes. > >>> > >>> I must admit I haven't dug deep, but if the target hook allows the mask > >>> to be > >>> > >>> defined in way that is target-friendly (and I don't know how much effort > >>> it will > >>> > >>> be to migrate the attribute to more front-ends), it should do the job > >>> nicely. > >>> > >>> Let me go back and dig a bit deeper and get back with questions if any. > >> > >> > >> Let me add that the advantage of this is the compiler doesn't need > >> to support weird explicitely laid out packed boolean vectors that do > >> not match what the target supports and the user doesn't need to know > >> what the target supports (and thus have an #ifdef maze around explicitely > >> specified layouts). > >> > >> Sorry for the delayed response – I spent a day experimenting with > >> vector_mask. > >> > >> > >> > >> Yeah, this is what option 4 in the RFC is trying to achieve – be portable > >> enough > >> > >> to avoid having to sprinkle the code with ifdefs. > >> > >> > >> It does remove some flexibility though, for example with -mavx512f > >> -mavx512vl > >> you'll get AVX512 style masks for V4SImode data vectors but of course the > >> target sill supports SSE2/AVX2 style masks as well, but those would not be > >> available as "packed boolean vectors", though they are of course in fact > >> equal to V4SImode data vectors with -1 or 0 values, so in this particular > >> case it might not matter. > >> > >> That said, the
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On 6/29/23 6:55 PM, Richard Biener wrote:
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
From: Richard Biener
Date: Tuesday, June 27, 2023 at 12:58 PM
To: Tejas Belagod
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote:
From: Richard Biener
Date: Monday, June 26, 2023 at 2:23 PM
To: Tejas Belagod
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches
wrote:
Hi,
Packed Boolean Vectors
--
I'd like to propose a feature addition to GNU Vector extensions to add packed
boolean vectors (PBV). This has been discussed in the past here[1] and a
variant has
been implemented in Clang recently[2].
With predication features being added to vector architectures (SVE, MVE, AVX),
it is a useful feature to have to model predication on targets. This could
find its use in intrinsics or just used as is as a GNU vector extension being
mapped to underlying target features. For example, the packed boolean vector
could directly map to a predicate register on SVE.
Also, this new packed boolean type GNU extension can be used with SVE ACLE
intrinsics to replace a fixed-length svbool_t.
Here are a few options to represent the packed boolean vector type.
The GIMPLE frontend uses a new 'vector_mask' attribute:
typedef int v8si __attribute__((vector_size(8*sizeof(int;
typedef v8si v8sib __attribute__((vector_mask));
it get's you a vector type that's the appropriate (dependent on the
target) vector
mask type for the vector data type (v8si in this case).
Thanks Richard.
Having had a quick look at the implementation, it does seem to tick the boxes.
I must admit I haven't dug deep, but if the target hook allows the mask to be
defined in way that is target-friendly (and I don't know how much effort it will
be to migrate the attribute to more front-ends), it should do the job nicely.
Let me go back and dig a bit deeper and get back with questions if any.
Let me add that the advantage of this is the compiler doesn't need
to support weird explicitely laid out packed boolean vectors that do
not match what the target supports and the user doesn't need to know
what the target supports (and thus have an #ifdef maze around explicitely
specified layouts).
Sorry for the delayed response – I spent a day experimenting with vector_mask.
Yeah, this is what option 4 in the RFC is trying to achieve – be portable enough
to avoid having to sprinkle the code with ifdefs.
It does remove some flexibility though, for example with -mavx512f -mavx512vl
you'll get AVX512 style masks for V4SImode data vectors but of course the
target sill supports SSE2/AVX2 style masks as well, but those would not be
available as "packed boolean vectors", though they are of course in fact
equal to V4SImode data vectors with -1 or 0 values, so in this particular
case it might not matter.
That said, the vector_mask attribute will get you V4SImode vectors with
signed boolean elements of 32 bits for V4SImode data vectors with
SSE2/AVX2.
This sounds very much like what the scenario would be with NEON vs SVE. Coming
to think
of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the
‘base’ vector type
and a ‘w’ specified for the type.
Given its current implementation, if vector_mask is exposed to the CFE, would
there be any
major challenges wrt implementation or defining behaviour semantics? I played
around with a
few examples from the testsuite and wrote some new ones. I mostly tried
operations that
the new type would have to support (unary, binary bitwise, initializations etc)
– with a couple of exceptions
most of the ops seem to be supported. I also triggered a couple of ICEs in some
tests involving
implicit conversions to wider/narrower vector_mask types (will raise reports
for these). Correct me
if I’m wrong here, but we’d probably have to support a couple of new ops if
vector_mask is exposed
to the CFE – initialization and subscript operations?
Yes, either that or restrict how the mask vectors can be used, thus
properly diagnose improper
uses.
Indeed.
A question would be for example how to write common mask test
operations like
if (any (mask)) or if (all (mask)).
I see 2 options here. New builtins could support new types - they'd
provide a target independent way to test any and all conditions. Another
would be to let the target use its intrinsics to do them in the most
efficient way possible (which the builtins would get lowered down to
anyway).
Likewise writing merge operations
- do those as
a = a | (mask ? b : 0);
thus use ternary ?: for this?
Yes, like now, the ternary could just translate to
{mask[0] ? b[0] : 0, mask[1] ? b[1] : 0, ... }
One thing to flesh out is the semantics. Should we allow this operatio
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: > > > > > > From: Richard Biener > Date: Tuesday, June 27, 2023 at 12:58 PM > To: Tejas Belagod > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote: > > > > > > > > > > > > From: Richard Biener > > Date: Monday, June 26, 2023 at 2:23 PM > > To: Tejas Belagod > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > > > On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > > wrote: > > > > > > Hi, > > > > > > Packed Boolean Vectors > > > -- > > > > > > I'd like to propose a feature addition to GNU Vector extensions to add > > > packed > > > boolean vectors (PBV). This has been discussed in the past here[1] and a > > > variant has > > > been implemented in Clang recently[2]. > > > > > > With predication features being added to vector architectures (SVE, MVE, > > > AVX), > > > it is a useful feature to have to model predication on targets. This > > > could > > > find its use in intrinsics or just used as is as a GNU vector extension > > > being > > > mapped to underlying target features. For example, the packed boolean > > > vector > > > could directly map to a predicate register on SVE. > > > > > > Also, this new packed boolean type GNU extension can be used with SVE ACLE > > > intrinsics to replace a fixed-length svbool_t. > > > > > > Here are a few options to represent the packed boolean vector type. > > > > The GIMPLE frontend uses a new 'vector_mask' attribute: > > > > typedef int v8si __attribute__((vector_size(8*sizeof(int; > > typedef v8si v8sib __attribute__((vector_mask)); > > > > it get's you a vector type that's the appropriate (dependent on the > > target) vector > > mask type for the vector data type (v8si in this case). > > > > > > > > Thanks Richard. > > > > Having had a quick look at the implementation, it does seem to tick the > > boxes. > > > > I must admit I haven't dug deep, but if the target hook allows the mask to > > be > > > > defined in way that is target-friendly (and I don't know how much effort it > > will > > > > be to migrate the attribute to more front-ends), it should do the job > > nicely. > > > > Let me go back and dig a bit deeper and get back with questions if any. > > > Let me add that the advantage of this is the compiler doesn't need > to support weird explicitely laid out packed boolean vectors that do > not match what the target supports and the user doesn't need to know > what the target supports (and thus have an #ifdef maze around explicitely > specified layouts). > > Sorry for the delayed response – I spent a day experimenting with vector_mask. > > > > Yeah, this is what option 4 in the RFC is trying to achieve – be portable > enough > > to avoid having to sprinkle the code with ifdefs. > > > It does remove some flexibility though, for example with -mavx512f -mavx512vl > you'll get AVX512 style masks for V4SImode data vectors but of course the > target sill supports SSE2/AVX2 style masks as well, but those would not be > available as "packed boolean vectors", though they are of course in fact > equal to V4SImode data vectors with -1 or 0 values, so in this particular > case it might not matter. > > That said, the vector_mask attribute will get you V4SImode vectors with > signed boolean elements of 32 bits for V4SImode data vectors with > SSE2/AVX2. > > > > This sounds very much like what the scenario would be with NEON vs SVE. > Coming to think > > of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the > ‘base’ vector type > > and a ‘w’ specified for the type. > > > > Given its current implementation, if vector_mask is exposed to the CFE, would > there be any > > major challenges wrt implementation or defining behaviour semantics? I played > around with a > > few examples from the testsuite and wrote some new ones. I mostly tried > operations that > > the new type would have to support (unary, binary bitwise, initializations > etc) – with a couple of exceptions > > most of the ops seem to be supported. I also triggered a couple of ICEs in > some tests involving > > implicit conversion
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
From: Richard Biener Date: Tuesday, June 27, 2023 at 12:58 PM To: Tejas Belagod Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote: > > > > > > From: Richard Biener > Date: Monday, June 26, 2023 at 2:23 PM > To: Tejas Belagod > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches > wrote: > > > > Hi, > > > > Packed Boolean Vectors > > -- > > > > I'd like to propose a feature addition to GNU Vector extensions to add > > packed > > boolean vectors (PBV). This has been discussed in the past here[1] and a > > variant has > > been implemented in Clang recently[2]. > > > > With predication features being added to vector architectures (SVE, MVE, > > AVX), > > it is a useful feature to have to model predication on targets. This could > > find its use in intrinsics or just used as is as a GNU vector extension > > being > > mapped to underlying target features. For example, the packed boolean > > vector > > could directly map to a predicate register on SVE. > > > > Also, this new packed boolean type GNU extension can be used with SVE ACLE > > intrinsics to replace a fixed-length svbool_t. > > > > Here are a few options to represent the packed boolean vector type. > > The GIMPLE frontend uses a new 'vector_mask' attribute: > > typedef int v8si __attribute__((vector_size(8*sizeof(int; > typedef v8si v8sib __attribute__((vector_mask)); > > it get's you a vector type that's the appropriate (dependent on the > target) vector > mask type for the vector data type (v8si in this case). > > > > Thanks Richard. > > Having had a quick look at the implementation, it does seem to tick the boxes. > > I must admit I haven't dug deep, but if the target hook allows the mask to be > > defined in way that is target-friendly (and I don't know how much effort it > will > > be to migrate the attribute to more front-ends), it should do the job nicely. > > Let me go back and dig a bit deeper and get back with questions if any. Let me add that the advantage of this is the compiler doesn't need to support weird explicitely laid out packed boolean vectors that do not match what the target supports and the user doesn't need to know what the target supports (and thus have an #ifdef maze around explicitely specified layouts). Sorry for the delayed response – I spent a day experimenting with vector_mask. Yeah, this is what option 4 in the RFC is trying to achieve – be portable enough to avoid having to sprinkle the code with ifdefs. It does remove some flexibility though, for example with -mavx512f -mavx512vl you'll get AVX512 style masks for V4SImode data vectors but of course the target sill supports SSE2/AVX2 style masks as well, but those would not be available as "packed boolean vectors", though they are of course in fact equal to V4SImode data vectors with -1 or 0 values, so in this particular case it might not matter. That said, the vector_mask attribute will get you V4SImode vectors with signed boolean elements of 32 bits for V4SImode data vectors with SSE2/AVX2. This sounds very much like what the scenario would be with NEON vs SVE. Coming to think of it, vector_mask resembles option 4 in the proposal with ‘n’ implied by the ‘base’ vector type and a ‘w’ specified for the type. Given its current implementation, if vector_mask is exposed to the CFE, would there be any major challenges wrt implementation or defining behaviour semantics? I played around with a few examples from the testsuite and wrote some new ones. I mostly tried operations that the new type would have to support (unary, binary bitwise, initializations etc) – with a couple of exceptions most of the ops seem to be supported. I also triggered a couple of ICEs in some tests involving implicit conversions to wider/narrower vector_mask types (will raise reports for these). Correct me if I’m wrong here, but we’d probably have to support a couple of new ops if vector_mask is exposed to the CFE – initialization and subscript operations? Thanks, Tejas. Richard. > > > Thanks, > > Tejas. > > > > > > > > > 1. __attribute__((vector_size (n))) where n represents bytes > > > > typedef bool vbool __attribute__ ((vector_size (1))); > > > > In this approach, the shape of the boolean vector is unclear. IoW, it is not > > clear if each bit in 'n' controls a byte or an element. On targets > > like SVE, it would be natural to have each bit control a byte of the target > &
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Tue, Jun 27, 2023 at 8:30 AM Tejas Belagod wrote:
>
>
>
>
>
> From: Richard Biener
> Date: Monday, June 26, 2023 at 2:23 PM
> To: Tejas Belagod
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
>
> On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches
> wrote:
> >
> > Hi,
> >
> > Packed Boolean Vectors
> > --
> >
> > I'd like to propose a feature addition to GNU Vector extensions to add
> > packed
> > boolean vectors (PBV). This has been discussed in the past here[1] and a
> > variant has
> > been implemented in Clang recently[2].
> >
> > With predication features being added to vector architectures (SVE, MVE,
> > AVX),
> > it is a useful feature to have to model predication on targets. This could
> > find its use in intrinsics or just used as is as a GNU vector extension
> > being
> > mapped to underlying target features. For example, the packed boolean
> > vector
> > could directly map to a predicate register on SVE.
> >
> > Also, this new packed boolean type GNU extension can be used with SVE ACLE
> > intrinsics to replace a fixed-length svbool_t.
> >
> > Here are a few options to represent the packed boolean vector type.
>
> The GIMPLE frontend uses a new 'vector_mask' attribute:
>
> typedef int v8si __attribute__((vector_size(8*sizeof(int;
> typedef v8si v8sib __attribute__((vector_mask));
>
> it get's you a vector type that's the appropriate (dependent on the
> target) vector
> mask type for the vector data type (v8si in this case).
>
>
>
> Thanks Richard.
>
> Having had a quick look at the implementation, it does seem to tick the boxes.
>
> I must admit I haven't dug deep, but if the target hook allows the mask to be
>
> defined in way that is target-friendly (and I don't know how much effort it
> will
>
> be to migrate the attribute to more front-ends), it should do the job nicely.
>
> Let me go back and dig a bit deeper and get back with questions if any.
Let me add that the advantage of this is the compiler doesn't need
to support weird explicitely laid out packed boolean vectors that do
not match what the target supports and the user doesn't need to know
what the target supports (and thus have an #ifdef maze around explicitely
specified layouts).
It does remove some flexibility though, for example with -mavx512f -mavx512vl
you'll get AVX512 style masks for V4SImode data vectors but of course the
target sill supports SSE2/AVX2 style masks as well, but those would not be
available as "packed boolean vectors", though they are of course in fact
equal to V4SImode data vectors with -1 or 0 values, so in this particular
case it might not matter.
That said, the vector_mask attribute will get you V4SImode vectors with
signed boolean elements of 32 bits for V4SImode data vectors with
SSE2/AVX2.
Richard.
>
>
> Thanks,
>
> Tejas.
>
>
>
>
>
>
>
> > 1. __attribute__((vector_size (n))) where n represents bytes
> >
> > typedef bool vbool __attribute__ ((vector_size (1)));
> >
> > In this approach, the shape of the boolean vector is unclear. IoW, it is not
> > clear if each bit in 'n' controls a byte or an element. On targets
> > like SVE, it would be natural to have each bit control a byte of the target
> > vector (therefore resulting in an 'unpacked' layout of the PBV) and on AVX,
> > each
> > bit would control one element/lane on the target vector(therefore resulting
> > in a
> > 'packed' layout with all significant bits at the LSB).
> >
> > 2. __attribute__((vector_size (n))) where n represents num of lanes
> >
> > typedef int v4si __attribute__ ((vector_size (4 * sizeof (int)));
> > typedef bool v4bi __attribute__ ((vector_size (sizeof v4si / sizeof
> > (v4si){0}[0])));
> >
> > Here the 'n' in the vector_size attribute represents the number of bits that
> > is needed to represent a vector quantity. In this case, this packed boolean
> > vector can represent upto 'n' vector lanes. The size of the type is
> > rounded up the nearest byte. For example, the sizeof v4bi in the above
> > example is 1.
> >
> > In this approach, because of the nature of the representation, the n bits
> > required
> > to represent the n lanes of the vector are packed at the LSB. This does not
> > naturally
> > align with the SVE approach of each bit representing a byte of the target
> > vector
> > and PBV therefore having an 'unpacked' layout.
> >
> > More importantly, another drawback here is that the change in units
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
From: Richard Biener
Date: Monday, June 26, 2023 at 2:23 PM
To: Tejas Belagod
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches
wrote:
>
> Hi,
>
> Packed Boolean Vectors
> --
>
> I'd like to propose a feature addition to GNU Vector extensions to add packed
> boolean vectors (PBV). This has been discussed in the past here[1] and a
> variant has
> been implemented in Clang recently[2].
>
> With predication features being added to vector architectures (SVE, MVE, AVX),
> it is a useful feature to have to model predication on targets. This could
> find its use in intrinsics or just used as is as a GNU vector extension being
> mapped to underlying target features. For example, the packed boolean vector
> could directly map to a predicate register on SVE.
>
> Also, this new packed boolean type GNU extension can be used with SVE ACLE
> intrinsics to replace a fixed-length svbool_t.
>
> Here are a few options to represent the packed boolean vector type.
The GIMPLE frontend uses a new 'vector_mask' attribute:
typedef int v8si __attribute__((vector_size(8*sizeof(int;
typedef v8si v8sib __attribute__((vector_mask));
it get's you a vector type that's the appropriate (dependent on the
target) vector
mask type for the vector data type (v8si in this case).
Thanks Richard.
Having had a quick look at the implementation, it does seem to tick the boxes.
I must admit I haven't dug deep, but if the target hook allows the mask to be
defined in way that is target-friendly (and I don't know how much effort it will
be to migrate the attribute to more front-ends), it should do the job nicely.
Let me go back and dig a bit deeper and get back with questions if any.
Thanks,
Tejas.
> 1. __attribute__((vector_size (n))) where n represents bytes
>
> typedef bool vbool __attribute__ ((vector_size (1)));
>
> In this approach, the shape of the boolean vector is unclear. IoW, it is not
> clear if each bit in 'n' controls a byte or an element. On targets
> like SVE, it would be natural to have each bit control a byte of the target
> vector (therefore resulting in an 'unpacked' layout of the PBV) and on AVX,
> each
> bit would control one element/lane on the target vector(therefore resulting
> in a
> 'packed' layout with all significant bits at the LSB).
>
> 2. __attribute__((vector_size (n))) where n represents num of lanes
>
> typedef int v4si __attribute__ ((vector_size (4 * sizeof (int)));
> typedef bool v4bi __attribute__ ((vector_size (sizeof v4si / sizeof
> (v4si){0}[0])));
>
> Here the 'n' in the vector_size attribute represents the number of bits that
> is needed to represent a vector quantity. In this case, this packed boolean
> vector can represent upto 'n' vector lanes. The size of the type is
> rounded up the nearest byte. For example, the sizeof v4bi in the above
> example is 1.
>
> In this approach, because of the nature of the representation, the n bits
> required
> to represent the n lanes of the vector are packed at the LSB. This does not
> naturally
> align with the SVE approach of each bit representing a byte of the target
> vector
> and PBV therefore having an 'unpacked' layout.
>
> More importantly, another drawback here is that the change in units for
> vector_size
> might be confusing to programmers. The units will have to be interpreted
> based on the
> base type of the typedef. It does not offer any flexibility in terms of the
> layout of
> the bool vector - it is fixed.
>
> 3. Combination of 1 and 2.
>
> Combining the best of 1 and 2, we can introduce extra parameters to
> vector_size that will
> unambiguously represent the layout of the PBV. Consider
>
> typedef bool vbool __attribute__((vector_size (s, n[, w])));
>
> where 's' is size in bytes, 'n' is the number of lanes and an optional 3rd
> parameter 'w'
> is the number of bits of the PBV that represents a lane of the target vector.
> 'w' would
> allow a target to force a certain layout of the PBV.
>
> The 2-parameter form of vector_size allows the target to have an
> implementation-defined layout of the PBV. The target is free to choose the 'w'
> if it is not specified to mirror the target layout of predicate registers. For
> eg. AVX would choose 'w' as 1 and SVE would choose s*8/n.
>
> As an example, to represent the result of a comparison on 2 int16x8_t, we'd
> need
> 8 lanes of boolean which could be represented by
>
> typedef bool v8b __attribute__ ((vector_size (2, 8)));
>
> SVE would implement v8b layout to make every 2nd bit significant i.e. w == 2
>
> and AVX would choose a layout where all 8 consecutive bit
Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
On Mon, Jun 26, 2023 at 8:24 AM Tejas Belagod via Gcc-patches
wrote:
>
> Hi,
>
> Packed Boolean Vectors
> --
>
> I'd like to propose a feature addition to GNU Vector extensions to add packed
> boolean vectors (PBV). This has been discussed in the past here[1] and a
> variant has
> been implemented in Clang recently[2].
>
> With predication features being added to vector architectures (SVE, MVE, AVX),
> it is a useful feature to have to model predication on targets. This could
> find its use in intrinsics or just used as is as a GNU vector extension being
> mapped to underlying target features. For example, the packed boolean vector
> could directly map to a predicate register on SVE.
>
> Also, this new packed boolean type GNU extension can be used with SVE ACLE
> intrinsics to replace a fixed-length svbool_t.
>
> Here are a few options to represent the packed boolean vector type.
The GIMPLE frontend uses a new 'vector_mask' attribute:
typedef int v8si __attribute__((vector_size(8*sizeof(int;
typedef v8si v8sib __attribute__((vector_mask));
it get's you a vector type that's the appropriate (dependent on the
target) vector
mask type for the vector data type (v8si in this case).
> 1. __attribute__((vector_size (n))) where n represents bytes
>
> typedef bool vbool __attribute__ ((vector_size (1)));
>
> In this approach, the shape of the boolean vector is unclear. IoW, it is not
> clear if each bit in 'n' controls a byte or an element. On targets
> like SVE, it would be natural to have each bit control a byte of the target
> vector (therefore resulting in an 'unpacked' layout of the PBV) and on AVX,
> each
> bit would control one element/lane on the target vector(therefore resulting
> in a
> 'packed' layout with all significant bits at the LSB).
>
> 2. __attribute__((vector_size (n))) where n represents num of lanes
>
> typedef int v4si __attribute__ ((vector_size (4 * sizeof (int)));
> typedef bool v4bi __attribute__ ((vector_size (sizeof v4si / sizeof
> (v4si){0}[0])));
>
> Here the 'n' in the vector_size attribute represents the number of bits that
> is needed to represent a vector quantity. In this case, this packed boolean
> vector can represent upto 'n' vector lanes. The size of the type is
> rounded up the nearest byte. For example, the sizeof v4bi in the above
> example is 1.
>
> In this approach, because of the nature of the representation, the n bits
> required
> to represent the n lanes of the vector are packed at the LSB. This does not
> naturally
> align with the SVE approach of each bit representing a byte of the target
> vector
> and PBV therefore having an 'unpacked' layout.
>
> More importantly, another drawback here is that the change in units for
> vector_size
> might be confusing to programmers. The units will have to be interpreted
> based on the
> base type of the typedef. It does not offer any flexibility in terms of the
> layout of
> the bool vector - it is fixed.
>
> 3. Combination of 1 and 2.
>
> Combining the best of 1 and 2, we can introduce extra parameters to
> vector_size that will
> unambiguously represent the layout of the PBV. Consider
>
> typedef bool vbool __attribute__((vector_size (s, n[, w])));
>
> where 's' is size in bytes, 'n' is the number of lanes and an optional 3rd
> parameter 'w'
> is the number of bits of the PBV that represents a lane of the target vector.
> 'w' would
> allow a target to force a certain layout of the PBV.
>
> The 2-parameter form of vector_size allows the target to have an
> implementation-defined layout of the PBV. The target is free to choose the 'w'
> if it is not specified to mirror the target layout of predicate registers. For
> eg. AVX would choose 'w' as 1 and SVE would choose s*8/n.
>
> As an example, to represent the result of a comparison on 2 int16x8_t, we'd
> need
> 8 lanes of boolean which could be represented by
>
> typedef bool v8b __attribute__ ((vector_size (2, 8)));
>
> SVE would implement v8b layout to make every 2nd bit significant i.e. w == 2
>
> and AVX would choose a layout where all 8 consecutive bits packed at LSB would
> be significant i.e. w == 1.
>
> This scheme would accomodate more than 1 target to effectively represent
> vector
> bools that mirror the target properties.
>
> 4. A new attribite
>
> This is based on a suggestion from Richard S in [3]. The idea is to introduce
> a new
> attribute to define the PBV and make it general enough to
>
> * represent all targets flexibly (SVE, AVX etc)
> * represent sub-byte length predicates
> * have no change in units of vector_size/no new vector_size signature
> * not have the number of bytes constrain representation
>
> If we call the new attribute 'bool_vec' (for lack of a better name), consider
>
> typedef bool vbool __attribute__((bool_vec (n[, w])))
>
> where 'n' represents number of lanes/elements and the optional 'w' is
> bits-per-lane.
>
> If 'w' is not specified, it and bytes-per-predicate are
>
