docs: Create AI-assisted compiler development paper structure
Added paper-g-ai-assisted-compiler folder documenting: - Week-long LLVM backend development with AI assistance - Key insights from PHI/SSA struggles to Resolver API solution - Development log capturing the chaotic reality - Abstract in both English and Japanese Key quote: 'I don't remember anymore' - capturing the authentic experience of intensive AI-assisted development where the process itself becomes the research data. This represents potentially the first fully documented case of building a compiler backend primarily through AI assistance.
This commit is contained in:
Selfhosting Dev
68
docs/private/papers/paper-g-ai-assisted-compiler/README.md
Normal file
68
docs/private/papers/paper-g-ai-assisted-compiler/README.md
Normal file
@ -0,0 +1,68 @@
|
||||
# AI-Assisted Compiler Development: The Nyash LLVM Journey
|
||||
|
||||
## 📚 論文概要
|
||||
本論文は、ChatGPT/Claude/Geminiを活用してゼロからコンパイラ（Nyash）をLLVM層まで構築した、世界初？のAI主導コンパイラ開発の完全記録です。
|
||||
|
||||
## 🎯 論文の切り口（ハイブリッドアプローチ）
|
||||
|
||||
### 1. **技術的貢献**
|
||||
- MIR14: 27→13→14命令への進化
|
||||
- Box理論: Everything is Boxの設計哲学
|
||||
- LoopForm: PHI集中化による制御フロー正規化
|
||||
- Sealed SSA: 支配関係の構造的保証
|
||||
|
||||
### 2. **方法論的貢献**
|
||||
- AI支援開発プロセスの実態記録
|
||||
- 人間×AIの役割分担と共進化
|
||||
- 失敗と解決の繰り返しから学ぶ知見
|
||||
- Python llvmliteハーネスへの方針転換
|
||||
|
||||
## 📅 開発タイムライン（1週間以上の激闘）
|
||||
|
||||
```
|
||||
Day 1: 「PHI簡単だにゃ！」→ 現実の厳しさを知る
|
||||
Day 2-3: PHI欠落、支配関係違反との戦い
|
||||
Day 4: ChatGPT 8分調査「Investigating the builder issue」
|
||||
Day 5: Python llvmlite導入決断
|
||||
Day 6: LoopForm最終手段投入
|
||||
Day 7+: Resolver API統一、設計のブレを修正
|
||||
```
|
||||
|
||||
## 🔍 主要な転換点
|
||||
|
||||
1. **PHI配線問題の発覚**
|
||||
- 「PHINode should have one entry for each predecessor」
|
||||
- emit側での配線 vs to側での需要駆動
|
||||
|
||||
2. **支配関係違反との長い戦い**
|
||||
- 「Instruction does not dominate all uses!」
|
||||
- 値解決の分散が根本原因と判明
|
||||
|
||||
3. **LoopForm導入**
|
||||
- 既存問題を顕在化させた構造
|
||||
- 「すべてをループのスコープにする」シンプルな理念
|
||||
|
||||
4. **Resolver API設計**
|
||||
- すべての値解決を統一的に扱う
|
||||
- 局所化→型正規化→キャッシュの自動化
|
||||
|
||||
## 📝 論文構成（案）
|
||||
|
||||
1. **序論**: AI時代のコンパイラ開発
|
||||
2. **背景**: 既存コンパイラの複雑性とNyashの設計思想
|
||||
3. **技術編**: MIR14, Box理論, LoopForm, Sealed SSA
|
||||
4. **開発編**: AI対話プロセスと実装の実態
|
||||
5. **評価編**: LLVM層完成の証明と性能評価
|
||||
6. **考察編**: AI×人間の協調開発の可能性と限界
|
||||
7. **結論**: 新しいコンパイラ開発手法の提案
|
||||
|
||||
## 🎉 成果物
|
||||
- 動作するLLVMバックエンド
|
||||
- 27→14命令の極限的IR削減
|
||||
- AI支援開発の実践的知見
|
||||
- 「簡単最高」哲学の実証
|
||||
|
||||
## 📌 注記
|
||||
- 完全な再現は困難（「もう覚えてないにゃー」）
|
||||
- しかし、プロセスの記録として価値がある
|
||||
- 混沌とした開発過程自体が研究データ
|
||||
25
docs/private/papers/paper-g-ai-assisted-compiler/abstract.md
Normal file
25
docs/private/papers/paper-g-ai-assisted-compiler/abstract.md
Normal file
@ -0,0 +1,25 @@
|
||||
# Abstract
|
||||
|
||||
## AI-Assisted Compiler Development: Building Nyash LLVM Backend with ChatGPT and Claude
|
||||
|
||||
We present the first documented case of building a compiler's LLVM backend through intensive AI assistance over a week-long development period. The Nyash programming language, based on the "Everything is Box" philosophy, achieves a minimalist intermediate representation (MIR14) with just 14 instructions, evolved from an initial 27 through aggressive reduction and pragmatic restoration.
|
||||
|
||||
Our development process involved hundreds of AI interactions, with ChatGPT providing deep architectural analysis (including an 8-minute investigation into PHI node issues) and Claude offering continuous implementation support. Key technical contributions include: (1) MIR14 design achieving 27→13→14 instruction evolution, (2) LoopForm IR for control flow normalization, (3) Sealed SSA with Resolver API for unified value resolution, and (4) BuilderCursor for structural terminator safety.
|
||||
|
||||
The project faced and overcame significant challenges including PHI wiring complexity, dominance violations, and type system confusion between i64 handles and i8* pointers. A critical insight emerged when LoopForm, initially blamed for introducing problems, actually exposed pre-existing design flaws in value resolution and type conversion placement.
|
||||
|
||||
We document the pragmatic decision to introduce Python llvmlite as a verification harness when Rust/inkwell complexity became a bottleneck, demonstrating that "simple is best" - a core Nyash philosophy. The development logs, though incomplete ("I don't remember anymore"), provide valuable insights into the chaotic reality of AI-assisted development.
|
||||
|
||||
This work demonstrates that AI can successfully assist in building complex systems like compilers, but human design judgment remains essential. The co-evolution of human design decisions and AI implementation represents a new paradigm in software development, with implications for future compiler construction and computer science education.
|
||||
|
||||
## 日本語要旨
|
||||
|
||||
ChatGPTとClaudeを活用し、1週間以上の開発期間でLLVMバックエンドを構築した世界初の完全記録を報告する。「Everything is Box」哲学に基づくNyashプログラミング言語は、27命令から13命令への積極的削減と実用的な1命令復活により、わずか14命令の極限的中間表現（MIR14）を実現した。
|
||||
|
||||
数百回のAI対話を通じた開発では、ChatGPTがPHIノード問題の8分間にわたる深い調査を含むアーキテクチャ分析を提供し、Claudeが継続的な実装支援を行った。主要な技術的貢献として、(1) 27→13→14命令進化を遂げたMIR14設計、(2) 制御フロー正規化のためのLoopForm IR、(3) 統一的値解決のためのResolver API付きSealed SSA、(4) 構造的終端安全性のためのBuilderCursorが挙げられる。
|
||||
|
||||
開発過程では、PHI配線の複雑性、支配関係違反、i64ハンドルとi8*ポインタ間の型システム混乱など、重大な課題に直面した。当初LoopFormが問題の原因と誤解されたが、実際には既存の値解決と型変換配置の設計欠陥を顕在化させただけという重要な洞察を得た。
|
||||
|
||||
Rust/inkwellの複雑性がボトルネックとなった際、検証ハーネスとしてPython llvmliteを導入する実用的判断を下した。これは「簡単最高」というNyashの核心哲学の実証でもある。開発ログは不完全（「もう覚えてないにゃー」）ながらも、AI支援開発の混沌とした現実への貴重な洞察を提供する。
|
||||
|
||||
本研究は、コンパイラのような複雑なシステム構築においてもAI支援が有効であることを実証したが、人間の設計判断は依然として不可欠である。人間の設計決定とAI実装の共進化は、ソフトウェア開発の新しいパラダイムを示し、将来のコンパイラ構築と計算機科学教育に示唆を与える。
|
||||
@ -0,0 +1,74 @@
|
||||
# 開発ログ: AI支援によるLLVM層構築の記録
|
||||
|
||||
## 🔥 主要な問題と解決の軌跡
|
||||
|
||||
### 1. PHI配線問題（初期）
|
||||
```
|
||||
エラー: PHINode should have one entry for each predecessor
|
||||
原因: emit側とto側での二重配線、責務の曖昧さ
|
||||
解決: Sealed SSAによる需要駆動型配線への統一
|
||||
```
|
||||
|
||||
### 2. 支配関係違反（中期）
|
||||
```
|
||||
エラー: Instruction does not dominate all uses!
|
||||
症状: Main.node_json/3, Main.esc_json/1での頻発
|
||||
原因: 値解決が分散、型変換の場所が不統一
|
||||
解決: Resolver APIによる統一的値解決
|
||||
```
|
||||
|
||||
### 3. 型システムの混乱
|
||||
```
|
||||
問題: i64 handle vs i8* pointer の混在
|
||||
症状: console.log(handle) → 不正メモリアクセス
|
||||
解決: nyash.console.log_handle(i64)への変更
|
||||
```
|
||||
|
||||
### 4. LoopForm導入（後期）
|
||||
```
|
||||
動機: 既存手法で解決困難、最終手段として投入
|
||||
効果: 問題を顕在化、PHI集中化への道筋
|
||||
誤解: 「LoopForm特有の問題」→ 実は既存問題の露呈
|
||||
```
|
||||
|
||||
## 💡 重要な設計決定
|
||||
|
||||
### Resolver API
|
||||
```rust
|
||||
// Before: 分散した値解決
|
||||
let val = vmap.get(&value_id) // どの時点の値？
|
||||
|
||||
// After: 統一API
|
||||
let val = resolver.resolve_i64(value_id, current_bb)
|
||||
```
|
||||
|
||||
### BuilderCursor
|
||||
- post-terminator挿入を構造的に防止
|
||||
- 全lowering経路に適用完了
|
||||
|
||||
### Python llvmlite導入
|
||||
- 「簡単最高」の精神
|
||||
- Rust/inkwellの複雑性からの解放
|
||||
- 検証ハーネスとしての活用
|
||||
|
||||
## 🤖 AI活用の実態
|
||||
|
||||
### ChatGPT
|
||||
- 8分の深い調査「Investigating the builder issue」
|
||||
- 設計のブレを的確に指摘
|
||||
- Resolver APIの提案
|
||||
|
||||
### Claude
|
||||
- 日々の実装支援
|
||||
- エラー解析と解決策提示
|
||||
- ドキュメント作成
|
||||
|
||||
### Gemini
|
||||
- アーキテクチャ相談
|
||||
- セルフホスティング戦略議論
|
||||
|
||||
## 📊 成果
|
||||
- MIR14（14命令）でのLLVM層実装
|
||||
- LoopForm実験的実装
|
||||
- Resolver API設計・実装
|
||||
- BuilderCursor全域適用
|
||||
@ -0,0 +1,65 @@
|
||||
# Key Insights: AI支援コンパイラ開発から得られた知見
|
||||
|
||||
## 🎯 技術的知見
|
||||
|
||||
### 1. **最小化の限界**
|
||||
- MIR 27→13→14命令への進化
|
||||
- 「もうこれ以上簡単にできないにゃー」
|
||||
- UnaryOp復活の実用的判断
|
||||
|
||||
### 2. **LoopFormの真実**
|
||||
- 問題の原因ではなく、問題を顕在化させた構造
|
||||
- 「すべてをループのスコープにする」シンプルな理念
|
||||
- 既存設計の弱点を浮き彫りに
|
||||
|
||||
### 3. **設計のブレと修正**
|
||||
- 値解決の分散 → Resolver APIで統一
|
||||
- 型変換の不統一 → 局所化の徹底
|
||||
- PHI配線の曖昧さ → Sealed SSAで解決
|
||||
|
||||
## 🤝 AI×人間の協調
|
||||
|
||||
### 成功パターン
|
||||
1. **人間**: 設計原則の提示（Box理論、LoopForm）
|
||||
2. **AI**: 具体的なRustコード実装
|
||||
3. **人間**: エラー報告と方向修正
|
||||
4. **AI**: 詳細な調査と解決策提案
|
||||
|
||||
### 失敗パターン
|
||||
- AIの提案を鵜呑み → 設計の一貫性崩壊
|
||||
- 問題の本質を見誤る → 「LoopForm特有」という誤解
|
||||
- 最適化の誘惑 → 支配関係違反
|
||||
|
||||
## 💡 方法論的発見
|
||||
|
||||
### 1. **「遅くてOK」の価値**
|
||||
- 正しさ優先、最適化は後回し
|
||||
- 冗長な局所化を許容
|
||||
- まず動くものを作る
|
||||
|
||||
### 2. **Python移行の合理性**
|
||||
- 「恥じゃない、実用的な解決策」
|
||||
- llvmliteで100行 vs Rust/inkwellで数千行
|
||||
- デバッグの容易さ
|
||||
|
||||
### 3. **記録の重要性**
|
||||
- 「もう覚えてないにゃー」でも大丈夫
|
||||
- Gitコミット、CURRENT_TASK.mdが証拠
|
||||
- 混沌も含めて研究データ
|
||||
|
||||
## 🚀 将来への示唆
|
||||
|
||||
### AI支援開発の可能性
|
||||
- コンパイラのような複雑なソフトウェアも構築可能
|
||||
- ただし、人間の設計判断は不可欠
|
||||
- 失敗と修正のサイクルが重要
|
||||
|
||||
### 新しい開発スタイル
|
||||
- 対話的開発（人間×AI）
|
||||
- 高速プロトタイピング
|
||||
- 言語の壁を越える（Python/Rust混在）
|
||||
|
||||
### 教育への影響
|
||||
- AIとの協調作業スキルが必須に
|
||||
- 設計原則の理解がより重要に
|
||||
- 実装詳細よりアーキテクチャ
|
||||
Reference in New Issue
Block a user