tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
4c0e6726e38b5f574f32ec829f0d9a39f54e17ec
hakorune/docs/private/papers/paper-g-ai-collaboration/implementation-history.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

3.2 KiB
Raw Blame History

実装変遷の記録

Phase 1: MIR設計（2024年11月-12月）

AI相談の流れ

  1. ChatGPT: 「最小限のIRを作りたい」

    • 27命令から13命令への削減を提案
    • BoxCall統一アーキテクチャ
    • 型情報については言及なし

  2. Claude: 「実装を手伝って」

    • MIR→LLVM変換の実装
    • 動作優先で進める
    • 型推測で対応することを暗黙の前提に

  3. Gemini: 「最適化どうする？」

    • インラインキャッシング提案
    • パフォーマンス改善
    • 型情報の必要性は議論されず

結果

// 型情報のないMIR
{"op": "binop", "kind": "+", "lhs": 10, "rhs": 20, "result": 30}
// 30が文字列か数値か不明！

Phase 2: 実装での苦闘（2025年1月）

症状

入力: print("Hello" + " World")
期待: Hello World
実際: 0

デバッグログ

[2025-01-13 14:30] 文字列連結が動かない
[2025-01-13 15:00] ハンドルが0になってる？
[2025-01-13 15:30] +演算子の解釈が違う？
[2025-01-13 16:20] あれ、型情報ないじゃん！

ChatGPT5の苦闘

  • 50分の大長考
  • Resolver 300行の複雑な実装
  • PHI配線で混乱

Phase 3: 人間の気づき（2025年1月13日）

にゃーの素朴な疑問

「なんで+が文字列連結か数値加算か分からないの？」 「最初から型書いとけばよくない？」 「他の言語はどうしてるの？」

発見のプロセス

  1. 実装の痛み → なぜ？
  2. 型推測の複雑さ → 無駄では？
  3. 他言語の調査 → みんな型情報持ってる！
  4. 結論 → MIRに型情報が必要

Phase 4: 解決策の実装

Before（型推測地獄）

# 300行のResolver
if is_stringish(lhs) or is_stringish(rhs):
    # 複雑な推測ロジック...

After（型情報明示）

{"op": "binop", "kind": "+", "lhs": 10, "rhs": 20, "result": 30,
 "dst_type": {"kind": "handle", "box_type": "StringBox"}}

Phase 5: PHI生成の重複発見（2025年1月14日）

問題の発覚

にゃー：「なんで文字列が0になるの？」 調査結果：PHI生成が2箇所で行われていた！

  1. Builder側: JSONからプレースホルダ生成
  2. Resolver側: 必要時にloc_i64_*を生成

複雑性の段階的侵入

初期: シンプルなPHI変換
↓ forward reference問題
↓ プレースホルダ導入
↓ Resolverも独自にPHI生成
↓ 気づいたら2つのPHI生成器！

にゃーの提案

「Resolverで統一したら？」 → Gemini「美しいけど大変」 → ChatGPT「やります！」

教訓

  1. AIの盲点

    • 「最小化」に夢中で基本を忘れる
    • 実装の苦痛を経験できない
    • 部分最適化の罠
    • 複雑性の段階的侵入に気づかない

  2. 人間の強み

    • 痛みから学ぶ
    • 「普通こうでしょ」という直感
    • 全体を俯瞰する力
    • 「なんで2つあるの？」という素朴な疑問

  3. 協働の価値

    • AIが理論、人間が実践
    • 相補的な関係
    • 失敗から学ぶプロセス
    • 人間の疑問がアーキテクチャ改善を促す