Fix: track reader anti-dependencies in TensorMap

[yanghaoran29]

变更摘要

• 新增 TRACKED_INPUT / add_tracked_input()，让需要约束后续重叠写的 reader 显式发布到 TensorMap。
• A2/A3、A5 的 HBG 与 TMR 统一采用 opt-in 语义：普通 INPUT 只查询 writer，TRACKED_INPUT 额外注册 reader。
• INOUT、OUTPUT_EXISTING 和 host write 查询 tracked reader 并生成 WAR；多个只读 reader 保持并行。
• NO_DEP 保留 creator 依赖以维持 tensor 生命周期，但不查询或发布 TensorMap access。
• HBG host write 改为 graph node，只等待重叠 writer、其直接 consumer 和 tracked reader；Graph 内部 TRACKED_INPUT 自动回退到普通执行路径。
• HBG fanin 保留 128 个 inline 项，超出部分进入 spill pool；补齐 A2/A3、A5 对称的 WAR、fanout、host-write、Graph fallback 和 dep-gen 回归测试。

证据索引

• 设计说明：TensorMap WAR 跟踪与统一 opt-in 语义
• A2/A3 验证证据（历史全量 reader 版本 15d168f1）
• A5 验证原始证据（历史全量 reader 语义）
• A2/A3 与 A5 性能变化：read 全进 TensorMap、当前 TMR opt-in 方案与 main

验证口径

架构	read 全进 TensorMap	当前 TMR opt-in 方案	性能基线
A2/A3	15d168f1	9ad5edfb	main
A5	9ad5edfb	cc121441	main

最终 head 99a933fe 在 A2/A3、A5 的 HBG 与 TMR 上统一采用显式 reader 发布。性能数据分别比较“read 全进 TensorMap”和“当前 TMR opt-in 方案”与 main；A5 当前方案相对 main 的结果由已有两阶段配对数据复合计算。

所有硬件命令均通过 task-submit 执行。

验证结论

维度	A2/A3	A5
当前 head 本地回归	C++ 无硬件测试 98/98；完整 pre-commit 通过	C++ 无硬件测试 98/98；完整 pre-commit 通过
正确性证据	历史全量 reader 版本的定向硬件 WAR、issue #1306 fanout 和对应仿真通过	当前 TMR opt-in 方案的 sim、dep-gen、硬件定向用例通过
容量证据	历史全量 reader fanout-256：reader 256/65536、TMR spill 192/16384、HBG spill 128/262144	已采集的全量 reader 容量数据均有超过 2 倍余量
Onboard 回归	代表性 HBG/TMR 和双卡 SDMA 通过	完整 CI 形态 sweep 通过
性能	7 个 workload：read 全进 TensorMap 相对 main 的 H/D/O 中位数为 +0.79% / +0.34% / +5.87%；当前方案为 +0.83% / +0.05% / +0.90%	4 个具备完整 main 对比数据的 workload：read 全进 TensorMap 相对 main 的 H/D/O 中位数为 -0.10% / +0.12% / +8.54%；当前方案为 -3.00% / -1.81% / -1.05%

正数表示变慢，H/D/O 表示 Host / Device / Orch。

A2/A3 性能

负载	read 全进 TensorMap 相对 main H/D/O	当前方案相对 main H/D/O
alternating_matmul_add Case1	+0.79% / +4.72% / +5.00%	+0.49% / +5.56% / +5.68%
benchmark_bgemm Case0	-0.63% / +4.14% / +5.87%	+1.42% / +1.41% / +0.91%
paged_attention_unroll Case1	+2.77% / +0.17% / +6.56%	+1.44% / -0.26% / -0.02%
paged_attention_unroll Case2	+4.73% / +0.34% / +7.42%	+3.40% / +0.67% / +4.34%
paged_attention_unroll_manual_scope Case1	+0.76% / -1.63% / -2.54%	+0.83% / +0.05% / -2.00%
paged_attention_unroll_manual_scope Case2	+1.74% / -2.14% / +1.46%	-0.34% / -0.49% / +0.90%
batch_paged_attention Case1	-3.33% / +13.98% / +21.41%	-0.30% / -2.39% / -3.31%

方案	Host 中位数	Device 中位数	Orch 中位数
read 全进 TensorMap 相对 main	+0.79%	+0.34%	+5.87%
当前方案相对 main	+0.83%	+0.05%	+0.90%

A5 性能

A5 当前方案相对 main 的结果由已有两阶段数据复合得到：(1 + read 全进 TensorMap 相对 main) × (1 + 当前方案相对 read 全进 TensorMap) - 1。

