香山昆明湖后端流水线的寄存器重命名优化：ROB 压缩、RAT Move 消除与发射后读寄存器堆
昆明湖这个版本对后端的改动，很多都收敛在“重命名”这一条线上。粗看是三个独立优化：ROB 压缩、基于 RAT 的 Move 消除、发射后读寄存器堆。实际上它们共享同一个判断：乱序窗口要变大，先想清楚哪些工作不必压在 ROB、发射队列和寄存器堆读口上。
ROB 压缩：用 RAB 把两件事拆开
ROB 在传统乱序核里承担两件事：顺序退休指令、维护物理寄存器的回收顺序。两件事捆在一起时，ROB 深度就是寄存器生命周期的锚点。昆明湖把后者拆出来，交给 RAB（RenAme Buffer，256 项）。RAB 跟踪物理寄存器的分配与释放，ROB 只做顺序退休，容量可以压到 160 项。注意一个细节：RAB 比 ROB 还大，说明寄存器提交的跟踪才是真正的主线。
配套手段还有重命名快照。分支预测错误后的重定向代价从“回放重命名过程”变成“恢复一组快照”，配合 RAB 快速定位重命名恢复点，精确异常因此不用逐条回放。整个重命名流水是 6 宽度的，物理寄存器 224 INT + 192 FP + 128 VEC。没有这组物理寄存器兜底，ROB 压缩就只是把瓶颈换了个位置。
基于 RAT 的 Move 消除
move 指令天然适合在重命名阶段消化。一条 mv rd, rs 只是把 rs 的值“看成”rd 的值，如果 RAT 里能够把 rd 直接映射到 rs 当前的物理寄存器，这条指令就不需要分配新物理寄存器、不需要进发射队列，后续读 rd 的指令直接从同一个物理寄存器取数，数据搬运以旁路操作数的方式完成。
省下来的不是一条指令的发射带宽，而是分配项的消耗、发射队列的操作数存储、以及提交阶段对无关物理寄存器的回收开销。整数代码里 move 出现的频率明显更高，所以这个优化对 INT 侧的 RAB 压力改善最直接。并不是所有 move 都值得处理：当源映射关联的物理寄存器生命周期已经偏长，消除反而会把该寄存器的占用期延续得更久，这属于要取舍的场景。
发射后读寄存器堆
发射后读寄存器堆（register file read after issue）是相对南湖的重要改动。常规设计在发射周期读好寄存器堆，数据暂存在发射队列中，调度关键路径等于“就绪检查 + 仲裁 + 读寄存器堆”。改动之后，发射队列只维护就绪状态，发射动作确认后再去读物理寄存器堆，读延时从调度关键路径上挪走。
这笔交易是把寄存器堆的读口压力集中到发射后的极短窗口，同时要求执行端与旁路网络接受更晚的数据到达。昆明湖的 LSU 时序为此做了重排：每周期最多发射 3 条整数 Load、2 条 Store、2 条向量访存微指令，DCache 非阻塞，访存阶段不再苛求指令发射时操作数已经躺进发射队列。
收益与边界
这三项优化叠加后的效果是：乱序窗口的瓶颈从 ROB 的结构容量变成物理寄存器的真实资源。发射队列不必再存操作数，调度器关键路径变短；move 指令不再占用窗口条目，ROB 压到 160 项也够用；每周期 8 条退休配 RAB 的提交管理，精确异常能力没有缩水。昆明湖整体性能目标是 SPEC CPU2006 约 45 分 @3GHz——这个数字不能归因到某一处改动，但说明后端这条线没有拖后腿。
类似的取舍在整个核里还能看到：ICache 把 Meta Array 和 Data Array 的读取解耦，先读 MetaArray、命中后再读 DataArray，功耗下降 69%。原则一致，尽量别在数据还没确定时做冗余工作。
边界也很清楚：Move 消除依赖 RAT 命中率，向量指令流里能被 RAT 直接消掉的纯 move 比整数侧少得多，这块收益有限；RAB 和快照机制在分支密集场景下恢复路径复杂，这部分成本需要由前端预测质量来对冲。发射后读寄存器堆适合 LSU 时序被重新整理过的设计，如果负载依赖链极短，晚读寄存器堆的等待可能抵消调度器省下的延时。
开放问题
RAB 的分配与回收策略如何与重命名快照精确对齐，发射后读寄存器堆具体如何与 load-use 转发路径衔接，这两处细节原文未展开。实现都在 src/main/scala/xiangshan 的对应模块里，仓库支持 make emu 构建 Verilator 仿真器，配合 difftest 可以继续盯着这两条路径调。昆明湖没有把这三个优化做成孤立的“卖点”，而是让重命名和寄存器分配阶段多花一点逻辑，换回发射队列、ROB 和寄存器堆读口上的大块成本——这是后端取舍上可移植性最强的地方。