Files
hakorune/docs/development/current/main/phases/phase-277/P0-DESIGN.md

75 lines
2.7 KiB
Markdown
Raw Normal View History

feat(llvm/phi): Phase 277 P1 - fail-fast validation for PHI strict mode ## Summary Implemented fail-fast validation for PHI ordering and value resolution in strict mode. ## Changes ### P1-1: Strict mode for "PHI after terminator" - File: `src/llvm_py/phi_wiring/wiring.py::ensure_phi` - Behavior: `NYASH_LLVM_PHI_STRICT=1` → RuntimeError if PHI created after terminator - Default: Warning only (no regression) ### P1-2: Strict mode for "fallback 0" - File: `src/llvm_py/phi_wiring/wiring.py::wire_incomings` - Behavior: Strict mode forbids silent fallback to 0 (2 locations) - Location 1: Unresolvable incoming value - Location 2: Type coercion failure - Error messages point to next debug file: `llvm_builder.py::_value_at_end_i64` ### P1-3: Connect verify_phi_ordering() to execution path - File: `src/llvm_py/builders/function_lower.py` - Behavior: Verify PHI ordering after all instructions emitted - Debug mode: Shows "✅ All N blocks have correct PHI ordering" - Strict mode: Raises RuntimeError with block list if violations found ## Testing ✅ Test 1: strict=OFF - passes without errors ✅ Test 2: strict=ON - passes without errors (no violations in test fixtures) ✅ Test 3: debug mode - verify_phi_ordering() connected and running ## Scope - LLVM harness (Python) changes only - No new environment variables (uses existing 3 from Phase 277 P2) - No JoinIR/Rust changes (root fix is Phase 279) - Default behavior unchanged (strict mode opt-in) ## Next Steps - Phase 278: Remove deprecated env var support - Phase 279: Root fix - unify "2本のコンパイラ" pipelines 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-22 14:48:37 +09:00
# Phase 277 P0: PHI型推論ドキュメント整備design-first
Status: planned / docs
Goal: Phase 275/276 で導入・修正された PHI 型推論MIR→LLVM harnessについて、導線・責務・SSOT を “迷子にならない形” で固定する。
Scope:
- 実装のリファクタではなく **ドキュメントSSOT**
- “どのファイルが何の責務か” を明確にし、次回のデバッグで「触る場所」を 1 本化する。
Non-goals:
- 新しい env var 追加
- PHI アルゴリズム変更(仕様変更)
- 既定挙動変更
---
## 1) SSOT の入口を定義する
必ず最初に入口を 1 箇所に固定する:
- `docs/development/current/main/phases/phase-277/README.md` を「入口SSOT」にする
- PHI 関連の “概念” と “コードの参照先” を README から辿れるようにする
---
## 2) “2本のパイプライン” を防ぐ説明を入れる
このセッションで顕在化した事故:
- ルートAでは BinOp 型伝播→PHI 型解決
- ルートBでは PHI 型解決→BinOp 型伝播
結果:
- 同じ fixture が片方で PASS、片方で FAIL実質 “2本のコンパイラ”
P0 では、これを README で明示し、根治フェーズPhase 279へ誘導する文言を固定する。
---
## 3) コード責務マップ(最低限)
以下の “責務の箱” を docs に書き出す(箇条書きでよい):
- **MIR 側型情報のSSOT**
- `MirInstruction.dst_type` の意味instruction-local SSOT
- `value_types`propagation/inference の結果の意味analysis SSOT
- PHI の `dst_type` の意味PHI-local SSOT
- **JoinIR / bridge 側**
- “どのルートで type propagation が走るか”
- “どの段で value_types が更新されるか”
- **LLVM harness 側(消費者)**
- `type_helper.py` が SSOT であることPhase 276 P0
- `dst_type_to_llvm_type` の contract`f64` / `i64` handle / `void`
---
## 4) デバッグ導線(最小)
“迷子防止” のため、以下を docs に固定する:
- PHI関連の推奨 env varPhase 277 P2 の統合版)
- `NYASH_LLVM_DEBUG_PHI=1`
- `NYASH_LLVM_DEBUG_PHI_TRACE=1`
- `NYASH_LLVM_PHI_STRICT=1`
- 典型的な確認コマンド1〜2本だけ
- 失敗時に「次に見るファイル」を 1 行で指示type_helper → wiring → resolver の順など)
---
## 5) 完了条件
- README から “PHI型推論の導線” が 1 本で読める
- “2本のパイプライン” の危険と、根治フェーズPhase 279へのリンクが明示されている
- 既存 docs との矛盾がないPhase 275/276/277 の整合)