Richard Biener <[email protected]> writes:
> On Fri, Jun 28, 2024 at 8:01 AM Richard Biener
> <[email protected]> wrote:
>>
>> On Fri, Jun 28, 2024 at 3:15 AM liuhongt <[email protected]> wrote:
>> >
>> > for the testcase in the PR115406, here is part of the dump.
>> >
>> > char D.4882;
>> > vector(1) <signed-boolean:8> _1;
>> > vector(1) signed char _2;
>> > char _5;
>> >
>> > <bb 2> :
>> > _1 = { -1 };
>> >
>> > When assign { -1 } to vector(1} {signed-boolean:8},
>> > Since TYPE_PRECISION (itype) <= BITS_PER_UNIT, so it set each bit of dest
>> > with each vector elemnet. But i think the bit setting should only apply for
>> > TYPE_PRECISION (itype) < BITS_PER_UNIT. .i.e for vector(1).
>> > <signed-boolean:16>, it will be assigned as -1, instead of 1.
>> > Is there any specific reason vector(1) <signed-boolean:8> is handled
>> > differently from vector<1> <signed-boolean:16>?
>> >
>> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
>> > Ok for trunk?
>>
>> I agree that <= BITS_PER_UNIT is suspicious, but the bit-precision
>> code should work for 8 bit
>> entities as well, it seems we only set the LSB of each element in the
>> "mask". ISTR that SVE
>> masks can have up to 8 bit elements (for 8 byte data elements), so
>> maybe that's why
>> <= BITS_PER_UNIT.
Yeah.
>> So maybe instead of just setting one bit in
>>
>> ptr[bit / BITS_PER_UNIT] |= 1 << (bit % BITS_PER_UNIT);
>>
>> we should set elt_bits bits, aka (without testing)
>>
>> ptr[bit / BITS_PER_UNIT] |= (1 << elt_bits - 1) << (bit
>> % BITS_PER_UNIT);
>>
>> ?
>
> Alternatively
>
> if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (expr))
> && TYPE_PRECISION (itype) <= BITS_PER_UNIT)
>
> should be amended with
>
> && GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (expr))) != MODE_VECTOR_INT
How about:
if (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (expr))) == MODE_VECTOR_BOOL)
{
gcc_assert (TYPE_PRECISION (itype) <= BITS_PER_UNIT);
?
Is it OK for TYPE_MODE to affect tree-level semantics though, especially
since it can change with the target attribute? (At least TYPE_MODE_RAW
would be stable.)
> maybe. Still for the possibility of vector(n) <signed-boolean:16>
> mask for a int128 element vector
> we'd have 16bit mask elements, encoding that differently would be
> inconsistent as well
> (but of course 16bit elements are not handled by the code right now).
Yeah, 16-bit predicate elements aren't a thing for SVE, so we've not
had to add support for them.
Richard
