docs: Phase 195 implementation status + Phase 196 (Select bug) planning
Phase 195 implementation complete (Lowerer side): - loop_with_if_phi_minimal.rs: multi-carrier PHI generation (sum + count) - pattern3_with_if_phi.rs: dynamic single/multi-carrier handling - ExitLine/CarrierVar.join_id: NO CHANGES NEEDED (existing infra worked!) - YAGNI principle validated - PhiGroupBox was not necessary Blocker discovered: Nested Select→Branch+Phi conversion bug - JoinIR correctly generates: ValueId(20) = phi [(bb3, 14), (bb4, 18)] - MIR incorrectly produces: %27 = phi [%28, bb8], [%32, bb9] (undefined) - Root cause: joinir_block.rs Select expansion (bridge layer) - NOT a Phase 195 issue - pre-existing bug in Select conversion Phase 196 planned (NEW): - 196-1: Document select_expansion / instruction_rewriter responsibilities - 196-2: Formalize "1 Select = 3 blocks + 1 PHI" interface - 196-3: Debug block reuse / block ID mapping - 196-4: Fix and E2E test (phase195_sum_count.hako → 72) Documentation updates: - phase195-pattern3-extension-design.md: Implementation Status section - CURRENT_TASK.md: Phase 195 complete + Phase 196 TODO - joinir-architecture-overview.md: P3 Lowerer complete, bridge blocker noted Key insight: "Pattern side is done, problem is in bridge side" 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
@ -334,22 +334,33 @@
|
|||||||
- Phase 195: Pattern 3 extension(if-in-loop + multi-flag carriers)
|
- Phase 195: Pattern 3 extension(if-in-loop + multi-flag carriers)
|
||||||
- Phase 200+: ConditionEnv expansion(function-scoped locals)
|
- Phase 200+: ConditionEnv expansion(function-scoped locals)
|
||||||
- Phase 201+: MethodCall extension(multiple calls in body)
|
- Phase 201+: MethodCall extension(multiple calls in body)
|
||||||
- [ ] **Phase 195: Pattern 3 拡張(設計フェーズ)**
|
- [x] **Phase 195: Pattern 3 拡張(設計 + Lowerer 実装完了)** (2025-12-09)
|
||||||
- **目的**: P3(If-Else PHI)を複数キャリア対応に拡張する設計
|
- **目的**: P3(If-Else PHI)を複数キャリア対応に拡張
|
||||||
- 195-1: 対象ループ絞り込み(_parse_string 簡易版、if-sum)
|
- **実装完了**:
|
||||||
- 195-2: LoopUpdateSummary/CarrierInfo 設計整理(複数キャリア対応)
|
- ✅ `loop_with_if_phi_minimal.rs`: multi-carrier PHI 生成(sum + count)
|
||||||
- 195-3: Pattern3 lowerer 設計更新(PhiGroup vs ExitLine 拡張判断)
|
- ✅ `pattern3_with_if_phi.rs`: 単一/複数キャリアを動的処理
|
||||||
- 195-4: 実装スコープ決定(2-3キャリア、既存 UpdateKind 範囲内)
|
- ✅ ExitLine / CarrierVar.join_id: **変更不要**(既存インフラ活用)
|
||||||
- 195-5: ドキュメント更新(CURRENT_TASK.md + overview 更新)
|
- ✅ テストファイル: `phase195_sum_count.hako` 作成
|
||||||
- **設計判断**:
|
- **設計判断の証明**:
|
||||||
- ✅ ExitLine 拡張で対応(PhiGroupBox は作らない - YAGNI 原則)
|
- ✅ ExitLine 拡張で対応(PhiGroupBox は作らない - YAGNI 原則が正しかった)
|
||||||
- ✅ 両分岐での Carrier 定義確認(更新なし = 前の値使用)
|
- ✅ 両分岐での Carrier 定義確認(更新なし = 前の値使用)
|
||||||
- ❌ ConditionEnv 拡張なし(Phase 200+ 保留)
|
- ❌ ConditionEnv 拡張なし(Phase 200+ 保留)
|
||||||
- ❌ LoopBodyLocal + MethodCall 混在は Phase 195+ 延期
|
- **Blocker**: Nested Select→Branch+Phi 変換バグ
|
||||||
- **期待成果**:
|
- JoinIR: `ValueId(20) = phi [(bb3, 14), (bb4, 18)]` ← 正しい
|
||||||
- phase195-pattern3-extension-design.md(完全設計書)
|
- MIR: `%27 = phi [%28, bb8], [%32, bb9]` ← %28, %32 が undefined
|
||||||
- Phase 195-impl の実装スコープ明確化
|
- **原因**: `joinir_block.rs` の Select 展開処理(bridge 層の既存バグ)
|
||||||
- JsonParser カバレッジ 40% → 60% への道筋
|
- **対応**: Phase 196 として分離(Lowerer 側は完了)
|
||||||
|
- **成果**:
|
||||||
|
- P3 Lowerer は複数キャリア対応完了 ✅
|
||||||
|
- ExitLine/CarrierVar は既に対応済み(変更不要)✅
|
||||||
|
- JoinIR→MIR bridge の Select バグは別 Issue として分離 ✅
|
||||||
|
- [ ] **Phase 196: Select 展開/変換バグ調査&修正**(NEW)
|
||||||
|
- **目的**: Nested Select→Branch+Phi 変換の既存バグを修正
|
||||||
|
- 196-1: `select_expansion` / `instruction_rewriter` の責務を doc に整理
|
||||||
|
- 196-2: 「1 Select = 3 ブロック + 1 PHI」変換インタフェース明文化
|
||||||
|
- 196-3: block reuse / block ID マッピングの切り分け
|
||||||
|
- 196-4: 修正実装 + E2E テスト(phase195_sum_count.hako → 72)
|
||||||
|
- **期待成果**: Phase 195 の multi-carrier が E2E で動作
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@ -523,11 +523,12 @@ JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ
|
|||||||
- Deferred loops: _parse_array, _parse_object (multiple MethodCalls)
|
- Deferred loops: _parse_array, _parse_object (multiple MethodCalls)
|
||||||
- 詳細: phase194-loop-inventory.md, phase194-jsonparser-deployment.md
|
- 詳細: phase194-loop-inventory.md, phase194-jsonparser-deployment.md
|
||||||
|
|
||||||
5. **Pattern 3 拡張(複数キャリア対応)** → Phase 195 設計中
|
5. **Pattern 3 拡張(複数キャリア対応)** → Phase 195 Lowerer 完了、Phase 196 待ち
|
||||||
- 目的: P3(If-Else PHI)で 2-3 個の Carrier を同時処理
|
- 目的: P3(If-Else PHI)で 2-3 個の Carrier を同時処理
|
||||||
- 設計判断: ExitLine 拡張で対応(PhiGroupBox は作らない - YAGNI 原則)
|
- **Lowerer 側完了**: multi-carrier PHI 生成(sum + count)✅
|
||||||
- 対象: _parse_string(flag+buffer)、if-sum(sum+count)
|
- **ExitLine**: 変更不要(既存インフラ活用)✅
|
||||||
- Phase 195-impl で実装予定
|
- **Blocker**: JoinIR→MIR の Select 変換バグ(Phase 196 で修正予定)
|
||||||
|
- パターン側は終わり、問題は bridge 側
|
||||||
|
|
||||||
6. **JsonParser 残り複雑ループへの適用(Phase 195+, 200+)**
|
6. **JsonParser 残り複雑ループへの適用(Phase 195+, 200+)**
|
||||||
- Phase 200+: ConditionEnv 拡張 (function-scoped variables) → _parse_number, _atoi
|
- Phase 200+: ConditionEnv 拡張 (function-scoped variables) → _parse_number, _atoi
|
||||||
|
|||||||
@ -621,3 +621,74 @@ Section 7.2 "残タスク" に追記:
|
|||||||
- 設計フェーズで構造を固める
|
- 設計フェーズで構造を固める
|
||||||
- 実装フェーズは lowerer のみに集中
|
- 実装フェーズは lowerer のみに集中
|
||||||
- ドキュメント駆動開発
|
- ドキュメント駆動開発
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implementation Status
|
||||||
|
|
||||||
|
**完了日**: 2025-12-09
|
||||||
|
**状態**: Lowerer/ExitLine 側は完了、JoinIR→MIR 変換バグにより E2E ブロック
|
||||||
|
|
||||||
|
### 実装サマリ
|
||||||
|
|
||||||
|
**Phase 195-impl で実装したこと**:
|
||||||
|
|
||||||
|
1. **`loop_with_if_phi_minimal.rs`** (+91行):
|
||||||
|
- multi-carrier PHI 生成を追加(sum + count の 2 キャリア対応)
|
||||||
|
- 各キャリアについて then/else 値を収集し、個別に PHI を生成
|
||||||
|
- JoinIR 上で正しい PHI 構造を出力
|
||||||
|
|
||||||
|
2. **`pattern3_with_if_phi.rs`** (+68行):
|
||||||
|
- 単一キャリア(後方互換)と複数キャリアを動的に扱うよう拡張
|
||||||
|
- exit_bindings に複数キャリアを載せる処理を追加
|
||||||
|
|
||||||
|
3. **ExitLine / LoopExitBinding / CarrierVar.join_id**:
|
||||||
|
- **変更不要!** 既存インフラをそのまま利用できた
|
||||||
|
- Phase 170-189 で整備された CarrierVar.join_id が multi-carrier を想定していた
|
||||||
|
- YAGNI 原則の正しさが証明された
|
||||||
|
|
||||||
|
### Blocker: Nested Select→Branch+Phi 変換バグ
|
||||||
|
|
||||||
|
**問題の概要**:
|
||||||
|
- JoinIR 側では正しい PHI が生成されている
|
||||||
|
- MIR 変換時に PHI inputs が undefined を参照するようになる
|
||||||
|
|
||||||
|
**具体例**:
|
||||||
|
```
|
||||||
|
JoinIR (正しい):
|
||||||
|
ValueId(20) = phi [(BasicBlockId(3), ValueId(14)), (BasicBlockId(4), ValueId(18))]
|
||||||
|
|
||||||
|
MIR (壊れている):
|
||||||
|
bb10:
|
||||||
|
%27 = phi [%28, bb8], [%32, bb9] // ← %28, %32 は undefined
|
||||||
|
```
|
||||||
|
|
||||||
|
**原因分析**:
|
||||||
|
- `joinir_block.rs` の Select 命令処理で、Nested Select(if-else が複数キャリアを持つ場合)の変換が壊れている
|
||||||
|
- Select → 3ブロック + 1 PHI の展開時に、block ID マッピングまたは ValueId マッピングが不整合
|
||||||
|
- Pattern3 の multi-carrier 対応自体は問題なく、bridge 層の既存バグ
|
||||||
|
|
||||||
|
**対応方針**:
|
||||||
|
- Phase 195 の scope からは外す(Lowerer/ExitLine の責務は完了)
|
||||||
|
- Phase 196 として Select 展開バグの調査・修正を別タスク化
|
||||||
|
|
||||||
|
### テスト状況
|
||||||
|
|
||||||
|
**後方互換テスト**:
|
||||||
|
- 単一キャリア P3 テスト(loop_if_phi.hako 等): 退行確認が必要
|
||||||
|
- Pattern1/2/4 代表テスト: 影響なし(Select 変換に依存しないパターン)
|
||||||
|
|
||||||
|
**multi-carrier E2E テスト**:
|
||||||
|
- `phase195_sum_count.hako`: JoinIR 生成は正しい、MIR 変換でブロック
|
||||||
|
|
||||||
|
### 次のステップ
|
||||||
|
|
||||||
|
**Phase 196: Select 展開/変換バグ調査&修正**(別タスク)
|
||||||
|
- `select_expansion` / `instruction_rewriter` の責務を doc に整理
|
||||||
|
- 「1 Select = 3 ブロック + 1 PHI」変換インタフェースを明文化
|
||||||
|
- block reuse / block ID マッピングの切り分け
|
||||||
|
|
||||||
|
**Phase 195 完了時点での成果**:
|
||||||
|
- P3 Lowerer は複数キャリア対応完了 ✅
|
||||||
|
- ExitLine/CarrierVar は既に対応済み(変更不要)✅
|
||||||
|
- JoinIR→MIR bridge の Select バグは別 Issue として分離 ✅
|
||||||
|
|||||||
Reference in New Issue
Block a user