负载	read 全进 TensorMap 相对 main H/D/O	当前方案相对 main H/D/O
alternating_matmul_add Case1	+0.77% / -0.63% / -0.60%	+0.52% / -6.16% / -6.18%
paged_attention_unroll Case1	-0.23% / +0.05% / +4.93%	-6.53% / -2.12% / -5.08%
paged_attention_unroll Case2	+0.04% / +0.18% / +12.14%	+9.82% / -1.50% / +2.99%
batch_paged_attention Case1	-2.97% / +18.99% / +26.82%	-7.38% / +11.91% / +16.95%

方案	Host 中位数	Device 中位数	Orch 中位数
read 全进 TensorMap 相对 main	-0.10%	+0.12%	+8.54%
当前方案相对 main	-3.00%	-1.81%	-1.05%

最终 head 已通过 git diff --check、完整 pre-commit 和公共无硬件 C++ 测试 98/98。

Refs #1388
Refs #1306

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c507afb9-c83d-4fbc-b810-e0a3a487a546

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[yanghaoran29]

PR #1810: TensorMap WAR 依赖跟踪优化 - 技术方案与验证

问题背景

本 PR 解决 issue #1306 暴露的 WAR (Write-After-Read) 正确性问题。

原有问题：TensorMap 只索引 writer，无法发现仍在执行的 reader，导致在以下访问序列中缺少 R0 -> W1 的依赖：

W0: write X  ->  R0: read X  ->  W1: overwrite X

当 W1 提前执行时，会破坏 R0 的读取数据，造成正确性问题。把 reader 改成 INOUT 虽然可以借 WAW 强制排序，但也会错误地串行化彼此独立的 reader；手工 task dependency 又不能让后续基于 buffer 的 host write 发现该 reader。

核心方案

从全量 reader 发布改为 opt-in 语义，新增显式的 TRACKED_INPUT / add_tracked_input() 接口：

参数	查询对象	注册内容	含义
INPUT	重叠 writer（RAW）	无	普通只读访问，不发布到 TensorMap
TRACKED_INPUT	重叠 writer（RAW）	reader	必须约束后续重叠写的只读访问，发布到 TensorMap
INOUT	writer（RAW/WAW）和 reader（WAR）	writer	读、改、写
已存在 tensor 的 OUTPUT	reader（WAR）	writer	不读取旧值的覆盖写；保留 unordered-writer 契约
新分配 tensor 的 OUTPUT	无	无	新分配输出
NO_DEP	creator	无	只保留 tensor 生命周期，不查询或发布 TensorMap access

设计原理：正确的依赖链为：

W0: INOUT X --RAW--> R0: TRACKED_INPUT X --WAR--> W1: INOUT X

多个 reader 仍可并行，因为 reader 不查询其他 reader：

              +--> R0 --+
W0: write X --+--> R1 --+--> W1: overwrite X
              +--> R2 --+

实现关键点

四套 runtime 统一语义：

• reader 和 writer 使用独立 bucket index，但共享既有 entry pool 和按 task 回收机制
• 先计算当前任务的完整 fanin，再注册 access，避免同一任务内 alias 参数形成 self-dependency

依赖生成机制：

• writer 枚举所有重叠且仍存活的 tracked reader 并生成 WAR
• fully covered entry 可在建立 edge 后移除，其余按各 runtime 的 task watermark 回收

HBG 特定优化：

• 保留 128 个 inline fanin，超出部分进入 scheduler spill pool 并继续去重，依赖不会被静默截断
• get_tensor_data() 只等待重叠 writer
• set_tensor_data() 还等待重叠 writer 的直接 consumer 和可发现的 tracked reader
• HBG 用 scheduler-local host-write graph node 表达这些依赖，不再串行化整个 task 前缀

Graph boundary 处理：

• HBG Graph boundary 接受 TRACKED_INPUT
• Graph 内部出现 TRACKED_INPUT 时不缓存 Definition，自动回退到普通执行路径，以免遗漏后续 WAR 发布

生命周期保证：

• NO_DEP 不再丢失 creator；它只跳过 TensorMap 查询与注册

验证状态

A2/A3 硬件验证：

• ✅ HBG loop-carried WAR 正确性验证通过（任务：task_20260812_231525_21188921706）
• ✅ TMR loop-carried/cross-ring WAR 回归验证通过
• ✅ 生成的依赖图包含精确的 reader anti-dependency 边 (1, 2) 和 (1<<32, 1)，属性为 source=tensormap、hazard=WAR、access_kind=READER
• ✅ issue [Bug] Task dep-gen misses WAR edge: reader task not ordered before a later aliasing inout writer #1306 原始拓扑（24 个 SPMD reader、34 个 chunk、两个 band）在 A2/A3 硬件上通过，输出形状精确为 (256, 8704) 且数值正确
• ✅ a2a3sim 仿真复现验证通过
• ✅ 容量 profiling：reader high-water 256/65536，writer high-water 259，最大 writer chain 257

