hakorune/docs/development/current/main/phase33-17-joinir-modularization-analysis.md

Phase 33-17: JoinIR モジュール化分析

実行日: 2025-12-07

現状のファイルサイズ分析

649行 instruction_rewriter.rs  ⚠️ 最大のファイル（目標200行の3.2倍）
405行 exit_binding.rs          ✅ 適切（テスト含む）
355行 pattern4_with_continue.rs
338行 routing.rs
318行 loop_header_phi_builder.rs ⚠️ やや大きい
300行 merge/mod.rs              ✅ 適切
250行 trace.rs
228行 ast_feature_extractor.rs
214行 pattern2_with_break.rs
192行 router.rs
176行 pattern1_minimal.rs
163行 pattern3_with_if_phi.rs
157行 exit_line/reconnector.rs
139行 exit_line/meta_collector.rs
104行 value_collector.rs
103行 exit_line/mod.rs
98行  exit_phi_builder.rs
65行  block_allocator.rs

🎯 モジュール化推奨事項

優先度A: instruction_rewriter.rs (649行 → 3ファイル200行以下)

問題:

• 1ファイル649行は箱理論の単一責任原則に違反
• 3つの独立した関心事が混在:
  1. TailCallKind分類ロジック (70行)
  2. 命令書き換え処理 (400行)
  3. MergeResult構築 (170行)

推奨分割:

instruction_rewriter.rs (649行)
  ↓
1. tail_call_classifier.rs (90行)
   - TailCallKind enum
   - classify_tail_call()
   - 分類ロジックの完全カプセル化

2. instruction_mapper.rs (350行)
   - merge_and_rewrite() のコア処理
   - Call→Jump変換
   - 命令リマッピング

3. boundary_injector.rs (180行)
   - BoundaryInjector 呼び出し
   - Copy命令生成
   - boundary関連ロジック

4. merge_result.rs (30行)
   - MergeResult struct定義
   - 関連ヘルパー

効果:

• ✅ 単一責任の原則完全準拠
• ✅ テスタビリティ向上（tail call分類を独立テスト可能）
• ✅ 可読性向上（ファイルサイズ200行以下）

---

優先度B: loop_header_phi_builder.rs (318行 → 2ファイル)

問題:

• 318行は200行目標を58%超過
• 2つの関心事が存在:
  1. LoopHeaderPhiInfo管理 (データ構造)
  2. LoopHeaderPhiBuilder構築ロジック (アルゴリズム)

推奨分割:

loop_header_phi_builder.rs (318行)
  ↓
1. loop_header_phi_info.rs (150行)
   - LoopHeaderPhiInfo struct
   - CarrierPhiEntry struct
   - get/set メソッド

2. loop_header_phi_builder.rs (170行)
   - LoopHeaderPhiBuilder
   - build() 実装
   - finalize() 実装

効果:

• ✅ データとロジックの分離
• ✅ LoopHeaderPhiInfo を他モジュールから独立利用可能
• ✅ ファイルサイズ200行以下達成

---

優先度C: pattern4_with_continue.rs (355行)

問題:

• 355行（目標の1.8倍）
• Pattern 2/3との重複コードが存在する可能性

推奨調査:

# Pattern 2/3/4の共通ヘルパー抽出可能性を調査
grep -A5 "extract.*variable\|build.*boundary" pattern*.rs

暫定推奨:

• Pattern 4は継続フラグで大きくなるのは自然
• 共通ヘルパーがあれば pattern_helpers.rs に抽出
• なければ現状維持（Phase 33-17の対象外）

---

優先度D: routing.rs (338行)

問題:

• 338行（目標の1.7倍）
• パターンルーティングロジックが肥大化

推奨調査:

• Pattern 1-4の条件分岐ロジックが重複していないか確認
• 抽出可能な共通ロジックがあれば分離

暫定推奨:

• ルーティングは本質的に線形な条件分岐になる
• 無理に分割せず、Phase 34以降で見直し

---

🚀 実装計画

Phase 33-17-A: instruction_rewriter分割（最優先）

タスク:

1. tail_call_classifier.rs 作成（TailCallKind + classify_tail_call）
2. boundary_injector_wrapper.rs 作成（BoundaryInjector呼び出し）
3. instruction_mapper.rs 作成（merge_and_rewriteコア）
4. merge_result.rs 作成（MergeResult struct）
5. instruction_rewriter.rs → 上記4ファイルへ移行
6. merge/mod.rs の import 更新
7. cargo build --release 確認

期待効果:

• instruction_rewriter.rs: 649行 → 削除（4ファイルに分散）
• 最大ファイル: 350行（instruction_mapper.rs）
• 200行超ファイル: 2個（instruction_mapper, pattern4）

---

Phase 33-17-B: loop_header_phi_builder分割（次点）

タスク:

1. loop_header_phi_info.rs 作成（データ構造）
2. loop_header_phi_builder.rs → ビルダーロジックのみ残す
3. merge/mod.rs の import 更新
4. cargo build --release 確認

期待効果:

• loop_header_phi_builder.rs: 318行 → 170行
• loop_header_phi_info.rs: 新規 150行
• 200行超ファイル: 1個（instruction_mapper のみ）

---

📊 完成後の予測

Before (Phase 33-16)

649行 instruction_rewriter.rs  ⚠️
318行 loop_header_phi_builder.rs ⚠️
355行 pattern4_with_continue.rs ⚠️

After (Phase 33-17完了後)

350行 instruction_mapper.rs   ⚠️ (許容範囲)
355行 pattern4_with_continue.rs ⚠️ (継続フラグで妥当)
180行 boundary_injector_wrapper.rs ✅
170行 loop_header_phi_builder.rs ✅
150行 loop_header_phi_info.rs ✅
90行  tail_call_classifier.rs ✅
30行  merge_result.rs ✅

達成指標:

• ✅ 200行超ファイル: 4個 → 2個（50%削減）
• ✅ 最大ファイル: 649行 → 355行（45%削減）
• ✅ 単一責任の原則完全準拠

---

🎯 Next Steps

1. Phase 33-17-A実装 → instruction_rewriter分割（優先度最高）
2. Phase 33-17-B実装 → loop_header_phi_builder分割
3. Pattern 4調査 → 共通ヘルパー抽出可能性検証
4. Phase 33-18検討 → routing.rs の最適化（必要に応じて）

---

箱理論への準拠

設計哲学

• ✅ TailCallClassifier Box: 分類ロジックの完全カプセル化
• ✅ BoundaryInjectorWrapper Box: boundary処理の委譲
• ✅ InstructionMapper Box: 命令変換の単一責任
• ✅ LoopHeaderPhiInfo Box: データ構造の独立管理

命名規則

• 〜Classifier: 分類・判定ロジック
• 〜Mapper: 変換・マッピング処理
• 〜Wrapper: 外部Boxへの委譲
• 〜Info: データ構造管理

---

📝 実装時の注意点

1. 後方互換性: merge/mod.rsからのインターフェースは変更しない
2. テスト: 既存のテストが全てパスすることを確認
3. ドキュメント: 各ファイルに箱理論の役割を明記
4. 段階的移行: 1ファイルずつ移行 → ビルド確認 → 次へ

---

Status: 分析完了、Phase 33-17-A実装準備完了 Estimated Time: Phase 33-17-A (2時間), Phase 33-17-B (1時間)