# GeminiとのNyashコンパイラ設計に関する議論のまとめ

**日付:** 2025年9月10日水曜日

## 1. Nyash LLVM PHIノード問題（SSAバグ）の分析

### 問題の特定
*   **エラーメッセージ:** `phi incoming value missing: in_vid=ValueId(29)`
*   **具体的な状況:** PHIノードが `%29` を `bb62` から来ると期待しているが、実際には `%29` は `bb66` で定義されており、制御フローは `bb66 -> bb62 -> bb60` となっている。PHIは `%29` を `bb66` から期待すべき。
*   **根本原因:** SSA構築ロジックが、PHIノードの入力における `BasicBlockId` を誤って決定している。特に、ループバックエッジに中間ジャンプブロック（`bb62` のような）が存在する場合に発生。

### 修正の方向性
*   **場所:** 主に `src/mir/builder.rs` および `src/mir/loop_builder.rs`。
*   **内容:** `SsaBuilder` の値伝播ロジックを強化し、中間ブロックを介しても値が実際にライブアウトする `BasicBlockId` を正しく識別できるようにする。

## 2. 参照カウントGCの導入検討

### ユーザーの提案
*   Nyashの現在のライフサイクル（スコープを抜けると解放、`fini` で解放、`weak` は無視）に加えて、「参照カウンターが2以上なら、スコープを抜けたり `fini` を呼ばれても解放しない」というルールを導入。
*   GCは開発/テスト用であり、本番ではオフにできる。重くなっても許容。

### 分析とアドバイス
*   **戦略:** 参照カウント（RC）GCの導入。
*   **メリット:** 即時解放、予測可能な一時停止。
*   **デメリット:** オーバーヘッド、参照サイクル（`weak` 参照で対応必要）。
*   **実装アプローチ:**
    *   **シンプルに開始:** まずはコアの `retain`（インクリメント）と `release`（デクリメントし、ゼロなら解放）ロジックに集中し、初期段階ではサイクルコレクタは実装しない。
    *   **コンパイル時機能:** `#[cfg(feature = "gc")]` のようなコンパイル時フラグでGCの有効/無効を切り替える。これにより、GCオフ時にはランタイムオーバーヘッドがゼロになる。
    *   **`Fini` の役割:** GC有効時は参照カウントをデクリメントする役割に。
    *   **`Weak` 参照:** 参照カウントを増やさない参照として実装し、サイクルを断ち切る手段として活用。
    *   **LLVM実装:** 各Boxに参照カウントフィールドを追加し、`nyash_box_retain`、`nyash_box_release` などのランタイムヘルパー関数を `nyrt` に実装。コンパイラバックエンドがこれらのヘルパー関数への呼び出しを生成する。
*   **Safepoint:** 純粋なRCでは不要だが、将来的にサイクル回収のためのトレーシングGCを導入する場合には必要となる。

## 3. プラグイン設定 (`nyash.toml` vs `nyash_box.toml`)

### 状況
*   `nyash.toml` は中央レジストリとして機能し、`[libraries]` セクションでプラグインの詳細を定義。
*   `nyash_box.toml` は各プラグインディレクトリ内に存在し、プラグインごとの詳細な仕様を記述。

### 分析
*   **重複:** `nyash.toml` に一部のプラグイン定義が重複しているように見えるが、これは「新スタイル（`[plugins]` セクションと `nyash_box.toml`）への移行期間における後方互換性のため」である。
*   **役割:** `nyash.toml` は中央マニフェストとタイプIDレジストリ、`nyash_box.toml` は各プラグインの詳細な仕様書として機能する。`nyash_box.toml` は実際にプラグインロード時に優先的に参照され、使用されている。

## 4. MIR13の未実装命令

### 3つの命令の実装戦略
1.  **Safepoint:**
    *   **実装:** 現時点ではno-op。将来のGC拡張ポイントとして枠を確保。
    *   **評価:** 非常に実用的で、将来を見据えたアプローチ。
2.  **TypeOp:**
    *   **実装:** `Check` は既存の `nyash_handle_get_type_id` を活用して型IDを比較。`Cast` は当面パススルーで、将来的にBoxCall経由で実装。
    *   **評価:** 概ね良好だが、`MirType` から `type_id` へのマッピングの正確性と一貫性を確保する必要がある。
