On Wed, 26 Oct 2022, Kumar, Venkataramanan wrote: > > Looking at znver1.md again, I think the problem is caused by incorrect > > modeling of division instructions: they have descriptions like > > > > (define_insn_reservation "znver1_idiv_DI" 41 > > (and (eq_attr "cpu" "znver1,znver2") > > (and (eq_attr "type" "idiv") > > (and (eq_attr "mode" "DI") > > (eq_attr "memory" "none")))) > > "znver1-double,znver1-ieu2*41") > > > > which says that DImode idiv has latency 41 (which is correct) and that it > > occupies 2nd integer execution unit for 41 consecutive cycles, but that is > > not correct: > > Yes you are correct. It does not block the 2nd integer execution pipe > consecutively for 41 cycles. > > > > > 1) the division instruction is partially pipelined, and has throughput 1/14 > > "Div" unit takes one instruction and in the worst case the latency will be 41 > cycles in znver1/2. > But I agree that we can put best case latency of 14 cycles for the scheduler > model in znver1/2 .
It is not latency. It is reciprocal throughput. For example, the multiplication instruction has latency 3 and reciprocal throughput 1, and the corresponding execution unit can accept a new multiplication instruction each cycle. In the .md file we are modeling that by saying that multiplication occupies some unit for one cycle (but has latency 3). Alexander
