[PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

Segher Boessenkool segher@kernel.crashing.org
Thu Sep 17 23:46:47 GMT 2020


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


More information about the Gcc-patches mailing list