[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## ARM SVE issues with non "standard" vector lengths

**From**: |
Laurent Desnogues |

**Subject**: |
ARM SVE issues with non "standard" vector lengths |

**Date**: |
Thu, 23 Apr 2020 15:59:46 +0200 |

Hello,
I found the following issues in SVE while playing with a vector length
of 640-bit.
1. sve_uzp_p
I think the comment about VL not being a power of 2 should be that VL
is not a multiple of 512-bit elements with VL > 512 (not sure how to
phrase that properly).
if (oprsz & 15) {
d[i] = compress_bits(n[2 * i] >> odd, esz);
Here n[2 * i + 1] should be taken into account.
for (i = 0; i < oprsz_16; i++) {
l = m[2 * i + 0];
h = m[2 * i + 1];
l = compress_bits(l >> odd, esz);
h = compress_bits(h >> odd, esz);
tmp_m.p[i] = l + (h << 32);
}
tmp_m.p[i] = compress_bits(m[2 * i] >> odd, esz);
Here m[2 * i + 1] should be taken into account.
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 hope I got all of this correctly I'm not familiar with that
implementation of SVE :)
Thanks,
Laurent

**ARM SVE issues with non "standard" vector lengths**,
*Laurent Desnogues* **<=**