Hi Jeff, On Thu, Sep 17, 2020 at 05:12:17PM -0600, Jeff Law wrote: > 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.
Power9 doesn't have a reorder buffer or anything similar at all -- it uses history buffers, so committing insns (pretty much what you call retiring) is essentially for free (restoring old register values after flushes now costs more though). Segher
