Files

tomoaki 757193891f 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

2.7 KiB

Raw Blame History

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 var（Phase 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 の整合）

2.7 KiB Raw Blame History Unescape Escape