## Phase 131-11-H: ループキャリアPHI型修正 - PHI生成時に初期値(entry block)の型のみ使用 - backedge の値を型推論に使わない(循環依存回避) - NYASH_CARRIER_PHI_DEBUG=1 でトレース ## Phase 131-12-P0: def_blocks 登録 & STRICT エラー化 - safe_vmap_write() で PHI 上書き保護 - resolver miss を STRICT でエラー化(フォールバック 0 禁止) - def_blocks 自動登録 ## Phase 131-12-P1: vmap_cur スナップショット実装 - DeferredTerminator 構造体(block, term_ops, vmap_snapshot) - Pass A で vmap_cur をスナップショット - Pass C でスナップショット復元(try-finally) - STRICT モード assert ## 結果 - ✅ MIR PHI型: Integer(正しい) - ✅ VM: Result: 3 - ✅ vmap snapshot 機構: 動作確認 - ⚠️ LLVM: Result: 0(別のバグ、次Phase で調査) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
Phase 131-12: Case C (LLVM wrong result) Investigation Notes
Status: Active
Scope: apps/tests/llvm_stage3_loop_only.hako が VM では正しいが LLVM では結果が一致しない問題の切り分け。
Related:
- SSOT (LLVM棚卸し):
docs/development/current/main/phase131-3-llvm-lowering-inventory.md - Case C (pattern):
docs/development/current/main/phase131-11-case-c-summary.md - PHI type cycle report (historical):
docs/development/current/main/phase-131-11-g-phi-type-bug-report.md - ENV:
docs/reference/environment-variables.md(NYASH_LLVM_DUMP_IR,NYASH_LLVM_TRACE_*)
事象
- VM:
Result: 3(期待通り) - LLVM:
Result: 0(不一致)
前提:
- MIR の PHI 型(loop-carrier)が循環で
Stringになる問題は Phase 131-11-H で修正済み。 - それでも LLVM で結果不一致が残るため、次は LLVM backend 側の value/phi/exit 値の取り回しを疑う。
切り分け(最優先)
1) 文字列連結経路の影響を切る
Case C は print("Result: " + counter) を含むため、以下の2系統を分けて確認する:
- Loop 値そのものが壊れているのか?
- String concat / print の coercion 経路が壊れているのか?
最小の派生ケース(新規fixtureにせず /tmp でOK):
return counter(出力なし、戻り値のみ)print(counter)(文字列連結なし)print("Result: " + counter)(元の形)
VM/LLVM で挙動を揃えて比較する。
2) LLVM IR を必ず保存して diff する
同一入力に対して:
NYASH_LLVM_DUMP_IR=/tmp/case_c.ll tools/build_llvm.sh apps/tests/llvm_stage3_loop_only.hako -o /tmp/case_c- 必要に応じて
NYASH_LLVM_TRACE_PHI=1 NYASH_LLVM_TRACE_VALUES=1 NYASH_LLVM_TRACE_OUT=/tmp/case_c.trace
確認点(IR):
- loop-carrier に対応する
phiが 正しい incoming を持っているか - ループ exit 後に参照される値が backedge の最終値になっているか(init 値のままになっていないか)
print/concat直前でcounterが0に固定されていないか(Constant folding ではなく wiring 問題)
期待される原因クラス
- Exit value wiring: JoinIR→MIR→LLVM のどこかで exit 後の “host slot” へ値が戻っていない
- PHI/value resolution: LLVM backend の
vmap/resolve_*が exit 後の ValueId を誤解決している - String concat coercion:
counterを string へ変換する経路で別の ValueId を参照している
受け入れ基準(この調査のDone)
return counterとprint(counter)が VM/LLVM で一致するまで、問題を局所化できていること。- その状態で、必要な修正点(どのファイル/どの関数)が特定できていること。