Files
hakorune/docs/development/current/main/phases
tomoaki bbfc3c1d94 refactor(joinir): Phase 287 P2 - Strengthen BackEdge/latch conditions (WIP)
**Problem**: Phase 188.3 Pattern6 (nested loop) encounters infinite loop
- inner_step → inner_step (self-recursion) incorrectly classified as BackEdge
- → redirects to outer header (loop_step) instead of inner_step entry
- is_recursive_call causes inner recursion to overwrite outer latch values
- → PHI receives wrong values → i doesn't increment → infinite loop

**Fix 1: BackEdge classification strictness** (tail_call_classifier.rs)
- Add `is_target_loop_entry` parameter to classify_tail_call()
- BackEdge ONLY when target==loop_step (entry_func), not inner_step
- Prevents inner_step → inner_step from redirecting to outer header

**Fix 2: latch_incoming guard** (instruction_rewriter.rs)
- Change condition from `is_recursive_call || is_target_loop_entry`
  to `is_target_loop_entry` only
- Prevents inner_step self-recursion from overwriting outer loop's latch
- set_latch_incoming() now called with correct values (verified by debug)

**Status**: 🚧 WIP - Infinite loop still occurs
- set_latch_incoming('i', BasicBlockId(8), ValueId(21))  Called correctly
- But final PHI: `phi [%4, bb8]` instead of `phi [%21, bb8]` 
- Root cause likely in PHI generation (merge/mod.rs), not latch_incoming
- Next: Investigate why latch_incoming values aren't used in PHI

**Files**:
- src/mir/builder/control_flow/joinir/merge/tail_call_classifier.rs
- src/mir/builder/control_flow/joinir/merge/instruction_rewriter.rs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-27 08:32:14 +09:00
..
2025-12-17 04:26:23 +09:00
2025-12-17 04:26:23 +09:00
2025-12-17 04:26:23 +09:00
2025-12-17 23:30:13 +09:00
2025-12-17 23:30:13 +09:00
2025-12-17 23:45:55 +09:00
2025-12-18 02:39:44 +09:00
2025-12-18 02:55:14 +09:00
2025-12-18 05:50:29 +09:00
2025-12-18 06:47:43 +09:00

Phase ドキュメント

このフォルダは、実装フェーズPhase 131, Phase 33 等)ごとの詳細記録を保管します。

現在の Phase

  • Phase 139DONE: post-if post_k の return lowering を ReturnValueLowererBox に統一(出口 SSOT 完成)
  • Phase 140DONE: NormalizedExprLowererBox 初版pure expression のみ)
  • Phase 141 P0DONE: impure 拡張点contractを SSOT 化Call/MethodCall はまだ out-of-scope
  • Phase 141 P1DONE: “既知 intrinsic だけ” を許可して段階投入length0
  • Phase 141 P1.5DONE: known intrinsic registry + available_inputs 3-source merge + diagnostics
  • Phase 141 P2+planned: Call/MethodCall 対応effects + typing の段階投入)
  • Phase 142-loopstmt P0DONE: 正規化単位を statementloop 1個へ寄せるパターン爆発を止める
  • Phase 142-loopstmt P1DONE: LLVM EXE smoke同 fixtureを追加
  • Phase 143-loopvocabplanned: StepTree の語彙拡張loop 内 if/break/continue を「語彙追加」で吸収)
  • Phase 9192: Selfhost depth2 coverageP5b escape recognition → lowering
  • Phase 94100: P5b escape E2E / Trim policy / pinned + accumulatorVM/LLVM EXE parity
  • Phase 102: real-app read_quoted loop regressionVM + LLVM EXE
  • Phase 103: if-only regression baselineVM + LLVM EXE / plan
  • Phase 113: if-only partial assign parity片側代入の保持 merge
  • Phase 107109: real-app depth-scan / policy router SSOT / error hint SSOT
  • Phase 110112: 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 (根本原因分析)

参照方法

  1. 現在の Phase を知りたい../10-Now.md
  2. 該当 Phase を詳しく知りたい → フォルダを開く
  3. 設計背景を知りたい../design/
  4. 調査ログを見たい../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