On Mon, Oct 11, 2021 at 4:10 PM Richard Sandiford via Gcc-patches < gcc-patches@gcc.gnu.org> wrote:
> Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use > > <V_elem> iterator instead of HI in mve_vmvnq_n_<supf><mode>. > > > > 2021-09-03 Christophe Lyon <christophe.l...@foss.st.com> > > > > gcc/ > > * config/arm/mve.md (mve_vmvnq_n_<supf><mode>): Use V_elem mode > > for operand 1. > > > > diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md > > index e393518ea88..14d17060290 100644 > > --- a/gcc/config/arm/mve.md > > +++ b/gcc/config/arm/mve.md > > @@ -617,7 +617,7 @@ (define_insn "mve_vcvtaq_<supf><mode>" > > (define_insn "mve_vmvnq_n_<supf><mode>" > > [ > > (set (match_operand:MVE_5 0 "s_register_operand" "=w") > > - (unspec:MVE_5 [(match_operand:HI 1 "immediate_operand" "i")] > > + (unspec:MVE_5 [(match_operand:<V_elem> 1 "immediate_operand" "i")] > > VMVNQ_N)) > > ] > > "TARGET_HAVE_MVE" > > I agree this is correct, but there's also the issue that the > predicate is too broad. At the moment it allows any immediate, > so things like: > > #include <arm_mve.h> > int32x4_t foo(void) { return vmvnq_n_s32(0x12345678); } > > are accepted by the compiler and only rejected by the assembler. > Not your bug to fix, just saying :-) > > Right, and it seems to be the case for vbicq_n, vorrq_n, ... I'll check that separately. > Thanks, > Richard >