Files
hakorune/docs/development/current/main/investigations/phase131-12-case-c-llvm-wrong-result.md
nyash-codex 7dfd6ff1d9 feat(llvm): Phase 131-11-H/12 - ループキャリアPHI型修正 & vmap snapshot SSOT
## 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>
2025-12-14 21:28:41 +09:00

2.8 KiB
Raw Blame History

Phase 131-12: Case C (LLVM wrong result) Investigation Notes

Status: Active
Scope: apps/tests/llvm_stage3_loop_only.hakoVM では正しいが 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.mdNYASH_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:

  1. return counter(出力なし、戻り値のみ)
  2. print(counter)(文字列連結なし)
  3. 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 直前で counter0 に固定されていないか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 counterprint(counter) が VM/LLVM で一致するまで、問題を局所化できていること。
  • その状態で、必要な修正点(どのファイル/どの関数)が特定できていること。