https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #11 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to Christophe Lyon from comment #10) > This was introduced by my change at r12-671 in mve.md: > -;; [vcmpneq_]) > +;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_, > vcmpltq_]) > ;; > -(define_insn "mve_vcmpneq_<mode>" > +(define_insn "mve_vcmp<mve_cmp_op>q_<mode>" > [ > (set (match_operand:HI 0 "vpr_register_operand" "=Up") > - (unspec:HI [(match_operand:MVE_2 1 "s_register_operand" "w") > - (match_operand:MVE_2 2 "s_register_operand" "w")] > - VCMPNEQ)) > + (MVE_COMPARISONS:HI (match_operand:MVE_2 1 "s_register_operand" "w") > + (match_operand:MVE_2 2 "s_register_operand" "w"))) > + ] > + "TARGET_HAVE_MVE" > + "vcmp.<mve_cmp_type>%#<V_sz_elem> <mve_cmp_op>, %q1, %q2" > + [(set_attr "type" "mve_move") > +]) > > So should that use MVE_COMPARISONS:MVE_2, and somehow include a conversion > from MVE_2 modes into HI for vpr.p0 in the pattern? Thinking about it some more, it might be the use of HI on the 'eq' that is incorrect. If the result were a vector, then the construct might have more meaning. I think you'll need to look at how predicates are handled in the aarch64 SVE code. For example, you might need to introduce the concept of VECTOR_BOOL_MODEs.
