本文基于我提交的公开 TIRx-harness PR #12 整理。该修复已于 2026 年 9 月 30 日合并。这里复盘的是资源报告的解析错误，验证记录来自当时的 PR，没有为写文章重新执行 GPU 测试。
数字都能找到，组合却不属于任何 kernel
ptxas 会在编译日志中报告寄存器、静态共享内存以及 spill 等资源。一个 cubin 包含多个 kernel 时，一份日志也会连续出现多份报告。原来的 parse_ptxas 在全文中分别搜索各个字段：寄存器取到第一份，某个可选字段缺失时，却可能继续命中下一份。
下面是便于阅读的字段示意，保留了 PR 中复现案例的关键关系，不是完整原始日志：
报告 A / plain
registers = 10
未报告静态 smem
报告 B / shared
registers = 12
smem = 128 bytes如果逐字段全局搜索，结果会变成 registers=10, smem=128。两项数字各有出处，拼在一起却对应不上任何一个 kernel。这种错误很隐蔽：类型检查能通过，数字也看起来合理，后续比较资源占用时才会带偏判断。
先决定读哪份，再决定取哪些字段
这个 API 原本就约定返回第一份 kernel 报告。因此修复没有改变返回对象的含义，而是在提取数字之前先确定文本范围。
- 优先用编译入口标记确定报告边界，截取第一份到第二份开始之间的内容。
- 没有编译入口标记时，回退到函数属性报告的边界。
- 简写的单份日志继续兼容；当前报告没出现的可选字段继续缺失。
缺失也有含义。 没有静态共享内存字段，不能借用别的 kernel 的值，也不能直接推断总共享内存为零；动态共享内存还需要其他信息。具体改动与回归用例见 PR diff。
验证要打到边界上
回归用例拼接两份报告，检查解析结果是否仍等于单独解析第一份，再交换顺序；另一个用例覆盖缺少编译入口标记的日志。这比只给一份字段齐全的报告更容易暴露问题。
PR 还记录了 CUDA 13.0.88、B300 环境中的真实编译复现，对两种声明顺序核对第一份报告。其针对性测试在修复前能发现错误，修复后通过；完整 NumSim / GPU 套件并未运行。
这次修改没有改变生成的 kernel，也没有证明任何加速效果。它解决的是更基础的问题：让一个资源数字始终属于产生它的那份报告。 对编译日志、性能追踪或多任务评测，明确记录边界应先于聚合指标。