Instruction-Level Parallelism

Register Renaming

A hardware mechanism that silently maps each architectural register name (R1, R2, …) to a distinct physical register, so reuses of the same name aren’t treated as real dependencies.

Why?

There are only ~16 architectural registers, so code constantly reuses names for unrelated data. Without renaming, the CPU would see a “dependency” every time R2 is reused and serialize the work, even though the second R2 has nothing to do with the first. That would make OoO useless, since false dependencies would force everything back into program order.

MOV R2, R7 + 32        ;   RX ← R7+32
ADD R1, R2             ;   R1 += RX
MOV R2, R9 + 64        ;   RY ← R9+64     ← R2 renamed to RY
ADD R3, R2             ;   R3 += RY

Instructions 3–4 look dependent on 1–2 because they all touch R2, but that’s a false dependency: name reuse, not data flow. With renaming, the two pairs run in parallel (or at least without a stall).

Synergy with speculation. When the CPU predicts a branch, it writes speculative results to a fresh set of physical registers while preserving the originals. When the branch resolves:

• Prediction correct → commit the new set, discard the old
• Prediction wrong → discard the new set, restore the old

This makes misprediction recovery cheap. (Zarnett’s analogy: like writing down both answers to a question and letting the TA pick the right one at the end.)

Why it’s load-bearing. Renaming is what lets the CPU “get past a cache miss and keep going”; L06 identifies this as the real point of the whole synergistic group (renaming + speculation + miss shadow + OoO).

From ECE459 L06.