target/arm: fix some simd writes vs sve

[PATCH 0/4] target/arm: fix some simd writes vs sve

Richard Henderson posted 4 patches 5 years, 9 months ago

Download series mbox

Test docker-quick@centos7 passed

Test FreeBSD passed

Test docker-mingw@fedora passed

Test checkpatch passed

Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20200214194643.23317-1-richard.henderson@linaro.org

Maintainers: Peter Maydell <peter.maydell@linaro.org>

target/arm/translate-a64.c | 9 +++++++++
1 file changed, 9 insertions(+)

Expand all Fold all

[PATCH 0/4] target/arm: fix some simd writes vs sve

Posted by Richard Henderson 5 years, 9 months ago

The launchpad bug only mentions EXT, but I found three more
via inspection.  I really should extend RISU so that we can
do AdvSIMD testing with SVE enabled...


r~


Richard Henderson (4):
  target/arm: Flush high bits of sve register after AdvSIMD EXT
  target/arm: Flush high bits of sve register after AdvSIMD TBL/TBX
  target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRN
  target/arm: Flush high bits of sve register after AdvSIMD INS

 target/arm/translate-a64.c | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
2.20.1

Re: [PATCH 0/4] target/arm: fix some simd writes vs sve

Posted by Peter Maydell 5 years, 8 months ago

On Fri, 14 Feb 2020 at 19:46, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> The launchpad bug only mentions EXT, but I found three more
> via inspection.  I really should extend RISU so that we can
> do AdvSIMD testing with SVE enabled...

Applied to target-arm.next, thanks.

I did a quick pass through for other functions that seem to call
write_vec_element() but not clear_vec_high() -- do any of these
need fixes?
- handle_vec_simd_wshli()
- handle_3rd_widening()
- handle_3rd_wide()
- handle_pmull_64()
- handle_simd_3same_pair(), "size == 3" branch
- handle_2misc_widening()
- handle_rev(), "size != 0" branch
- handle_2misc_pairwise()
- handle_shll()
- disas_simd_indexed() final else branch (the one with the second
  of the two identical comments about "The simplest way to handle
  the 16x16 indexed ops")
- disas_crypto_three_reg_sha512()
- disas_crypto_four_reg()
- disas_crypto_xar()

Probably false positives in that list, I just did a quick eyeball.

We could probably test this with risu by having the startup code
fill in the top parts of the SVE regs with non-zero and then
making sure they're included in the comparison after insns.
You'd need to test each insn in a separate risu run, though,
otherwise the first insn in the block clears the Z regs and we
don't get to tell if the insn after it does...

thanks
-- PMM