LLVM勉強会でささださんたちと話したこと
LLVM勉強会の途中で笹田さんたちと話した内容です。
- さ
- ささださんたち
- み
- 私(みうら)
互換性をUPさせる方策
if $debug then def foo デバッグバージョン end else def foo リリースバージョン end end
on stack replacement
- さ
- 再コンパイルするとon stack replacement(実際にはこの言葉私は知らなかったので呼び出し元を書き換えられるかという感じで判りやすく説明してもらった)が、必要になるが、LLVMで可能だろうか
- み
- LLVMの枠内では不可能だと思う。LLVMでは最適化を可能にするためスタックフレームの構造は決まっていないから。あるいは効率を落としてコンテキスト情報を一杯残すようにすれば・・・。いずれにしてもバックエンドに手を入れる必要があると思う。X86機械語を生で使えばできると思うけど
- さ
- それは判る。でも、どのくらいの手間が掛かるのかわからない
- み
- そうですねー
型推論 vs Tracing JIT
- さ
- 型推論をがりがりやると重い。Tracing JITなんかを使ってさくっとコードを生成した方がよいのでは、またJavascriptなんかはそれが主流だよね。
- み
- 型推論重いよー。再コンパイルすると何回もやらないといけないし。でも、yarv2llvmの型推論ってPrologのユニフケーションだからPrologの高速化テクニック、もっというとネイティブコード生成ができると思う。
(後で冷静に考えたらネイティブコード生成してたら型推論できちゃうよ)
インスタンス変数のキャッシュ
- さ
- yarv2llvmのインスタンス変数のキャッシュってモジュールが出てくると破綻しない?
例えば、
module A def asd @foo end end class B include A def initilaize @foo = "B" end end class C include A def initilaize @bar = "BAR" @foo = "C" end end
- み
- うううっ、オブジェクトのレイアウトとかインスタンス変数の初期化の順番とか工夫するとうまくいくんじゃないかなー。(根拠無し)