Paul A. Clayton (paaronclayton.delete@this.gmail.com) on October 16, 2020 6:20 am wrote:
> anon
> (anon.delete@this.ymous.org) on October 15, 2020 11:56 am wrote:
> [snip]
>
> > Thank you for this detailed analysis. I haven't read the paper
> thoroughly yet, but I wanted
> > to discuss one of your comments about reordering uops and rename
> optimizations.
> >
> > Regarding reordering, the problem here is that is that you cannot
> generally rename out-of-order because
> > although this might not have any impact at first glance (What's the
> difference between "add rax, rcx;
> > ld rbx, [rdx], add r12, rax" and "ld rbx, [rdx], add rax, rcx; add
> r12, rax"?), I think it it gets messy
> > if you want precise exceptions/interruptions. So, you probably can
> rename out-of-order but you need
> > to map those out-of-order mappings back to a ROB-like structure
> that is allocated earlier than rename
> > in the pipeline and it might be weird. However, that is an
> interesting thought because I know of some
> > designs where the RAT is port-limited and so rename groups with at
> most x reads/writes have to be formed,
> > which may not match what is coming out of Decode (compiler could
> help though).
>
> Since exceptions are exceptional, one could do replay from the Icache (assuming data-inclusive Icache,
> which seems typical). This is vaguely similar to one of the POWER implementations (POWER5?) using
> replay with single-operation bundles on exceptions so that ROB overhead could be reduced. If the
> Icache was not data inclusive of the µop cache (as opposed to just tag inclusive to support snooping),
> the untangling of µop order would require extra information and be a bit complex.
>
> > On the rename optimization thing ("rewriting"). I am not
> > sure I followed the idea. Could you please elaborate?
>
> With respect to renaming, if a source operand is the destination of a previous µop, one can replace
> that register name with the number of the µop that provides the value (assuming single-result
> µops). When renaming, those sources would not read the RAT but the free list to get their new
> name. This is just caching the dependence information; detecting dependencies before RAT access
> would increase latency (yet allow reading from the free list and not the RAT), detecting them in
> parallel with RAT access would increase RAT port demand — caching the information provides the
> benefit of the former without the latency cost (and could save some energy as well).
>
> (One could also imagine other optimizations, some of which would depend on the design of
> the scheduler. For example, a scheduler might use indexed wake-up rather than broadcast
> comparison when one operation is known to provide the last-to-be-available source of another
> operation; if replay is cheap, predicted as last-to-be-available might suffice.)

Thank you, I think I got it. I will point out that it could be possible to implement this directly at the I-Cache by rewriting a custom format on a line fill if the instruction format permits it. If not, then doing it in the uop cache does seem like the place, even though in practice it becomes hard to tell if it will impact cycle time or not. Essentially, another level of choice is added at Rename : Who uses the free list and who uses the RAT (for sources). It might not be a big deal but it means that each "lane" from Decode has to enable a different circuit whereas in the baseline each "lane" would go straight to the RAT period (for sources).

Indexed wake up on the scheduler has been argued to be much more power efficient (e.g. TRIPS), but in this case, it would be added on top of the baseline broadcast wake up and to so it sounds like a hard sell to the circuit designer, especially for something that would only work if the source and the last destination are in the same dispatch bundle. Maybe an indexed write port used for dispatch could be stolen...