hakorune/docs/development/current/main/joinir-architecture-overview.md

JoinIR Architecture Overview (2025‑12‑06)

このドキュメントは、JoinIR ライン全体（Loop/If lowering, ExitLine, Boundary, 条件式 lowering）の 「箱」と「契約」を横串でまとめた設計図だよ。selfhost / JsonParser / hako_check など、 どの呼び出し元から見てもここを見れば「JoinIR 層の責務と流れ」が分かるようにしておく。

変更があったら、Phase ドキュメントではなく このファイルを随時更新する 方針。

---

1. 不変条件（Invariants）

JoinIR ラインで守るべきルールを先に書いておくよ：

1. JoinIR 内部は JoinIR ValueId だけ

   • JoinIR lowering が発行する JoinInst の ValueId は、すべて alloc_value() で割り当てるローカル ID。
   • Rust/MIR 側の ValueId（builder.variable_map に入っている ID）は、JoinIR には直接持ち込まない。

2. host ↔ join の橋渡しは JoinInlineBoundary 系だけ

   • host から JoinIR への入力（ループ変数 / 条件専用変数）は
     • JoinInlineBoundary.join_inputs + host_inputs
     • JoinInlineBoundary.condition_bindings（ConditionBinding） だけで接続する。
   • 出力（キャリアの出口）は JoinInlineBoundary.exit_bindings に一本化する。

3. 式としての戻り値とキャリア更新を分離する

   • 「ループが式として値を返す」ケース（例: let r = loop_min_while(...)）の出口は exit_phi_builder が扱う。
   • 「ループが状態更新だけする」ケース（例: trim の start/end）の出口は ExitLine（ExitMeta / ExitBinding / ExitLineReconnector） だけが扱う。

4. ループ制御 vs 条件式の分離

   • ループの「形」（Pattern1–4, LoopFeatures）は control-flow 専用の箱が担当。
   • 条件式（i < len && (ch == " " || ch == "\t") 等）は BoolExprLowerer / condition_to_joinir が担当し、 ループパターンは boolean ValueId だけを受け取る。

5. Fail‑Fast

   • JoinIR が対応していないループパターン / if パターンは、必ず [joinir/freeze] 等で明示的にエラーにする。
   • LoopBuilder 等へのサイレントフォールバックは禁止（Phase 186–187 で完全削除済み）。

---

2. 主な箱と責務

2.1 Loop 構造・検出ライン

• LoopFeatures / LoopPatternKind / router

  • ファイル:
    • src/mir/loop_pattern_detection.rs
    • src/mir/builder/control_flow/joinir/patterns/router.rs
  • 責務:
    • AST からループ構造の特徴（has_break, has_continue, has_if_else_phi, carrier_count 等）を抽出。
    • classify(&LoopFeatures) で Pattern1–4 に分類。
    • LOOP_PATTERNS テーブルを通じて該当 lowerer（pattern*_minimal.rs）にルーティング。
    • Phase 170‑C 系で LoopUpdateSummary（各キャリアの UpdateKind 情報）を統合し、
      CaseALoweringShape が関数名ではなく構造＋更新パターンだけを見て判定できるようにする計画。

• Pattern Lowerers (Pattern1–4)

  • ファイル例:
    • simple_while_minimal.rs（Pattern1）
    • loop_with_break_minimal.rs（Pattern2）
    • loop_with_if_phi_minimal.rs（Pattern3）
    • loop_with_continue_minimal.rs（Pattern4）
  • 責務:
    • LoopScopeShape / AST / LoopFeatures を入力として JoinIR の JoinModule を構築。
    • JoinFragmentMeta{ expr_result, exit_meta } を返し、出口情報を ExitLine に渡す。
    • host/MIR の ValueId は一切扱わない（JoinIR ローカルの ValueId のみ）。

• CommonPatternInitializer (Phase 33-22)

  • ファイル: src/mir/builder/control_flow/joinir/patterns/common_init.rs
  • 責務:
    • 全 Pattern 共通の初期化ロジック統一化（ループ変数抽出 + CarrierInfo 構築）。
    • All 4 loop patterns use this for unified initialization, guaranteeing boundary.loop_var_name is always set and preventing SSA-undef bugs.

• JoinIRConversionPipeline (Phase 33-22)

  • ファイル: src/mir/builder/control_flow/joinir/patterns/conversion_pipeline.rs
  • 責務:
    • JoinIR → MIR 変換フロー統一化（JoinModule → MirModule → merge_joinir_mir_blocks）。
    • Single entry point for JoinIR→MIR conversion, encapsulating phases 1-6 and ensuring consistent transformation across all patterns.

2.2 条件式ライン（式の箱）

