Re: ARM SVE issues with non "standard" vector lengths

Re: ARM SVE issues with non "standard" vector lengths

[Laurent Desnogues]

On Thu, Apr 23, 2020 at 5:19 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 4/23/20 6:59 AM, Laurent Desnogues wrote:
> > 2. sve_zip_p
> >
> > This generates extraneous data in the higher part of the result.
> >
> > I hit this when I got a wrong result on an instruction that ends up
> > using sve_cntp which counts all bits set in each 64-bit chunk. There
> > might be some other instructions beyond ZIP that generate extra data
> > that would break sve_cntp.  So perhaps it'd be easier to fix sve_cmtp
> > (and hope that it's the only function that uses bits beyond vector
> > length...).
>
> There are quite a few places that assume (and some that assert, such as the
> load/store paths) that there are no predicate bits set beyond VL.
>
> I will fix zip.

Looking at the code I think sve_punpk_p is affected too.

Thanks,

Laurent

>
>
> r~

Re: ARM SVE issues with non "standard" vector lengths

[Richard Henderson]

On 4/23/20 6:59 AM, Laurent Desnogues wrote:
> 2. sve_zip_p
> 
> This generates extraneous data in the higher part of the result.
> 
> I hit this when I got a wrong result on an instruction that ends up
> using sve_cntp which counts all bits set in each 64-bit chunk. There
> might be some other instructions beyond ZIP that generate extra data
> that would break sve_cntp.  So perhaps it'd be easier to fix sve_cmtp
> (and hope that it's the only function that uses bits beyond vector
> length...).

I don't see how sve_zip_p can set high bits.  If vl is not a multiple of 512,
it writes in units of uint16_t.  This cannot produce values outside range.

Are you certain that the high bits were not set and left over by some previous
buggy operation, since the uint16_t writes would not clear any extra bits?


r~

Re: ARM SVE issues with non "standard" vector lengths

[Richard Henderson]

On 4/25/20 11:49 AM, Richard Henderson wrote:
> On 4/23/20 6:59 AM, Laurent Desnogues wrote:
>> 2. sve_zip_p
>>
>> This generates extraneous data in the higher part of the result.
>>
>> I hit this when I got a wrong result on an instruction that ends up
>> using sve_cntp which counts all bits set in each 64-bit chunk. There
>> might be some other instructions beyond ZIP that generate extra data
>> that would break sve_cntp.  So perhaps it'd be easier to fix sve_cmtp
>> (and hope that it's the only function that uses bits beyond vector
>> length...).
> 
> I don't see how sve_zip_p can set high bits.  If vl is not a multiple of 512,
> it writes in units of uint16_t.  This cannot produce values outside range.

Bah.  I was looking at zip2 first.  zip1 uses the uint64_t path.
I see the problem now.


r~

Re: ARM SVE issues with non "standard" vector lengths

[Richard Henderson]

On 4/23/20 9:24 AM, Laurent Desnogues wrote:
> Looking at the code I think sve_punpk_p is affected too.

Got it.  Same issue as zip1.


r~