[PATCH] arm: Fix bugs with MVE vmov from two GPRs to vector lanes

[Alex Coplan]

Hi all,

Please find a compressed patch.gz attached, the original patch is over
the 400KB limit for submission to the list.

The initial problem I wanted to fix here is that GAS was rejecting MVE
instructions such as:

vmov q3[2], q3[0], r2, r2

with:

Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2'

which is incorrect; such instructions are valid. Note that for moves in
the other direction, e.g.:

vmov r2, r2, q3[2], q3[0]

GAS is correct in rejecting this as it does not make sense to move both
lanes into the same register (the Arm ARM says this is CONSTRAINED
UNPREDICTABLE).

After fixing this issue, I added exhaustive assembly/disassembly tests
for these vmovs. This revealed several disassembly issues, including
incorrectly marking the moves into vector lanes as UNPREDICTABLE, and
disassembling many of the vmovs as vector loads. These are now fixed.

Regtested on arm-eabi, no regressions.

OK for trunk? What about backports?

Thanks,
Alex

gas/ChangeLog:

	* config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving
	into the same GPR twice.
	* testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message.
	* testsuite/gas/arm/mve-vmov-3.d: New test.
	* testsuite/gas/arm/mve-vmov-3.s: New test.

opcodes/ChangeLog:

	* arm-dis.c (mve_opcodes): Fix disassembly of
	MVE_VMOV2_GP_TO_VEC_LANE when idx == 1.
	(is_mve_encoding_conflict): MVE vector loads should not match
	when P = W = 0.
	(is_mve_unpredictable): It's not unpredictable to use the same
	source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.gz
Type: application/gzip
Size: 40252 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20210514/90b7b3c5/attachment-0001.gz>