• BoolExprLowerer

  • ファイル: src/mir/join_ir/lowering/bool_expr_lowerer.rs
  • 責務:
    • AST の boolean 式 → MIR の Compare/BinOp/UnaryOp に lowering（通常の if/while 用）。
    • <, ==, !=, <=, >=, > と &&, ||, ! の組合せを扱う。

• condition_to_joinir + ConditionEnv/ConditionBinding

  • ファイル: src/mir/join_ir/lowering/condition_to_joinir.rs
  • 責務:
    • ループ lowerer 用の「AST 条件 → JoinIR Compute命令列」。
    • ConditionEnv 経由で「変数名 → JoinIR ValueId」のみを見る。
    • host 側の ValueId は ConditionBinding { name, host_value, join_value } として JoinInlineBoundary に記録する。

• LoopConditionScopeBox（Phase 170-D 実装済み）

  • ファイル: src/mir/loop_pattern_detection/loop_condition_scope.rs
  • 責務:
    • 条件式に登場する変数が、ループパラメータ（LoopParam）/ループ外ローカル（OuterLocal）/ループ本体ローカル（LoopBodyLocal）のどれかを分類する。
    • Pattern2/4 が「対応してよい条件のスコープ」を判定するための箱。
    • ループ本体ローカルを条件に含む高度なパターンは、LoopBodyCarrierPromoter（Phase 171） で carrier に昇格させる。
  • Bug Fix（2025-12-07）:
    • 関数パラメータが LoopBodyLocal と誤分類される問題を修正。
    • condition_var_analyzer.rs の is_outer_scope_variable() で、variable_definitions に含まれない変数を OuterLocal とする。
    • これにより JsonParserBox などの関数パラメータを含むループが正しく動作。

• LoopBodyCarrierPromoter（Phase 171-C-1 実装中）

  • ファイル: src/mir/loop_pattern_detection/loop_body_carrier_promoter.rs
  • 責務:
    • LoopBodyLocal 変数を carrier に昇格させ、Pattern 2/4 で処理可能にする。
    • 昇格成功 → Pattern 2/4 にルーティング（新しい carrier 情報付き）。
    • 昇格失敗 → UnsupportedPattern（Fail-Fast）。
  • Pattern 2/4 + Pattern 5 の境界線:
    • Pattern 2/4 の守備範囲: LoopParam + OuterLocal のみ。LoopBodyLocal 条件は受け入れない。
    • Pattern 5 の守備範囲: LoopBodyLocal を carrier に昇格。成功なら Pattern 2/4 へ委譲。
    • 境界: LoopConditionScopeBox が LoopBodyLocal 検出 → LoopBodyCarrierPromoter で昇格試行。
  • Design Strategy（Design D: Evaluated Bool Carrier）:
    • ch == " " || ... のような条件を is_whitespace (bool carrier) に変換。
    • 昇格例:

      // Before (blocked)
      loop(start < end) {
          local ch = s.substring(start, start+1)
          if ch == " " || ... { ... } else { break }
      }
      
      // After (Pattern2 compatible)
      local is_whitespace = true
      loop(start < end && is_whitespace) {
          local ch = s.substring(start, start+1)
          is_whitespace = (ch == " " || ...)
          if is_whitespace { ... } else { break }
      }
      

  • Current Status（Phase 171-C-1）:
    • ✅ API 定義: PromotionRequest → PromotionResult
    • ✅ Skeleton 実装: LoopBodyLocal 検出・定義探索
    • ⏳ Promotion logic: Phase 171-C-2 で Trim パターンの実際の昇格ロジックを実装予定
  • 詳細: docs/development/current/main/phase171-pattern5-loop-inventory.md

2.3 キャリア / Exit / Boundary ライン

• CarrierInfo / LoopUpdateAnalyzer

  • ファイル:
    • src/mir/join_ir/lowering/carrier_info.rs
    • LoopUpdateAnalyzer 周辺
  • 責務:
    • ループ内で更新される変数（carrier）の名前と host ValueId を検出。
    • 更新式（sum = sum + i, count = count + 1 等）を UpdateExpr として保持。

• ExitMeta / JoinFragmentMeta

  • ファイル: carrier_info.rs 等
  • 責務:
    • JoinIR lowerer が「どの carrier が、どの JoinIR ValueId で出口に出るか」を記録。
    • JoinFragmentMeta の一部として expr_result: Option<ValueId> と exit_meta をまとめる。

• ExitMetaCollector

  • ファイル: src/mir/builder/control_flow/joinir/merge/exit_line/meta_collector.rs
  • 責務:
    • ExitMeta + CarrierInfo から Vec<LoopExitBinding{ carrier_name, join_exit_value, host_slot }> を構築。
    • 副作用なしの pure function。

