Ira Rosen ira.rosen@linaro.org wrote:
After testing only with the vectorizer testsuite (which contains at least 30 tests for strided accesses), I'd appreciate comments on the patch before I start full testing (cross testing with qemu doesn't work so well for NEON).
I cannot really comment on the ARM semantics, but just from the point of view of how the .md file looks:
- You define new patterns neon_vzip<mode>_interleave etc. instead of using the existing neon_vzip<mode>_internal etc., presumably because the existing patterns are broken. But because they are actually broken, they should rather be fixed themselves (and *then* used instead of duplicated).
- You define a bunch of new UNSPEC_ codes which will actually never show up in RTL, because the expanders that appear to use them always end in a DONE statement:
+(define_expand "vec_extract_even<mode>" + [(set (match_operand:VDQW 0 "register_operand" "") + (unspec:VDQW [(match_operand:VDQW 1 "register_operand" "") + (match_operand:VDQW 2 "register_operand" "")] + UNSPEC_EXTEVEN))] + "TARGET_NEON" +{ + rtx tmp = gen_reg_rtx (<MODE>mode); + + if (BYTES_BIG_ENDIAN) + emit_insn (gen_neon_vuzp<mode>_extract (tmp, operands[1], operands[2], + operands[0])); + else + emit_insn (gen_neon_vuzp<mode>_extract (operands[0], operands[1], + operands[2], tmp)); + DONE; +})
It doesn't seem to make much sense to define UNSPECs here; such expanders can instead simply use naked match_operands like so:
(define_expand "vec_extract_even<mode>" [(match_operand:VDQW 0 "register_operand" "") (match_operand:VDQW 1 "register_operand" "") (match_operand:VDQW 2 "register_operand" "")]
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294