tomoaki
575a5d750f
## Task A: Loop Invariants Architecture (Option A - Boundary Extension) Introduced explicit loop_invariants concept for variables that are: - Used in loop body but never modified (e.g., substring needle in index_of) - Need header PHI (all iterations use same value) - Do NOT need exit PHI (not a LoopState) Implementation: - Added `loop_invariants: Vec<(String, ValueId)>` field to JoinInlineBoundary - Added `with_loop_invariants()` method to JoinInlineBoundaryBuilder - Modified Pattern 6 to use loop_invariants instead of ConditionOnly misuse * s (haystack) and ch (needle) now properly classified * exit_bindings simplified to only LoopState carriers - Extended LoopHeaderPhiBuilder to generate invariant PHIs * Entry PHI: from host * Latch PHI: self-reference (same value every iteration) - Updated instruction_rewriter to handle invariant latch incoming Files Modified: - src/mir/join_ir/lowering/inline_boundary.rs (structure + builder) - src/mir/join_ir/lowering/inline_boundary_builder.rs (builder method) - src/mir/builder/control_flow/joinir/patterns/pattern6_scan_with_init.rs - src/mir/builder/control_flow/joinir/merge/loop_header_phi_builder.rs - src/mir/builder/control_flow/joinir/merge/mod.rs - src/mir/builder/control_flow/joinir/merge/instruction_rewriter.rs ## Task B: Code Quality - var() Helper Unification Created common module to eliminate var() duplication: - New module: src/mir/builder/control_flow/joinir/patterns/common/ - Centralized var() helper in ast_helpers.rs - Updated Pattern 6 and Pattern 2 to use common var() - Test code (5 occurrences) deferred to Phase 256+ per 80/20 rule Result: Eliminated 2 duplicate var() functions, 5 test occurrences remain Files Created: - src/mir/builder/control_flow/joinir/patterns/common/ast_helpers.rs - src/mir/builder/control_flow/joinir/patterns/common/mod.rs Files Modified: - src/mir/builder/control_flow/joinir/patterns/mod.rs - src/mir/builder/control_flow/joinir/patterns/pattern6_scan_with_init.rs - src/mir/builder/control_flow/joinir/patterns/policies/balanced_depth_scan_policy.rs ## Task C: Documentation - PostLoopEarlyReturnPlan Usage Examples Enhanced post_loop_early_return_plan.rs with: - Architecture explanation (exit PHI usage prevents DCE) - Pattern 2 example (Less: balanced_depth_scan) - Pattern 6 example (NotEqual: index_of) - Builder defer decision: when 4+ patterns emerge, add builder Files Modified: - src/mir/builder/control_flow/joinir/patterns/policies/post_loop_early_return_plan.rs ## Task D: Phase 256 Preparation Analyzed next failure from smoke tests: - `StringUtils.split/2` with variable-step loop - Not constant step (i += len or similar) - Three implementation options identified Created Phase 256 README with: - Minimal reproduction code - Root cause analysis - Implementation options with trade-offs - Clear next steps Files Created: - docs/development/current/main/phases/phase-256/README.md ## Verification Results ✅ All tests passing: - pattern254_p0_index_of_vm.sh: PASS - No regression in Pattern 1-5 - Smoke test progresses past json_lint_vm to next failure ✅ Architecture achievements: - Semantic clarity: loop_invariants vs exit_bindings properly separated - ConditionOnly misuse eliminated - PHI generation correct for all carrier types - Code quality: var() duplication reduced - Next phase clearly defined ## Summary Phase 255 P2 achieves root-cause fix for multi-param loop support: - Boundary concept expanded (loop_invariants field) - Pattern 6 architecture corrected (no ConditionOnly misuse) - Code quality improved (var() centralized) - Next pattern (variable-step) is now the challenge ✨ Box-first principles maintained: clean separation, explicit roles, minimal coupling 🧠 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Phase ドキュメント
このフォルダは、実装フェーズ（Phase 131, Phase 33 等）ごとの詳細記録を保管します。
現在の Phase
- Phase 139（DONE）: post-if
post_kの return lowering をReturnValueLowererBoxに統一（出口 SSOT 完成） - Phase 140（DONE）:
NormalizedExprLowererBox初版（pure expression のみ） - Phase 141 P0（DONE）: impure 拡張点（contract）を SSOT 化（Call/MethodCall はまだ out-of-scope）
- Phase 141 P1（DONE）: “既知 intrinsic だけ” を許可して段階投入（length0）
- Phase 141 P1.5（DONE）: known intrinsic registry + available_inputs 3-source merge + diagnostics
- Phase 141 P2+（planned）: Call/MethodCall 対応（effects + typing の段階投入）
- Phase 142-loopstmt P0（DONE）: 正規化単位を statement（loop 1個）へ寄せる（パターン爆発を止める）
- Phase 142-loopstmt P1（DONE）: LLVM EXE smoke（同 fixture）を追加
- Phase 143-loopvocab（planned）: StepTree の語彙拡張（loop 内 if/break/continue を「語彙追加」で吸収）
- Phase 91–92: Selfhost depth‑2 coverage（P5b escape recognition → lowering）
- Phase 94–100: P5b escape E2E / Trim policy / pinned + accumulator（VM/LLVM EXE parity）
- Phase 102: real-app read_quoted loop regression（VM + LLVM EXE）
- Phase 103: if-only regression baseline（VM + LLVM EXE / plan）
- Phase 113: if-only partial assign parity（片側代入の保持 merge）
- Phase 107–109: real-app depth-scan / policy router SSOT / error hint SSOT
- Phase 110–112: ControlTree / StepTree（構造SSOT, dev-only）※設計SSOTは
../design/control-tree.md
Phase フォルダ構成（推奨）
phases/phase-131/
├── README.md (Phase 全体概要)
├── 131-03-llvm-lowering-inventory.md (LLVM 部分のテスト・検証)
├── 131-11-case-c-summary.md (Case C 実装サマリー)
└── phase131-11-case-c-root-cause-analysis.md (根本原因分析)
参照方法
- 現在の Phase を知りたい → ../10-Now.md
- 該当 Phase を詳しく知りたい → フォルダを開く
- 設計背景を知りたい → ../design/
- 調査ログを見たい → ../investigations/
Phase 命名規則
- ファイル名:
phase-<N>-<title>/(例:phase-131/) - 文書名:
<N>-<NN>-<topic>.md(例:131-11-case-c-summary.md)- Phase 番号で自然にソート可能
- 同一 Phase 内で段階的に追跡可能
作成ルール（SSOT）
詳しくは ../DOCS_LAYOUT.md を参照。
- ✅ 置き場所:
phases/phase-<N>/配下のみ - ✅ 内容: Phase の実装記録・進捗・チェックリスト・検証結果
- ❌ 避けるべき: 複数 Phase で参照される設計・アーキテクチャ（→ design/ へ）
最終更新: 2025-12-19