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.)