107 lines
8.8 KiB
Markdown
107 lines
8.8 KiB
Markdown
|
# 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命令はそのまま残る。
|
|||
|
|
|
|||
|
|
---
|