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. 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.
Richard.
> Thanks,
> Tejas.
