@azoff wrote in
https://forge.sourceware.org/gcc/gcc/pulls/208#issuecomment-7038:
> I took v2 for a spin and the crypto tests are changed from XFAIL -> PASS, but
> there are the following regressions for -mfloat-abi=soft:
>
> +FAIL: gcc.target/arm/armv8_2-fp16-neon-1.c scan-assembler-times
> vdup\.16\td[0-9]+, r[0-9]+ 2
> +FAIL: gcc.target/arm/armv8_2-fp16-neon-1.c scan-assembler-times
> vdup\.16\tq[0-9]+, r[0-9]+ 2
> +FAIL: gcc.target/arm/armv8_2-fp16-neon-1.c scan-assembler-times
> vdup\.16\td[0-9]+, d[0-9]+\[1\] 1
> +FAIL: gcc.target/arm/armv8_2-fp16-neon-1.c scan-assembler-times
> vdup\.16\tq[0-9]+, d[0-9]+\[1\] 1
This is just some more fallout of the new code sequence. For a couple of tests
we now get
```
lsrs r3, r0, #16
vdup.16 d16, r3
vmov r0, r1, d16 @ v4hf
```
instead of the inferior
```
vmov d16, r0, r1 @ v4hf
vdup.16 d16, d16[1]
vmov r0, r1, d16 @ v4hf
```
or similar for the 128-bit result types. Other tests then fail because
scan-assembler looks across the entire file and we hit increased matches on
other scans.
I've fixed all the issues by converting the relevant scan-assembler tests to
match-function-bodies tests.
--
https://forge.sourceware.org/gcc/gcc/pulls/208#issuecomment-7039
