On today's RISC-V GCC patch review call, someone mentioned there might be an alternative that uses a hook instead. Jeff mentioned this type of check may be needed in other pipeline descriptions either now or in the future, so I thought I'd post what I have so we can discuss which form is preferred. Thought's on this solution versus the hook solution???
The hook is riscv_sched_adjust_cost and right now it doesn't do a whole lot other than scale LMUL latency. Even though this is conceptually related to what you're doing with the div latency adjustment I still think these kinds of small-scale adjustments are better done directly in the scheduler description itself.
So IMHO we shouldn't complicate it and the patch is OK. The change is reasonable and reflects what the hardware does (one could argue it's even better than the mode) - latency depends on the element size.
diff --git a/gcc/config/riscv/tt-ascalon-d8.md b/gcc/config/riscv/tt-ascalon-d8.md index a57c0b31a81..25b99b6129e 100644 --- a/gcc/config/riscv/tt-ascalon-d8.md +++ b/gcc/config/riscv/tt-ascalon-d8.md @@ -285,38 +285,38 @@ (define_insn_reservation "tt_ascalon_d8_vec_ordered_reduction" 10 (define_insn_reservation "tt_ascalon_d8_vec_idiv_half" 16 (and (eq_attr "tune" "tt_ascalon_d8") (eq_attr "type" "vidiv") - (eq_attr "mode" "HF")) + (eq_attr "sew" "16")) "tt_ascalon_d8_decode,(tt_ascalon_d8_vec0*3 | tt_ascalon_d8_vec1*3)")(define_insn_reservation "tt_ascalon_d8_vec_idiv_single" 13(and (eq_attr "tune" "tt_ascalon_d8") (eq_attr "type" "vidiv") - (eq_attr "mode" "SF")) + (eq_attr "sew" "32")) "tt_ascalon_d8_decode,(tt_ascalon_d8_vec0*3 | tt_ascalon_d8_vec1*3)")
I suppose SF and HF were typos in the first place, seeing they refer to integer division?
-- Regards Robin
