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. 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. Richard. > Jakub >
