On Wed, Oct 15, 2025 at 02:21:15PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 15, 2025 at 02:15:39PM +0200, Richard Biener wrote:
> > > In v1 of this patch [1], I asked [2] the same thing, and the consensus
> > > seem to have been that we should look at modes precisely to only work on
> > > packed boolean vectors (TYPE_PRECISION of 1 bit is true for them but it
> > > also true for other types).
> > 

Richard,

> > Which "other" VECTOR_BOOLEAN_TYPE_P types you mean?  Note not all
> > VECTOR_BOOLEAN_TYPE_P types have 1-bit element precision.

Again, reading the comments in the code, VECTOR_BOOLEAN_TYPE_P just
tells use that this is a vector of booleans, however the specifics of
the element type is restricted.

> > 
> > I'll note that types is what users write and DWARF is supposed to
> > represent source.  Modes are an implementation detail, and in
> > particular those might change between functions, for example to
> > BLKmode if not supported.
> 
> Yeah, but we don't allow typedef bool VB __attribute__((vector_size (N)));
> and even decltype (vect1 == vect2) in C++ (or typeof in C) will not be
> VECTOR_BOOLEAN_TYPE_P I think, so I think one can see VECTOR_BOOLEAN_TYPE_P
> in dwarf2out.cc hopefully only for the backend special types like aarch64
> or riscv have.
> And at that point, I think it is probably fine to use TYPE_MODE_RAW if it
> will be always MODE_VECTOR_BOOL in those cases and derive generically the
> debug info properties from that

OK, I'll try that.

> instead of having a target hook that needs
> to do that for each target.

Jakub, I forgot to reply to the part of your email in the v1 thread [1] about
VECTOR_BOOL_MODE in machmode.def:

>     VECTOR_BOOL_MODE (NAME, COUNT, COMPONENT, BYTESIZE)
>        Create a vector mode called NAME that contains COUNT boolean
>        elements and occupies BYTESIZE bytes in total.  Each boolean
>        element is of COMPONENT type and occupies (COUNT * BITS_PER_UNIT) /
>        BYTESIZE bits, with the element at index 0 occupying the lsb of the
>        first byte in memory.  Only the lowest bit of each element is
>        significant.
> documentation applies.  That isn't always 1-bit stride, guess sometimes
>  ...
> Though the comment looks wrong,
> I think each boolean element occupies (BYTESIZE * BITS_PER_UNIT) / COUNT
> bits, not the other way around.

I agree, this comment is wrong and your formula seems correct.

So, I should set bit-stride to (BYTESIZE * BITS_PER_UNIT) / COUNT based
on the information from the mode, and set bit-size to TYPE_PRECISION.

[1]: https://inbox.sourceware.org/gcc-patches/aOO06GS94739a0Cv@tucnak/

Kind regards,
Yury

Reply via email to