These are chat archives for Constellation/iv

24th
Feb 2014
iseki
@iseki-masaya
Feb 24 2014 11:30
詳しい説明ありがとうございます。breakerは最初からbreakerで実行されるということは、breakerでcompileに失敗することはないということですか。SpiderMonkeyでは型情報が足らない時はbaselineJITでcompileできないので、はじめはインタプリタで実行するという理解なのですが、同様の原因でbreakerでもcompileに失敗すると思うのですが...
iseki
@iseki-masaya
Feb 24 2014 11:44
3の解答についてなのですが、" top + size でこれから生成するコードの先頭ポインタ"とはbreaker_prologue関数ということですか。そして、breaker_prologue関数の実態はxbyakで生成したコードになるということですか。
Yusuke Suzuki
@Constellation
Feb 24 2014 11:51

詳しい説明ありがとうございます。breakerは最初からbreakerで実行されるということは、breakerでcompileに失敗することはないということですか。SpiderMonkeyでは型情報が足らない時はbaselineJITでcompileできないので、はじめはインタプリタで実行するという理解なのですが、同様の原因でbreakerでもcompileに失敗すると思うのですが...

はい, 失敗はないです. なぜなら型情報を profiling せずに JIT を行っているためで, 構成としては, V8 の full-codegen, JSC の baseline JIT と同じです.

3の解答についてなのですが、" top + size でこれから生成するコードの先頭ポインタ"とはbreaker_prologue関数ということですか。そして、breaker_prologue関数の実態はxbyakで生成したコードになるということですか

はい, そのとおりです.

例えば, V8 は Interpreter をもちません, full-codegen は最初に実行されて, その結果は必ず失敗しません. V8 は最初は full-codegen のはいたコードで実行し, counter が hot になると, hydrogen / lithium いわゆる crankshaft が起動します.
crankshaft は失敗します, が full-codegen は失敗しません. full-codegen が失敗すると, 実行するコードないので...
iseki
@iseki-masaya
Feb 24 2014 11:55
型情報をprofilingしないとcompileに失敗しないというのが理解できないのですが...
iseki
@iseki-masaya
Feb 24 2014 12:01
型情報が足らずに型を推論できない場合でもアセンブラの生成ができるのですか。
Yusuke Suzuki
@Constellation
Feb 24 2014 12:15
型情報を用いていないです. なので基本的に generic なコードが生成されます.
iseki
@iseki-masaya
Feb 24 2014 12:23
すみません、理解が追いつかないのですが、breakerが出力するのはアセンブラだと思うのですが、型に依存しないということはtemplateみたいに全パターンcompileするということですか?
それでも、実行時にはどのパターンで実行するか知る必要があるので型情報が必要になる気が...
genericなアセンブラというのが理解できないのですが...
Yusuke Suzuki
@Constellation
Feb 24 2014 12:30
JSVal でそのまま扱うということですー.
例えば, https://github.com/Constellation/iv/blob/master/iv/lv5/railgun/operation.h#L336 railgun::VM の BinaryAdd は JSVal を 2 つとって + を演算していますよね,
これとほとんど同じことを assembler でやってしまうという話です.
実際には静的に決定する型を簡単に解析したりもしますが, 基本的に optimize 用で, 型が確定しなかったとしても何ら問題はないです. https://github.com/Constellation/iv/blob/master/iv/lv5/breaker/compiler_arithmetic.h#L86
Yusuke Suzuki
@Constellation
Feb 24 2014 12:35
https://github.com/Constellation/iv/blob/master/iv/lv5/breaker/compiler_arithmetic.h#L130 が BINARY_ADD の時に型が全くわからなかった時の path です.
iseki
@iseki-masaya
Feb 24 2014 12:50
Int32Guardを呼ぶことでint型かcheckし、intでない場合は".ARITHMETIC_GENERIC"ラベルに飛ぶ処理になってるのですが、https://github.com/Constellation/iv/blob/master/iv/lv5/breaker/compiler.h#L2846
この".ARITHMETIC_GENERIC"の先の処理がgenericということですか。
Yusuke Suzuki
@Constellation
Feb 24 2014 12:52
はいそうです.
iseki
@iseki-masaya
Feb 24 2014 12:53
ラベルの先の処理ってどこに記述されてますか?
Yusuke Suzuki
@Constellation
Feb 24 2014 12:54
iseki
@iseki-masaya
Feb 24 2014 13:04
stubの呼び出しということは、xbyakで作り出したアセンブラではなくC++のcompilerが作り出した機械語を呼び出すということですよね。
Yusuke Suzuki
@Constellation
Feb 24 2014 13:05
はい, そうです
iseki
@iseki-masaya
Feb 24 2014 13:08
C++のcompilerが頑張ってJSValに対応する機械語を作ってくれるので、breakerでcompileが失敗することはないんですね。ただし、stub callでは複雑な機械語を読み込むことになるので、失敗する可能性のあるguardingに比べて遅くなるということですね。
Yusuke Suzuki
@Constellation
Feb 24 2014 13:08
はいそうです.
ここで, 型情報を profile して,
type guard を含めた SSA を作成し,
type guard の重複と, JSVal への boxing の削除を行い, その代わり guard が外れると breaker に deoptimization する, というのが自分が当初検討していた optimizing compiler (LLVM を用いてつくろうと考えている) 部分です
breaker で profile をとって, diagram へ OSR するというのを理想としています.
iseki
@iseki-masaya
Feb 24 2014 13:11
ようやく理解出来ました。ありがとうございます。
Yusuke Suzuki
@Constellation
Feb 24 2014 13:25
@herumi https://github.com/Constellation/iv/commit/54cea28072a382254c886087c553631b0ceab1f9 超綺麗になりました, どうもですー! mov flag 更新しないの最高ですね.
Yusuke Suzuki
@Constellation
Feb 24 2014 17:51
次, RegExp のほう超ナイーブすぎる実装だったので, ちょっとなんとかします.
  • 複数の文字の一括比較 (x64 の 64bit register を用いて, 1byte で 8文字, 2byte で(UTF-16)4文字一括で比較
    ++ SSE 使ったほうが速いのかどうかも含め検討. pcmpestri など. JS の場合, string に \0 が入る可能性があるので, pcmpistri は不可
  • 構築結果が単なる文字列の場合 (/a/ など), 正規表現エンジンでなく, 普通に検索する (simple string pattern)