[ARM] PR98435: Missed optimization in expanding vector constructor

[Prathamesh Kulkarni via Gcc-patches]

Hi,
As mentioned in PR, for the following test-case:

#include <arm_neon.h>

bfloat16x4_t f1 (bfloat16_t a)
{
  return vdup_n_bf16 (a);
}

bfloat16x4_t f2 (bfloat16_t a)
{
  return (bfloat16x4_t) {a, a, a, a};
}

Compiling with arm-linux-gnueabi -O3 -mfpu=neon -mfloat-abi=softfp
-march=armv8.2-a+bf16+fp16 results in f2 not being vectorized:

f1:
        vdup.16 d16, r0
        vmov    r0, r1, d16  @ v4bf
        bx      lr

f2:
        mov     r3, r0  @ __bf16
        adr     r1, .L4
        ldrd    r0, [r1]
        mov     r2, r3  @ __bf16
        mov     ip, r3  @ __bf16
        bfi     r1, r2, #0, #16
        bfi     r0, ip, #0, #16
        bfi     r1, r3, #16, #16
        bfi     r0, r2, #16, #16
        bx      lr

This seems to happen because vec_init pattern in neon.md has VDQ mode
iterator, which doesn't include V4BF. In attached patch, I changed
mode
to VDQX which seems to work for the test-case, and the compiler now generates:

f2:
        vdup.16 d16, r0
        vmov    r0, r1, d16  @ v4bf
        bx      lr

However, the pattern is also gated on TARGET_HAVE_MVE and I am not
sure if either VDQ or VDQX are correct modes for MVE since MVE has
only 128-bit vectors ?

Thanks,
Prathamesh