3.  **Barrier:**
    *   **実装:** LLVMの `llvm.memory.barrier` intrinsic を使用し、`Acquire`（Read）と `Release`（Write）セマンティクスを実装。
    *   **評価:** 良好だが、より現代的で正確なメモリ順序付けのために `llvm.fence` intrinsic の使用を検討すべき。

## 5. GitHub Copilot / Codex の機能

### ユーザーの主張と確認
*   **主張:** GitHub CopilotはIssueに書くと直接ソースコードを編集してくれる。
*   **確認:** ユーザーの主張は**正しい**。GitHub Copilotは、IssueをCopilotに割り当てることで、新しいブランチを作成し、コード変更を含むプルリクエストを自律的に生成する機能を持つ。
*   **補足:** 最終的なコードの統合には、人間によるレビューと承認が必須。`chatgpt.com/codex` は基盤となるAIモデルに関する情報であり、直接サービスではない。

## 6. LoopForm（MIR13の次世代IR）

### 概念
*   **目的:** 制御フロー（ループ、分岐、関数、スコープ、ジェネレータ、async）を「Loop=反復の箱」という概念に統一し、簡素化するための**中間正規形**。
*   **哲学:** 「制御を値として扱う（Signal）」という「LifeBox Model」の一部。
*   **利点:** フロントエンドのLoweringの一様化、CFG合流点の標準化、PHI最適化の簡素化。
*   **MIR13との関係:** MIR13（Core-13）の**上位層**であり、最終的にはCore-13に**再Lowering（逆Lowering）**可能。

### 4つの命令
1.  **`loop.begin`:** ループ/構造のエントリポイント、PHIの合流点。
2.  **`loop.iter`:** イテレーション/パスのエントリ、Signalディスパッチ。
3.  **`loop.branch`:** 条件付きディスパッチ、制御フロー決定。
4.  **`loop.end`:** ループ/構造の終了点、制御シグナルを運ぶ。
*   **評価:** AIが考案したこれらの命令は、制御フローを統一するための非常に堅牢で最小限のセットであり、よく考えられている。

### 「Boxがそのままループ」哲学
*   **アイデア:** Boxがフィールド、メソッド、`fini` を持ち、そこにループの条件式をメソッドとして追加すれば、Box自体がループになるという究極の「Everything is Box」の具現化。
*   **利点:** 究極の統一性、メタプログラミングの可能性、最適化の機会、概念的な優雅さ。
*   **課題:** パフォーマンスオーバーヘッド、Loweringの複雑さ、デバッグ。

### 実装順序
1.  **フェーズ0（準備）:** MIR13の安定化、SSAバグ修正、堅牢なMIR検証、MIRダンプツールの実装。
2.  **フェーズ1（コア変換）:** LoopForm IRの定義、高レベル構文からLoopFormへのLowering、LoopFormからCore-13への逆Lowering（安全のためデフォルト有効）。
3.  **フェーズ2（検証と最適化）:** LoopForm検証パス、基本的なLoopForm最適化。
4.  **フェーズ3（高度な機能）:** LifeBox Model統合、高度なLoopForm最適化、LoopFormからの直接LLVMバックエンド（将来）。
*   **原則:** 安全性、可逆性、段階的導入を常に維持。

### MIR出力ツール
*   **必要性:** コンパイラ開発におけるデバッグ、理解、最適化開発に不可欠。
*   **提案機能:**
    *   人間が読めるテキスト形式（SSA、基本ブロック、制御フロー、型情報）。
    *   Graphviz DOT形式（CFG可視化）。
    *   特定のコンパイラフェーズでのMIRダンプ。
    *   MIR差分ツール。
    *   インタラクティブMIRビューア。
    *   MIR検証/バリデーション。
    *   MIR固有のアノテーション（`@mir_dump`, `@mir_assert`）。

### 「単純なループ」ヒント
*   **アイデア:** MIR出力時（または最適化前）に「これはただのループ」というヒントを与えることで、オプティマイザが `LoopBox` を従来のループとして扱い、積極的な最適化（インライン化など）を適用できるようにする。
*   **実装:** ヒントは `LoopForm` 構造に付加され、オプティマイザが `BoxCall` を含む `LoopForm` を「見通す」ことを可能にする。`BoxCall` などの既存MIR命令はそのまま残る。

---