Hi Joe, Joe Ramsay <joe.ram...@arm.com> writes: > Hi! > > MD patterns extended for unary ops ABS, CLS, CLZ, CNT, NEG and NOT > to support unpacked vectors. Also extended patterns for BIC to > support unpacked vectors where input elements are of the same width.
Thanks for the patch. Looks good, but... > @@ -2848,12 +2848,12 @@ > > ;; Predicated integer unary arithmetic with merging. > (define_expand "@cond_<optab><mode>" > - [(set (match_operand:SVE_FULL_I 0 "register_operand") > - (unspec:SVE_FULL_I > + [(set (match_operand:SVE_I 0 "register_operand") > + (unspec:SVE_I > [(match_operand:<VPRED> 1 "register_operand") > - (SVE_INT_UNARY:SVE_FULL_I > - (match_operand:SVE_FULL_I 2 "register_operand")) > - (match_operand:SVE_FULL_I 3 "aarch64_simd_reg_or_zero")] > + (SVE_INT_UNARY:SVE_I > + (match_operand:SVE_I 2 "register_operand")) > + (match_operand:SVE_I 3 "aarch64_simd_reg_or_zero")] > UNSPEC_SEL))] > "TARGET_SVE" > ) ...it shouldn't be necessary to change the @cond_<optab><mode> expander to get this to work. If we did change it, we'd also need to change the associated define_insns (*cond_<optab><mode>_2 and *cond_<optab><mode>_any), otherwise the expanders would generate unrecognisable instructions. So I think we should drop this part of the patch and leave it as future work. The other SVE_INT_UNARYs are clrsb, clz, popcount, ss_abs and ss_neg. I agree that we can't easily test those, but that the change should in principle be correct for them too. (In particular, all of them need the element type (Vetype) rather than the container type (Vctype), which is one of the main questions when extending these patterns.) Thanks, Richard