• JoinInlineBoundary

  • ファイル: src/mir/join_ir/lowering/inline_boundary.rs
  • フィールド（主なもの）:
    • join_inputs / host_inputs：ループパラメータの橋渡し
    • condition_bindings: Vec<ConditionBinding>：条件専用変数の橋渡し
    • exit_bindings: Vec<LoopExitBinding>：キャリア出口の橋渡し
  • 責務:
    • 「host 関数 ↔ JoinIR fragment」の境界情報の SSOT。

• BoundaryInjector

  • ファイル: src/mir/builder/joinir_inline_boundary_injector.rs
  • 責務:
    • join_inputs + host_inputs / condition_bindings に基づき、entry block に Copy 命令を挿して host→JoinIR を接続。

• ExitLine (ExitMetaCollector / ExitLineReconnector / ExitLineOrchestrator)

  • ファイル:
    • src/mir/builder/control_flow/joinir/merge/exit_line/mod.rs
    • exit_line/meta_collector.rs
    • exit_line/reconnector.rs
  • 責務:
    • ExitMeta から exit_bindings を構築し（Collector）、 remapper と組み合わせて builder.variable_map のキャリアスロットを更新（Reconnector）。
    • expr 用の PHI には一切触れない（carrier 専用ライン）。

2.4 expr result ライン（式としての戻り値）

• exit_phi_builder

  • ファイル: src/mir/builder/control_flow/joinir/merge/exit_phi_builder.rs
  • 責務:
    • JoinIR fragment が「式としての戻り値（expr_result）」を持つ場合にだけ、 Return 値を exit block の PHI にまとめて 1 つの ValueId を返す（※Phase 33‑16 で正式再実装予定）。
    • ループキャリア（start/end/sum 等）は扱わない（carrier は ExitLine 専用ライン）。

• InstructionRewriter（expr_result のみを exit_phi_inputs に流す）

  • ファイル: instruction_rewriter.rs
  • 責務:
    • JoinFragmentMeta.expr_result が Some の場合だけ、該当 return 値を exit_phi_inputs に積むのが理想形。
    • carrier 用の return/jump は ExitMeta/ExitLine 側で扱う。
    • 現状（Phase 33‑15 時点）:
      • SSA‑undef を避けるため、一時的に exit_phi_inputs / carrier_inputs の収集を停止している。
      • そのため「ループを式として評価する」ケースでは PHI を経由した expr 結果はまだ生成されない。
      • これは 一時的な止血措置 であり、Phase 33‑16 で「Loop ヘッダ PHI を出口値の SSOT とする」設計に差し替える予定。

---

3. JoinIR → MIR 統合の全体フロー

1. Pattern router が AST/LoopFeatures から Pattern1–4 を選択し、各 lowerer が (JoinModule, JoinFragmentMeta) を生成。
2. JoinInlineBoundary が:
   • ループ入力（join_inputs/host_inputs）
   • 条件変数（condition_bindings）
   • キャリア出口（exit_bindings） を保持。
3. merge_joinir_mir_blocks が:
   • BlockID/ValueID remap
   • JoinIR 関数群の inline
   • Return→jump の書き換え
   • expr result 用 PHI（exit_phi_builder）
   • ExitLineOrchestrator（ExitMetaCollector + ExitLineReconnector） を順に実行。

この全体フローの詳細は src/mir/builder/control_flow/joinir/merge/mod.rs と phase-189-multi-function-mir-merge/README.md を参照。

---

4. selfhost / .hako JoinIR Frontend との関係

JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ側でも生成・解析される予定だよ：

• .hako 側の JsonParser/分析箱は、Program JSON / MIR JSON v1 を読んで JoinIR/MIR を解析する。
• Rust 側 JoinIR ラインの設計変更（特に ValueId/ExitLine/Boundary 周り）は、 必ずこのファイルを更新してから .hako 側にも段階的に反映する方針。

「JoinIR の仕様」「箱の責務」「境界の契約」は、このファイルを SSOT として運用していく。

---

5. 関連ドキュメント

• docs/development/current/main/10-Now.md
  • 全体の「いまどこ」を短くまとめたダッシュボード。
• docs/private/roadmap2/phases/phase-180-joinir-unification-before-selfhost/README.md
  • JoinIR 統一フェーズ全体のロードマップと進捗。
• 各 Phase 詳細:
  • 185–188: Strict mode / LoopBuilder 削除 / Pattern1–4 基盤
  • 189–193: Multi-function merge / Select bridge / ExitLine 箱化
  • 171–172 / 33‑10/13: ConditionEnv, ConditionBinding, JoinFragmentMeta, ExitLineRefactor 等