Files
hakorune/docs/development/current/PHI_NORMALIZATION_PLAN.md

30 lines
2.1 KiB
Markdown
Raw Normal View History

# Phi 正規化プラン9.78h スキャフォールド)
feat(hako_check): Phase 153 - Dead code detection revival (JoinIR version) Implement comprehensive dead code detection for hako_check with JoinIR integration, following Phase 133/134/152 box-based modularity pattern. ## Key Achievements 1. **Comprehensive Inventory** (`phase153_hako_check_inventory.md`): - Documented current hako_check architecture (872 lines) - Analyzed existing HC011/HC012 rules - Confirmed JoinIR-only pipeline (Phase 124) - Identified Phase 153 opportunities 2. **DeadCodeAnalyzerBox** (`rule_dead_code.hako`): - Unified HC019 rule (570+ lines) - Method-level + box-level dead code detection - DFS reachability from entrypoints - Text-based analysis (no MIR JSON dependency for MVP) - Heuristic-based false positive reduction 3. **CLI Integration** (`cli.hako`): - Added `--dead-code` flag for comprehensive mode - Added `--rules dead_code` for selective execution - Compatible with --format (text/json-lsp/dot) 4. **Test Infrastructure**: - HC019_dead_code test directory (ng/ok/expected.json) - `hako_check_deadcode_smoke.sh` with 4 test cases ## Technical Details - **Input**: Analysis IR (MapBox with methods/calls/boxes/entrypoints) - **Output**: HC019 diagnostics - **Algorithm**: Graph-based DFS reachability - **Pattern**: Box-based modular architecture - **No ENV vars**: CLI flags only ## Files Modified - NEW: docs/development/current/main/phase153_hako_check_inventory.md - NEW: tools/hako_check/rules/rule_dead_code.hako - MOD: tools/hako_check/cli.hako - NEW: tools/hako_check/tests/HC019_dead_code/ - NEW: tools/hako_check_deadcode_smoke.sh - MOD: CURRENT_TASK.md ## Next Steps - Phase 154+: MIR CFG integration for block-level detection - Phase 160+: Integration with .hako JoinIR/MIR migration 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 14:19:48 +09:00
> **Status**: Archived plan実装済み / 設計メモ)
> **Note**: Step 3 まで実装済みで、MIR ビルダーは既定で PHI-on。以降は `docs/development/roadmap/` / `docs/private/roadmap/` 側の設計を正とし、このファイルは当時の段階プランの記録として残しています。
feat(hako_check): Phase 153 - Dead code detection revival (JoinIR version) Implement comprehensive dead code detection for hako_check with JoinIR integration, following Phase 133/134/152 box-based modularity pattern. ## Key Achievements 1. **Comprehensive Inventory** (`phase153_hako_check_inventory.md`): - Documented current hako_check architecture (872 lines) - Analyzed existing HC011/HC012 rules - Confirmed JoinIR-only pipeline (Phase 124) - Identified Phase 153 opportunities 2. **DeadCodeAnalyzerBox** (`rule_dead_code.hako`): - Unified HC019 rule (570+ lines) - Method-level + box-level dead code detection - DFS reachability from entrypoints - Text-based analysis (no MIR JSON dependency for MVP) - Heuristic-based false positive reduction 3. **CLI Integration** (`cli.hako`): - Added `--dead-code` flag for comprehensive mode - Added `--rules dead_code` for selective execution - Compatible with --format (text/json-lsp/dot) 4. **Test Infrastructure**: - HC019_dead_code test directory (ng/ok/expected.json) - `hako_check_deadcode_smoke.sh` with 4 test cases ## Technical Details - **Input**: Analysis IR (MapBox with methods/calls/boxes/entrypoints) - **Output**: HC019 diagnostics - **Algorithm**: Graph-based DFS reachability - **Pattern**: Box-based modular architecture - **No ENV vars**: CLI flags only ## Files Modified - NEW: docs/development/current/main/phase153_hako_check_inventory.md - NEW: tools/hako_check/rules/rule_dead_code.hako - MOD: tools/hako_check/cli.hako - NEW: tools/hako_check/tests/HC019_dead_code/ - NEW: tools/hako_check_deadcode_smoke.sh - MOD: CURRENT_TASK.md ## Next Steps - Phase 154+: MIR CFG integration for block-level detection - Phase 160+: Integration with .hako JoinIR/MIR migration 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-04 14:19:48 +09:00
目的: ループ/分岐における Phi 選択を正道に戻し、借用衝突を避けつつ段階導入する。
段階プラン80/20
- Step 1: 実行系での選択復帰(完了)
- `previous_block` に基づき `inputs[(bb==prev)]` を選択。見つからない場合は先頭をフォールバック。
- デバッグ: `NYASH_VM_DEBUG_PHI=1` で選択ログ。
- Step 2: LoopExecutor 連携
- `VM::loop_execute_phi``LoopExecutor::execute_phi` に委譲(安全な借用構成に整理)。
- `record_transition(from,to)` をもとにヘッダ検出・イテレーション情報を活用。
- Step 3: 正規 SSA への復帰
- Builder 側で phi 挿入・seal・predecessor 更新を正道で実装。
- Verifier に phi 一貫性(定義支配/マージ使用)チェックを追加・厳格化。
- Step 4: ログ削減とテスト
- 代表ケースloop/if-merge/whileをスナップショット化。
- 既定で静音、`NYASH_VM_DEBUG_PHI` のみで詳細。
実装状況2025-08-26
- Step 1 完了: `VM::loop_execute_phi``previous_block` による選択に対応。
- Step 2 スケルトン導入: `LoopExecutor` へphi実行を委譲し、`control_flow::record_transition(from,to)``previous_block` と遷移を記録。VM本体の分岐時に呼び出し済み。
- 既知の課題: `LoopExecutor` のヘッダ検出/イテレーション管理の強化(いまは簡易)。
次アクション
- `LoopExecutor` のヘッダ判定とイテレーション可視化を拡充(`is_loop_header` の実装、`NYASH_VM_DEBUG_PHI` 出力拡張)。
- Builder 側の phi 正規化 TODO を CURRENT_TASK に追記seal/pred更新・Phi先頭挿入の確認用ユニットテスト追加