There was a typo in the pipeline description where DUP was assigned to the vector pipes for quad mode ops when it really only uses the VTOG pipes. Fixing this does not show any noticeable difference in performance (there's a very small bump of 1.7% in x264 but that's about it) in my tests but is the more precise description of operations for falkor.
Bootstrapped and tested with --with-cpu=falkor to confirm that there are no regressions. Siddhesh Changes from v1: - Fixed up ChangeLog entry - Replaced falkor_gtov,falkor_gtov with falkor_gtov*2 * config/aarch64/falkor.md (falkor_am_1_vxvy_vxvy): Move neon_dup_q to... (falkor_am_1_gtov_gtov): ... a new insn reservation. CC: james.greenha...@arm.com CC: kyrylo.tkac...@foss.arm.com --- gcc/config/aarch64/falkor.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/gcc/config/aarch64/falkor.md b/gcc/config/aarch64/falkor.md index 5cbc5150ef3..45cbff93b24 100644 --- a/gcc/config/aarch64/falkor.md +++ b/gcc/config/aarch64/falkor.md @@ -322,6 +322,12 @@ (eq_attr "type" "neon_from_gp_q")) "falkor_gtov,falkor_gtov") +;; DUP does not use vector pipes in Q mode, only gtov+gtov. +(define_insn_reservation "falkor_am_1_gtov_gtov" 1 + (and (eq_attr "tune" "falkor") + (eq_attr "type" "neon_dup_q")) + "falkor_gtov*2") + ;; neon_to_gp_q is used for 32-bit ARM instructions that move 64-bits of data ;; so no use needed here. @@ -337,7 +343,7 @@ (define_insn_reservation "falkor_am_1_vxvy_vxvy" 1 (and (eq_attr "tune" "falkor") - (eq_attr "type" "neon_bsl_q,neon_dup_q,neon_ext_q,neon_move_q,neon_rev_q,neon_tbl1_q,neon_permute_q")) + (eq_attr "type" "neon_bsl_q,neon_ext_q,neon_move_q,neon_rev_q,neon_tbl1_q,neon_permute_q")) "falkor_vxvy+falkor_vxvy") (define_insn_reservation "falkor_am_2_vxvy" 2 -- 2.17.1