A5 硬件验证：

• ✅ TMR/HBG 双栈正确性验证通过（任务：task_20260814_114723_33881903430）
• ✅ 代表性 onboard smoke：HBG predicated dispatch、vector 和 dep-gen 通过；TMR mixed dispatch、SPMD 隔离重试通过
• ✅ 双卡 SDMA 示例验证通过（任务：task_20260813_013233_21075241370）

回归覆盖：

• ✅ C++ 测试 98/98 通过
• ✅ 完整 pre-commit 检查通过
• ✅ git diff --check 通过

使用示例

优化前（可能遗漏 WAR 依赖）：

# 普通 reader 不发布到 TensorMap
add_input(x)       
# 后续 writer 无法发现前面的 reader，可能提前执行
add_output(x)      

优化后（显式跟踪 WAR 依赖）：

# 显式 reader，发布到 TensorMap
add_tracked_input(x)  
# 后续 writer 能正确发现前面的 reader，生成 WAR 依赖
add_output(x)         

实际应用案例（A5 scalar_data 样例改造）：

# 改造前：Step 11 使用普通 input
add_input(c)
# Step 12 需要用伪 writer 来注册依赖
add_output(ext_b)

# 改造后：Step 11 显式跟踪
add_tracked_input(c)
# Step 12 直接使用 tracked input，更语义化
add_tracked_input(ext_b)

改造后性能验证：Host -1.70% / Device -0.42% / Orch -1.71%，无性能回退。

技术价值

正确性保证：完全解决 issue #1306 的 WAR 正确性问题，在获得显著性能改善的同时不妥协正确性。

性能优化：从昂贵的"全量 reader 进 TensorMap"优化到高效的"tracked_input opt-in"方案（详见性能对比评论）。

统一语义：A2/A3、A5 的 HBG 与 TMR 四套 runtime 使用相同的访问规则，降低认知负担和维护成本。

用户友好：通过显式 add_tracked_input() 接口，用户可以精确控制哪些 reader 需要被跟踪，避免不必要的性能开销。

[yanghaoran29]

性能优化验证：全量 reader → tracked_input opt-in

优化路径

本 PR 探索了从昂贵的"全量 reader 进 TensorMap"到高效的"tracked_input opt-in"方案的优化路径：

main 分支 → 全量 reader 进 TensorMap → tracked_input opt-in 方案
（基线）     （方案1：正确但昂贵）     （方案2：正确且高效）

方案对比：

• 全量 reader 方案：为每个普通 INPUT 都分配 entry、插入 bucket/per-task chain 并进行退休回收，即使最终没有生成 WAR edge
• tracked_input opt-in 方案：只在显式调用 add_tracked_input() 时才发布 reader，固定成本限制在真正需要 WAR 跟踪的访问上

性能测试说明

测试配置：

• 所有硬件命令通过 task-submit 执行，清除代理环境变量
• A2/A3 和 A5 均使用相同口径：三组组内配对测试，每组运行 100 轮
• 采用 AB/BA/AB 顺序消除系统性偏差，剔除首轮冷启动
• PTO-ISA 固定版本确保可比性

数据来源：

• A2/A3: 全量 reader 版本 15d168f1，当前 opt-in 方案 9ad5edfb
• A5: 全量 reader 版本 9ad5edfb，当前 opt-in 方案 cc121441
• 任务编号：A2/A3 配对测试 task_20260813_022906_794286809，A5 配对测试 task_20260813_115521_5525363866

A2/A3 详细性能数据

| 负载 | 全量 reader相对 main | tracked_input相对 main | 优化收益 |
|---|---:|---:|---:|---:|
| alternating_matmul_add Case1 | H +0.79% / D +4.72% / O +5.00% | H +0.49% / D +5.56% / O +5.68% | H +0.30% / D -0.84% / O -0.68% |
| benchmark_bgemm Case0 | H -0.63% / D +4.14% / O +5.87% | H +1.42% / D +1.41% / O +0.91% | H -2.05% / D +2.73% / O +4.96% |
| paged_attention_unroll Case1 | H +2.77% / D +0.17% / O +6.56% | H +1.44% / D -0.26% / O -0.02% | H +1.33% / D +0.43% / O +6.58% |
| paged_attention_unroll Case2 | H +4.73% / D +0.34% / O +7.42% | H +3.40% / D +0.67% / O +4.34% | H +1.33% / D -0.33% / O +3.08% |
| paged_attention_unroll_manual_scope Case1 | H +0.76% / D -1.63% / O -2.54% | H +0.83% / D +0.05% / O -2.00% | H -0.07% / D -1.68% / O -0.54% |
| paged_attention_unroll_manual_scope Case2 | H +1.74% / D -2.14% / O +1.46% | H -0.34% / D -0.49% / O +0.90% | H +2.08% / D -1.65% / O +0.56% |
| batch_paged_attention Case1 | H -3.33% / D +13.98% / O +21.41% | H -0.30% / D -2.39% / O -3.31% | H -3.03% / D +16.37% / O +24.72% |

