On Wed, Jul 17, 2024 at 1:53 PM Tejas Belagod <tejas.bela...@arm.com> wrote:
>
> On 7/17/24 4:36 PM, Richard Biener wrote:
> > On Wed, Jul 17, 2024 at 10:17 AM Tejas Belagod <tejas.bela...@arm.com>
> > wrote:
> >>
> >> On 7/15/24 6:05 PM, Richard Biener wrote:
> >>> On Mon, Jul 15, 2024 at 1:22 PM Tejas Belagod <tejas.bela...@arm.com>
> >>> wrote:
> >>>>
> >>>> On 7/15/24 12:16 PM, Tejas Belagod wrote:
> >>>>> On 7/12/24 6:40 PM, Richard Biener wrote:
> >>>>>> On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek <ja...@redhat.com> wrote:
> >>>>>>>
> >>>>>>> On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
> >>>>>>>> Padding is only an issue for very small vectors - the obvious choice
> >>>>>>>> is
> >>>>>>>> to disallow vector types that would require any padding. I can
> >>>>>>>> hardly
> >>>>>>>> see where those are faster than using a vector of up to 4 char
> >>>>>>>> elements.
> >>>>>>>> Problematic are 1-bit elements with 4, 2 or one element vectors,
> >>>>>>>> 2-bit elements
> >>>>>>>> with 2 or one element vectors and 4-bit elements with 1 element
> >>>>>>>> vectors.
> >>>>>>>
> >>>>>>> I'd really like to avoid having to support something like
> >>>>>>> _BitInt(16372) __attribute__((vector_size (sizeof (_BitInt(16372)) *
> >>>>>>> 16)))
> >>>>>>> _BitInt(2) to say size of long long could be acceptable.
> >>>>>>
> >>>>>> I'd disallow _BitInt(n) with n >= 8, it should be just the syntactic
> >>>>>> way to say
> >>>>>> the element should have n (< 8) bits.
> >>>>>>
> >>>>>>>> I have no idea what the stance of supporting _BitInt in C++ are,
> >>>>>>>> but most certainly diverging support (or even semantics) of the
> >>>>>>>> vector extension in C vs. C++ is undesirable.
> >>>>>>>
> >>>>>>> I believe Clang supports it in C++ next to C, GCC doesn't and Jason
> >>>>>>> didn't
> >>>>>>> look favorably to _BitInt support in C++, so at least until something
> >>>>>>> like
> >>>>>>> that is standardized in C++ the answer is probably no.
> >>>>>>
> >>>>>> OK, I think that rules out _BitInt use here so while bool is then
> >>>>>> natural
> >>>>>> for 1-bit elements for 2-bit and 4-bit elements we'd have to specify
> >>>>>> the
> >>>>>> number of bits explicitly. There is signed_bool_precision but like
> >>>>>> vector_mask it's use is restricted to the GIMPLE frontend because
> >>>>>> interaction with the rest of the language isn't defined.
> >>>>>>
> >>>>>
> >>>>> Thanks for all the suggestions - really insightful (to me) discussions.
> >>>>>
> >>>>> Yeah, BitInt seemed like it was best placed for this, but not having C++
> >>>>> support is definitely a blocker. But as you say, in the absence of
> >>>>> BitInt, bool becomes the natural choice for bit sizes 1, 2 and 4. One
> >>>>> way to specify non-1-bit widths could be overloading vector_size.
> >>>>>
> >>>>> Also, I think overloading GIMPLE's vector_mask takes us into the
> >>>>> earlier-discussed territory of what it should actually mean - it meaning
> >>>>> the target truth type in GIMPLE and a generic vector extension in the FE
> >>>>> will probably confuse gcc developers more than users.
> >>>>>
> >>>>>> That said - we're mixing two things here. The desire to have "proper"
> >>>>>> svbool (fix: declare in the backend) and the desire to have "packed"
> >>>>>> bit-precision vectors (for whatever actual reason) as part of the
> >>>>>> GCC vector extension.
> >>>>>>
> >>>>>
> >>>>> If we leave lane-disambiguation of svbool to the backend, the values I
> >>>>> see in supporting 1, 2 and 4 bitsizes are 1) first step towards
> >>>>> supporting BitInt(N) vectors possibly in the future 2) having a way for
> >>>>> targets to define their intrinsics' bool vector types using GNU
> >>>>> extensions 3) feature parity with Clang's ext_vector_type?
> >>>>>
> >>>>> I believe the primary motivation for Clang to support ext_vector_type
> >>>>> was to have a way to define target intrinsics' vector bool type using
> >>>>> vector extensions.
> >>>>>
> >>>>
> >>>>
> >>>> Interestingly, Clang seems to support
> >>>>
> >>>> typedef struct {
> >>>> _Bool i:1;
> >>>> } STR;
> >>>>
> >>>> typedef struct { _Bool i: 1; } __attribute__((vector_size (sizeof (STR)
> >>>> * 4))) vec;
> >>>>
> >>>>
> >>>> int foo (vec b) {
> >>>> return sizeof b;
> >>>> }
> >>>>
> >>>> I can't find documentation about how it is implemented, but I suspect
> >>>> the vector is constructed as an array STR[] i.e. possibly each
> >>>> bit-element padded to byte boundary etc. Also, I can't seem to apply
> >>>> many operations other than sizeof.
> >>>>
> >>>> I don't know if we've tried to support such cases in GNU in the past?
> >>>
> >>> Why should we do that? It doesn't make much sense.
> >>>
> >>> single-bit vectors is what _BitInt was invented for.
> >>
> >> Forgive me if I'm misunderstanding - I'm trying to figure out how
> >> _BitInts can be made to have single-bit generic vector semantics. For
> >> eg. If I want to initialize a _BitInt as vector, I can't do:
> >>
> >> _BitInt (4) a = (_BitInt (4)){1, 0, 1, 1};
> >>
> >> as 'a' expects a scalar initialization.
> >>
> >> Of if I want to convert an int vector to bit vector, I can't do
> >>
> >> v4si_p = v4si_a > v4si_b;
> >> _BitInt (4) vbool = __builtin_convertvector (v4si_p, _BitInt (4));
> >>
> >> Also semantics of conditionals with _BitInt behave like scalars
> >>
> >> _BitInt (4) p = a && b; // Here a and b are _BitInt (4), but they
> >> behave as scalars.
> >>
> >> Also, I can't do things like
> >>
> >> typedef _BitInt (2) vbool __attribute__((vector_size(sizeof (_BitInt
> >> (2)) * 4)));
> >>
> >> to force it to behave as a vector because _BitInt is disallowed here.
> >>
> >
> > All I'm trying to say is that when people want to use vector<bool> as
> > a large packed bitfield they can now use _BitInt instead. Of course
> > with a different (but portable) API.
> > > I don't see single-bit element vectors something as especially
> > useful with a "vector API". What's its the use-case? (similar
> > for the two and four bit elements, with or without padding)
> >
>
> I'm trying to figure out if we had a portable (generic) way to represent
> predicate vectors(eg BitInts) in the front end, and had rules(or a
> vector API?)) that cast from integer vectors acting as bools to BitInts,
> would it be more efficient to lower to target predicate modes (VNx16BI
> etc on targets that support n-bit mode predicates)? It could also
> possibly interoperate with target intrinsics better than int bool vectors.
No, we don't have an existing way to represent predicate vectors. And no,
I don't think there's good evidence of necessity for supporting one
within the realm
of GCCs generic vector extension. But there's plenty of doubt a portable
and performant way of doing this is possible.
Richard.
> I don't know if this is a compelling-enough use-case.
>
> Thanks,
> Tejas.
>
>
> > Richard.
> >
> >> 2-bit and 4-bit
> >>> element vectors is what's missing, but the scope is narrow and
> >>> efficient lowering or native support is missing. Vectors of bit
> >>> elements but with padding is just something stupid to look for
> >>> as a general feature.
> >>>
> >>
> >> Fair enough.
> >>
> >>
> >> Thanks,
> >> Tejas.
> >>
> >>
> >>> Richard.
> >>>
> >>>> Thanks,
> >>>> Tejas.
> >>
>
