On 12/30/24 8:16 AM, Richard Sandiford wrote:
Andrew Pinski writes:
On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
Thanks for the helpful suggestion. The attached v2 patch tries to implement
it.
It was bootstrapped and regtested on x86, aarch64 and Power 10.
Also regtested on rv64gcv_
Jeff Law writes:
> On 12/30/24 8:16 AM, Richard Sandiford wrote:
>
>>
>> The divisor is by definition 1. I think dropping it would make the
>> loop more obviously correct, since the same assumption is implicit in
>> the loop body.
> I'll likely pick this up as Robin is on PTO for the next ~10 da
On 12/30/24 8:16 AM, Richard Sandiford wrote:
The divisor is by definition 1. I think dropping it would make the
loop more obviously correct, since the same assumption is implicit in
the loop body.
I'll likely pick this up as Robin is on PTO for the next ~10 days. So
just to be 100% clear
Andrew Pinski writes:
> On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
>>
>> Thanks for the helpful suggestion. The attached v2 patch tries to implement
>> it.
>>
>> It was bootstrapped and regtested on x86, aarch64 and Power 10.
>> Also regtested on rv64gcv_zvl512b.
>>
>> Those are all littl
On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
>
> Thanks for the helpful suggestion. The attached v2 patch tries to implement
> it.
>
> It was bootstrapped and regtested on x86, aarch64 and Power 10.
> Also regtested on rv64gcv_zvl512b.
>
> Those are all little-endian (sub)targets, though, so
Thanks for the helpful suggestion. The attached v2 patch tries to implement
it.
It was bootstrapped and regtested on x86, aarch64 and Power 10.
Also regtested on rv64gcv_zvl512b.
Those are all little-endian (sub)targets, though, so it would certainly be
helpful if you could run additional aarch6
"Robin Dapp" writes:
> [PATCH] varasm: Use native_encode_rtx for constant vectors.
>
> optimize_constant_pool hashes vector masks by native_encode_rtx and
> merges identically hashed values in the constant pool. Afterwards the
> optimized values are written in output_constant_pool_2.
>
> However,
> from output_constant_pool_2 and make it defer to native_encode_rtx
> instead. That seems like the most direct way of avoiding mishaps.
>
> E.g. another way in which different routines could make different choices
> is in whether, for SVE's VNx8BI (say), they fill the upper bit of each
> 2-bit el
"Robin Dapp" writes:
>> "Robin Dapp" writes:
>>> But here I intended to just change the encoded value in memory and to
>>> prevent it from aliasing with other encoded values.
>>> In an actual instruction the values we "padded" (or that are beyond the
>>> vector length) are ignored. For the purpo
> "Robin Dapp" writes:
>> But here I intended to just change the encoded value in memory and to
>> prevent it from aliasing with other encoded values.
>> In an actual instruction the values we "padded" (or that are beyond the
>> vector length) are ignored. For the purpose of hashing a mask of
>>
"Robin Dapp" writes:
> But here I intended to just change the encoded value in memory and to
> prevent it from aliasing with other encoded values.
> In an actual instruction the values we "padded" (or that are beyond the
> vector length) are ignored. For the purpose of hashing a mask of
> "1010"
>> How does encoding work for SVE's small mask modes? I suppose
>>
>> unsigned int elt_bits = vector_element_size (GET_MODE_PRECISION (mode),
>> GET_MODE_NUNITS (mode));
>>
>> is != 1 but rather adjusted so a byte is filled?
>
> It's 1 for VNx1
"Robin Dapp" writes:
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
>
> Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
> "b
Gentle ping. Any guidance on how to continue here?
--
Regards
Robin
> Am 25.11.2024 um 15:36 schrieb Robin Dapp :
>
>
>>
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
Btw, we’ve been there on the tree level wit
> ...it's not clear to me that we should define the upper bits of the
> byte to be zero. What would rely on that? Is it something that we'd
> require for all loads and stores of such modes?
Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
"balanced" mask representation i
"Robin Dapp" writes:
> Hi,
>
> this came up when testing even/odd permutes on riscv
> (https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669181.html).
> I didn't yet continue with the patch but it's clear it
> exposes an issue with encoding vector masks.
>
> When we encode a vector mask with
17 matches
Mail list logo