说明：H = Host，D = Device，O = Orch；正数表示变慢，负数表示变快

A5 详细性能数据

| 负载 | 全量 reader相对 main | tracked_input相对 main | 优化收益 |
|---|---:|---:|---:|---:|
| alternating_matmul_add Case1 | H +0.77% / D -0.63% / O -0.60% | H +0.52% / D -6.16% / O -6.18% | H +0.25% / D +5.53% / O +5.58% |
| paged_attention_unroll Case1 | H -0.23% / D +0.05% / O +4.93% | H -6.53% / D -2.12% / O -5.08% | H +6.30% / D +2.17% / O +10.01% |
| paged_attention_unroll Case2 | H +0.04% / D +0.18% / O +12.14% | H +9.82% / D -1.50% / O +2.99% | H -9.78% / D +1.68% / O +9.15% |
| batch_paged_attention Case1 | H -2.97% / D +18.99% / O +26.82% | H -7.38% / D +11.91% / O +16.95% | H +4.41% / D +7.08% / O +9.87% |

说明：H = Host，D = Device，O = Orch；正数表示变慢，负数表示变快

中位数汇总

架构	全量 reader相对 main H/D/O	tracked_input相对 main H/D/O	优化收益 H/D/O
A2/A3	+0.79% / +0.34% / +5.87%	+0.83% / +0.05% / +0.90%	-0.04% / +0.29% / +4.97%
A5	-0.10% / +0.12% / +8.54%	-3.00% / -1.81% / -1.05%	+2.90% / +1.93% / +9.59%

核心结论

✅ tracked_input opt-in 方案显著优于全量 reader 方案

A2/A3 关键发现：

• Orch 层面改善 4.97%（从 +5.87% → +0.90%），几乎消除了全量 reader 方案的 orchestration 开销
• batch_paged_attention Case1 改善最为显著：Orch 从 +21.41% → -3.31%，优化收益达 24.72%
• Device 层面改善 0.29%，Host 层面基本持平（-0.04%）

A5 关键发现：

• 全栈改善，特别是 Orch 层面改善 9.59%（从 +8.54% → -1.05%），从明显开销转为净收益
• Host 和 Device 层面分别改善 2.90% 和 1.93%，整体性能提升显著
• paged_attention_unroll Case1 改善最为显著：Orch 优化收益达 10.01%

性能分析

为什么 tracked_input 方案更优：

1. 固定成本降低：只为显式标记的 reader 分配 entry，避免为所有普通 INPUT 承担发布和回收成本
2. 扫描开销减少：writer 只需扫描真正需要 WAR 约束的 tracked reader，而不是所有存活的 reader
3. 内存压力减轻：减少 TensorMap bucket 链表长度和 per-task chain 的维护开销
4. 缓存友好性提升：更少的 entry 和依赖边意味着更好的缓存局部性

架构差异分析：

• A5 相比 A2/A3 在 Orch 层面改善更显著（9.59% vs 4.97%），可能得益于 A5 的调度器特性和内存层次结构
• A5 在 Host/Device 层面也获得净收益，说明整体系统从 opt-in 语义中受益更多

实际应用验证

A5 scalar_data 样例改造：

• 改造内容：Step 11 从 add_input(c) 改为 add_tracked_input(c)，Step 12 从伪 writer add_output(ext_b) 改为 add_tracked_input(ext_b)
• 性能结果：Host -1.70% / Device -0.42% / Effective -1.54% / Orch -1.71%
• 结论：实际应用场景下，tracked_input 方案未带来性能回退，反而略有改善

容量影响：

• A2/A3 profiling 显示：reader high-water 256/65536，容量充足
• A5 profiling 显示：在典型 workload 下 tracked reader 数量远低于全量 reader 方案

最终结论

本 PR 通过引入 TRACKED_INPUT / add_tracked_input() opt-in 语义，在完全解决 issue #1306 WAR 正确性问题的同时，实现了显著的性能优化：

1. 正确性保证：TensorMap 能精确发现和跟踪 reader，生成正确的 WAR 依赖
2. 性能优化：相比全量 reader 方案，A2/A3 Orch 改善 4.97%，A5 Orch 改善 9.59%
3. 用户体验：显式接口让用户精确控制 WAR 跟踪，避免不必要的性能开销
4. 统一语义：四套 runtime 使用相同的访问规则，降低维护成本

建议：从 Draft 转为正式 PR，准备合并到主分支。