Hi Robin, > > -;; Vector crypto, assumed to be a generic operation for now. > > -(define_insn_reservation "vec_crypto" 4 > > +;; Vector population count > > +(define_insn_reservation "vec_pop" 4 > > (and (eq_attr "tune" "generic_ooo,generic") > > - (eq_attr "type" "crypto,vclz,vctz,vcpop")) > > + (eq_attr "type" "vcpop")) > > "vxu_ooo_issue,vxu_ooo_alu") > > Hmm, generally I'd say it's reasonable to remove "crypto" but I wonder whether > vcpop is special enough to have its own reservation? IMHO vclz, vctz, vbrev, > etc. are all kind of similar in that they are not regular arithmetic operations > but rather bitmanip ones (as opposed to vandn, vwsll or so). I guess they > could all execute on an ALU pipe but I wouldn't be surprised if implementations > differed here. > > Not that I have a very strong opinion but right now I'd slightly lean towards > removing vclz and friends from vec_alu and add them here instead. Let's see > what others think still.
On tt-ascalon-d8 vctz and vclz are 1 cycle and vcpop is 2 cycles, so I somewhat selfishly split it out as above. We'll add a pipeline description for it soon, so I don't have a strong opinion either. Thanks, Anton
