On 7/28/25 2:40 AM, Anton Blanchard wrote:
The crypto type covers scalar (not vector) crypto instructions, and vclz
and vctz appear in two places.
gcc/ChangeLog:
* config/riscv/generic-vector-ooo.md (vec_crypto): Remove crypto,
vclz, vctz from insn reservation, rename to vec_pop.
So in the patchwork meeting last week Robin expressed a desire to make
this more generic. Rather than basing the decision on vcpop type, base
the decision on a more generic concept like "vector bitmanip N cycles".
That could work, but it would mean we have to adjust this pattern:
;; vclz.v vctz.v vcpop.v
(define_insn "@pred_v<bitmanip_optab><mode>"
[(set (match_operand:V_VLSI 0 "register_operand" "=vd, vr")
(clz_ctz_pcnt:V_VLSI
(parallel
[(match_operand:V_VLSI 2 "register_operand" " vr, vr")
(unspec:<VM>
[(match_operand:<VM> 1 "vector_mask_operand" " vm,Wc1")
(match_operand 3 "vector_length_operand" " rK, rK")
(match_operand 4 "const_int_operand" " i, i")
(reg:SI VL_REGNUM)
(reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)])))]
"TARGET_ZVBB"
"v<bitmanip_insn>.v\t%0,%2%p1"
[(set_attr "type" "v<bitmanip_insn>")
(set_attr "mode" "<MODE>")])
I guess we could create <bitmanip_insn_type> and have it map cpop to
something more generic. We'd probably want to do the same thing for the
scalar bitmanip insns as well and adjust all the scheduler models that
use the old <bitmanip_insn> mapping.
Other thoughts?
jeff
