On 9/3/20 4:37 PM, Segher Boessenkool wrote: >> Apart from that, one P9 specific point is that the update form load isn't >> preferred, the reason is that the instruction can not retire until both >> parts complete, it can hold up subsequent instructions from retiring. >> If the addi stalls (starvation), the instruction can not retire and can >> cause things stuck. It seems also something we can model here? > This is (almost) no problem on p9, since we no longer have issue groups. > It can hold up older insns from retiring, sure, but they *will* have > finished, and p9 can retire 64 insns per cycle. The "completion wall" > is gone. The only problem is if things stick around so long that > resources run out... but you're talking 100s of insns there.
So the PA8xxx had the same issue with its dual output insns -- the big difference is the PA8xxx systems were considered retirement bandwidth limited (2 memory and 2 non-memory per cycle, with just a 56 entry reorder buffer, split between memory and non-memory ops). Holding a slot in the reorder buffer was relatively costly. If you can retire 64 ops per cycle and you've probably got an enormous reorder buffer, so I wouldn't worry much about holding up insns from retiring on your target. jeff
pEpkey.asc
Description: application/pgp-keys
