Files
hakorune/docs/private/papers/comparison.md
Selfhosting Dev 4c0e6726e3 🔧 refactor(llvm-py): Fix resolver PHI handling and add trace improvements
Changes to resolver.py:
- Improved PHI value tracking in _value_at_end_i64() (lines 268-285)
- Added trace logging for snap hits with PHI detection
- Fixed PHI placeholder reuse logic to preserve dominance
- PHI values now returned directly from snapshots when valid

Changes to llvm_builder.py:
- Fixed externcall instruction parsing (line 522: 'func' instead of 'name')
- Improved block snapshot tracing (line 439)
- Added PHI incoming metadata tracking (lines 316-376)
- Enhanced definition tracking for lifetime hints

This should help debug the string carry=0 issue in esc_dirname_smoke where
PHI values were being incorrectly coerced instead of preserved.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-09-14 16:25:21 +09:00

61 lines
2.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 論文D vs 論文G 比較
## 📊 2つの論文の違い
| 項目 | 論文DSSA/箱理論) | 論文GAI協働 |
|------|-------------------|----------------|
| **焦点** | 技術的解決策 | 協働プロセス |
| **読者** | コンパイラ実装者 | SE研究者、AI研究者 |
| **内容** | SSA実装の簡略化手法 | AI見落としと人間の発見 |
| **貢献** | 650→100行の実装改善 | 新しい協働モデル提案 |
| **理論** | 箱理論(技術) | 実装駆動型学習(方法論) |
| **データ** | コード比較、性能測定 | 相談ログ、開発履歴 |
| **結論** | シンプルさの勝利 | Everything is Experience |
## 🎯 それぞれの価値
### 論文D技術編の価値
- SSA構築に苦しむ実装者への具体的解決策
- 箱理論という新しい実装パラダイム
- 定量的な改善効果85%コード削減)
- すぐに適用可能な実践的知識
### 論文GAI協働編の価値
- AI時代の新しい開発モデル
- 人間の役割の再定義
- 実装経験の重要性の実証
- AI活用の落とし穴と対策
## 📝 相互参照
両論文は以下のように相互参照可能:
**論文Dから**
> 「この箱理論の発見に至った経緯については[論文G]を参照。AI協働開発における興味深い現象が観察された。」
**論文Gから**
> 「型情報の追加により実現された技術的改善の詳細は[論文D]を参照。650行から100行への劇的な簡略化が達成された。」
## 🤔 統合するべきか?
### 別々のメリット
- 各論文が明確な焦点を持つ
- 読者が必要な情報だけ読める
- それぞれ6-8ページの濃い内容
### 統合のデメリット
- 焦点がぼやける
- 12-15ページの長大な論文に
- 技術だけ知りたい人には冗長
## 💡 結論
**現時点では別々の論文として保持することを推奨**
理由:
1. それぞれが独立した価値を持つ
2. 異なる学会・ジャーナルに投稿可能
3. 読者層が明確に分かれる
4. 相互参照で関連性は示せる
将来的に統合版を作ることも可能だが、まずは2つの濃い論文として完成させることが重要。