CinderX JIT Review

定位

对 CinderX JIT PR 做 correctness-first code review。优先找会改变 Python 语义、JIT 层级契约、exception edge、deopt/refcount、specialized opcode 消费、helper fallback 或验证边界的风险。

这个 skill 不是性能调优流程。性能收益只能作为背景；review 结论先回答“这次 JIT 改动如何证明没有改坏语义”。

按风险读取

先看 diff 和相关调用链，再读取适用材料：

• references/jit-correctness-validation-strategy.md：分层正确性策略、may-raise / exception table、RuntimeTests 硬要求。
• references/review-checklists.md：按风险类型检查 helper、deopt、refcount、adaptive opcode、side effect、AArch64 codegen 和覆盖证据。

局部问题只读取对应小节；不涉及 JIT 行为的文档或工具改动不要求通读两份材料。

开放性原则

把本 skill 当作 review 下限，不当作风险全集。先从具体 diff、调用链、执行时机、异常边、ownership、平台约束和测试证据出发，再用 references 补充已知高风险模式。

• 如果 diff 暴露了 references 没列出的新风险，也要按 correctness-first review 输出 finding。
• 不要因为某个问题不属于 may-raise、deopt、refcount、adaptive opcode 或 AArch64 checklist，就跳过它。
• 当新风险反复出现时，在 review 结束后建议把它沉淀回 references/review-checklists.md，但不要等文档更新后才指出问题。
• 明确区分“本 skill 没覆盖”和“这个 PR 没风险”；前者不能推出后者。

Review 顺序

1. 明确 review 对象。

   • 确认 repo、base/head、PR/MR 编号、diff 范围和目标分支。
   • 如果是 GitCode PR，优先 review refs/merge-requests/<id>/head 和 refs/merge-requests/<id>/merge，不要只看分支 tip。

2. 判定改动层级。

   • Bytecode builder / preload。
   • HIR lowering、optimization pass、guard、verifier。
   • LIR、regalloc、uop。
   • Codegen、AArch64 backend、runtime helper。
   • Deopt、FrameState、frame layout、live refs。
   • RuntimeTests、test_cinderx、test_kunpeng、gate/tooling。

3. 写出本次 correctness contract。

   • 这次优化依赖的 Python 语义前提是什么？
   • 哪些前提由 guard、verifier、helper contract 或 codegen invariant 保护？
   • 前提失效时如何 fallback、deopt 或回到解释器语义？
   • 哪些机器检查证明 fast path 命中、fallback 正确、JIT on/off 等价？

4. 对照适用风险检查证据缺口，不要求重读整个 diff。

   • may-raise 点是否被新增、删除、移动、合并或替换？
   • 是否消费 CPython adaptive / specialized opcode 或 inline cache？
   • 是否改变 helper call、side-effect 顺序、container mutation、attribute access、descriptor 行为？
   • 是否改变 borrowed / owned ref、refcount insertion 输入、deopt live refs？
   • 是否改变 AArch64 寄存器、NZCV flags、W/X 宽度、SP alignment、branch/code patching、deopt mapping？

5. 审查验证面。

   • JIT 行为改动通常必须有 RuntimeTests 机器检查；test_cinderx、pyperformance、microbenchmark 不能替代局部 lowering/pass/codegen 契约。
   • test_cinderx 证明系统级 Python 行为，不能单独证明 HIR/LIR/codegen fast path 命中。
   • test_kunpeng 用于 ARM64/openEuler 相关路径时，检查是否覆盖目标 specialized opcode、helper、AArch64 或 platform-sensitive 行为。
   • 纯文档、注释或不改变 JIT 行为的测试工具改动使用相应检查，不因此要求新增 RuntimeTests；重构按实际行为风险验证。

6. 输出 review findings。

   • Findings 必须排在最前面，按严重度排序。
   • 每条 finding 必须包含 severity、文件/行号、风险、缺失证据或建议修复。
   • 用户问“在哪评论”时，先给 exact file/line placement 和 P1/P2，再给解释。
   • 没有 finding 时直接说明，并只列与结论相关的实际验证限制。

Severity 口径

• P1：可能导致错误语义、异常传播错误、crash、silent wrong result、deopt/refcount 破坏，或 PR 缺少证明核心 fast path 正确性的 RuntimeTests。
• P2：覆盖不足、contract 描述不清、负例缺失、平台 gate 表达不完整，或存在高风险但当前 diff 里尚未证明会出错。
• P3：文档、命名、维护性、review 可读性问题，不应遮住 correctness findings。

不要把“测试缺失”自动降级。若缺失测试正是证明核心 JIT 语义所必需的证据，应按 correctness 风险定级。

输出模板

Findings
- [P1] <file>:<line> <title>
  <why this can break Python/JIT semantics>
  Required evidence or fix:
  <specific RuntimeTests/test_cinderx/test_kunpeng or code change>
  Suggested comment:
  <ready-to-paste review comment>

Open Questions / Assumptions
- <only if needed>

Validation Notes
- Reviewed diff: <base..head or PR/MR refs>
- Local checks run: <commands or not run>
- Remaining risk: <short>

Keep the final answer concise, but keep enough technical detail for the user to paste the review comment without another round trip.