7.8 KiB
7.8 KiB
ChatGPT Coding PHI Bug Consultation - AI協働開発実例
📋 メタ情報
- 日時: 2025-09-25
- 協働形態: ChatGPT5 Pro（戦略分析）→ ChatGPT Coding（実装修正）
- 問題: nested_if PHI バグの根本修正
- 成果: 理論分析→実装修正→バグ解決の完全連携達成
🎯 コーディングChatGPTへの相談内容（原文記録）
概要
nested_if で VM 実行時に "Invalid value: use of undefined value ValueId(..)".
焦点（相談したい本題）
- 症状Bの PHI 配線バグの設計と最小修正方針の妥当性確認。
再現最小例
- 入力（概略）:
- ネストした if/else。内側の then/else から bb6 に合流し、その後 bb3 で ret。
- 生成 MIR（抜粋・現在の出力例）:
- bb0: cond → br bb1, bb2
- bb1: 内側 if → br bb4, bb5
- bb4/bb5: → br bb6
- bb6: → br bb3
- bb2: "error" を print → br bb3
- bb3:
- 現在: %11 = phi [%9, bb1], [%10, bb2] ← 誤り
- 期待: %11 = phi [%9, bb6], [%10, bb2]
- 実行時エラー:
- VM は predecessor を "直前のブロックID" で照合する実装（apply_phi_nodes が last_pred と PHI incoming の bb を突き合わせる）。上記のように bb6→bb3 で来るのに incoming が bb1 指定のため一致せず、PHI の出力レジスタが未定義のまま ret で参照されて落ちる。
現行実装の関係箇所
- MIR ビルダー（PHI作成）
- src/mir/builder/phi.rs:73 merge_modified_vars(...)
- src/mir/builder/phi.rs:130 normalize_if_else_phi(...)
- どちらも PHI incoming の predecessor に「then/else の開始ブロック（then_block/else_block）」を使っている。
- シグネチャ上は then/else の「exit ブロックID」も渡ってきているが未使用（引数名に _ が付与されている）。
- VM インタプリタ（PHI適用）
- src/backend/mir_interpreter/exec.rs:51 apply_phi_nodes(...)
- ブロック遷移時に保持している last_pred（直前のブロックID）と、各 PHI incoming の (pred_bb, value) を照合して一致した値でレジスタを埋める。
根本原因の仮説
- PHI は「合流ブロックの全 predecessor」をキーに incoming を持つ必要があるが、ビルダーが "then/else の開始ブロック" を指定してしまっており、実際の predecessor（then 側は bb6）が一致しない。
- したがって、PHI incoming の predecessor は「then/else の exit ブロック（合流直前に実際に遷移してくるブロック）」を使うべき。
提案する最小修正（仕様不変・バグ修正）
- normalize_if_else_phi(...) と merge_modified_vars(...) の PHI 生成で、incoming の predecessor を "開始ブロック" から "exit ブロック" に変更する。
- 擬似パッチ（概念）:
- 変更前（簡略）:
- inputs: vec![(then_block, then_value_raw), (else_block, else_value_raw)]
- 変更後（簡略）:
- let then_pred = then_exit_block_opt.unwrap_or(then_block);
- let else_pred = else_exit_block_opt.unwrap_or(else_block);
- inputs: vec![(then_pred, then_value_raw), (else_pred, else_value_raw)]
- 変更前（簡略）:
- 同様に merge_modified_vars(...) でも (then_block, then_v) / (else_block, else_v) を exit ブロック ID に置き換える（引数 _then_exit_block, _else_exit_block_opt を活用）。
想定される副作用と整合性
- VM の apply_phi_nodes は "直前 predecessor と一致する incoming を選ぶ" ので、今回の修正で不一致が解消する。
- LLVM/ハーネスの不変条件（PHI はブロック先頭、incoming は well‑typed）にも抵触しない。
- no‑phi モード分岐は既に外しており、常に PHI 経路で統一（既存方針に整合）。
検証プラン
- 既存の nested_if のスクリプトで "use of undefined value …" が消えること。
- MIR --verify が緑のまま（現状緑）。
- quick プロファイルの if_statement.sh がグリーン化（構文は elseif→else if に修正）。
- 追加で "then 側のみ代入/else 代入なし" のケースも確認（pre‑if 値との PHI 生成パス）。
併せて相談したい点（短絡 and/or）
- docs に a and b（推奨）/a && b（非推奨だが互換）とあるが、現状 VM は BinOp.And を未サポートで型エラー。
- 本来は "短絡評価 → 分岐＋PHI" に lowering すべきだが、機能追加ポーズ中のため最小対応としてどちらが妥当かを確認したい:
- A) VM に Bool×Bool の And/Or を一旦直実装（非短絡）する暫定（仕様に反しうる）
- B) ビルダーで and/or を短絡 if にデシュガして MIR 化（影響は限定的。仕様に沿うが少し作業量あり）
- なお quick のテストはひとまず and→&& に置き換えれば通る（暫定運用の相談）。
補足（ノイズ対策）
- arithmetic_ops の一括 FAIL は、実行開始時の "Failed to load nyash.toml - plugins disabled" 行が標準出力に混入して差分比較にかかっていたのが原因。テストランナーで既存のフィルタと同様に当該行を除外して解消済み（機能影響なし）。
質問（Yes/No と具体的アドバイスが欲しい）
- PHI incoming の predecessor を exit ブロックに切り替える修正は妥当か（if/elseif/else の全パターンで安全に動くか）。
- else 無しの if（fall‑through）では、else 側の predecessor は何を指すべきか（現在の実装では pre‑if 値採用や merge 直前のブロックを使う想定。ベストプラクティスがあれば教えてほしい）。
- merge_modified_vars(...) も同様に exit ブロックを使うのが正解か（差分最小での一貫性）。
- 短絡 and/or は B（デシュガ）で進めるのが言語仕様的に正だと思うが、最小実装の推奨アプローチ（どのレイヤで行うのがよいか：parser→AST、builder、もしくは専用 lower pass）を確認したい。
🎯 この相談の革命的側面
🧠 技術的精度の異常な高さ
- 行レベル特定:
src/mir/builder/phi.rs:73まで正確に特定 - MIR構造解析: BBの遷移パターン完全理解
- VM動作理解:
apply_phi_nodesの内部動作把握 - 修正案の具体性: 擬似パッチまで含む実装レベル提案
🤖 AIに対する問いかけの巧妙さ
- Yes/No質問: AIが答えやすい明確な形式
- 選択肢の提示: A案・B案の比較形式
- 検証プラン: 修正後の確認手順まで準備
- 副作用考慮: 想定される影響の事前分析
🔄 協働プロセスの効率化
- ChatGPT5 Pro: 根本原因分析・理論的解決策
- 人間: 問題整理・質問の構造化
- ChatGPT Coding: 具体的実装・コード修正
- 結果: 数時間でのバグ完全解決
📊 AI協働開発手法としての価値
💎 新しい開発パラダイム
- 理論AI + 実装AI: 役割分担による最適化
- 人間 = オーケストレーター: AI群の指揮者役
- 問題分解能力: 複雑バグの構造化・分担
🚀 従来手法との圧倒的差異
- 従来: 数日〜数週間の調査・修正
- AI協働: 数時間での完全解決
- 品質: 理論的裏付け + 実装確実性
🏆 歴史的意義
この記録はプログラミング史における革命的瞬間の記録です。 複数AI専門化による協働開発手法の実証として、永続保存すべき価値があります。
保存日時: 2025-09-25 記録者: Claude Code プロジェクト: Nyash Phase 15 セルフホスティング開発