Hi all,

I just found a bug that goes back to the initial merge of
the MVE backend: The vcreate intrinsic has had it's vector
lanes mixed up, compared to what was intended (as per
the ACLE) definition. This is also a discrepancy with clang:
https://godbolt.org/z/4n93e5aqj

This patches simply switches the operands around and
makes the tests more specific on the input registers
(I do not touch the output Q regs as they vary based
on softfp/hardfp or the input registers when the input
is a constant, since, in that case, a single register
is loaded with a constant and then the same register is
used twice as "vmov q0[2], q0[0], r2, r2" and the reg
num might also not always be guaranteed).

No regressions on MVE tesctsuite configurations or in
the CMSIS-NN testsuite.

Ok for trunk? (Despite this being late in Stage 4, sorry
about that!)

Thanks,
Stamatis Markianos-Wright

gcc/ChangeLog:

         * config/arm/mve.md (mve_vcvtq_n_to_f_<supf><mode>): Swap operands.
           (mve_vcreateq_f<mode>): Swap operands.

gcc/testsuite/ChangeLog:

         * gcc.target/arm/mve/intrinsics/vcreateq_f16.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_f32.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_s16.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_s32.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_s64.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_s8.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_u16.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_u32.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_u64.c: Tighten test.
         * gcc.target/arm/mve/intrinsics/vcreateq_u8.c: Tighten test.