Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 17 2018 14:28
    dominiakm opened #102
  • Aug 17 2018 14:25
    dominiakm opened #101
  • Mar 24 2015 05:22

    Constellation on master

    Getter is called twice in railg… (compare)

  • Jan 30 2015 19:40
    Travis Constellation/iv (master) still failing (205)
  • Jan 30 2015 16:11

    Constellation on master

    Drop unnecessary typedef (compare)

  • Jan 30 2015 12:17
    Travis Constellation/iv (master) still failing (204)
  • Jan 30 2015 11:14
    Constellation opened #100
  • Jan 30 2015 10:46
    Travis Constellation/iv (master) still failing (203)
  • Jan 30 2015 09:09
    Travis Constellation/iv (master) still failing (202)
  • Jan 30 2015 08:15

    Constellation on master

    Fix ToNumber on Symbols (compare)

  • Jan 30 2015 08:05

    Constellation on master

    Drop JSReference, it's not used… (compare)

  • Jan 30 2015 07:53

    Constellation on master

    Drop SipHash, it's not used any… (compare)

  • Jan 18 2015 09:22
    Travis Constellation/iv (master) still failing (201)
  • Jan 18 2015 07:22

    Constellation on master

    Subsequent SPARC fix, thx id:sy… (compare)

  • Jan 18 2015 07:18
    Constellation commented #99
  • Jan 15 2015 11:39
    syoyo commented #99
  • Jan 12 2015 16:36
    Travis Constellation/iv (master) still failing (200)
  • Jan 12 2015 14:13

    Constellation on master

    Enabling a language ASM only wh… (compare)

  • Jan 10 2015 19:29
    Travis Constellation/iv (master) failed (199)
  • Jan 10 2015 17:24
    Constellation commented #99
iseki
@iseki-masaya
どうだめなんですか...
Yusuke Suzuki
@Constellation
手元でも build error が出ていて (LLVM_FIND_COMPONENTS をのぞいても, のぞかなくても), ちょっとそれを見ていますですー.
iseki
@iseki-masaya
了解です。
Yusuke Suzuki
@Constellation
直しました! これでどうですか?
iseki
@iseki-masaya
今buildしてみます。
iseki
@iseki-masaya
無事、buildできました!ありがとうございます。
Yusuke Suzuki
@Constellation
LLLVM JIT から LLVM MCJIT に切り替えました
Yusuke Suzuki
@Constellation
http://dl.acm.org/citation.cfm?id=2451512.2451541 面白そうなので読んでいます.
Yusuke Suzuki
@Constellation
これは, deoptimization については考慮してなさそうな感じを受けます.
しかし, OSR から入るやり方はこのやり方でいいかなと.
deoptimization, pyston とかどうですかね. https://github.com/dropbox/pyston deopt で grep かけると結構処理あるように見えるので何かあるかもしれないです.
http://llvm.org/devmtg/2013-11/slides/Pizlo-JavascriptJIT.pdf
WebKit JSC FTL JIT のものです. StackMap というのを使えばいける感じですかね.
Yusuke Suzuki
@Constellation
FTL JIT のために入ったっぽいですね. これは良いです.
patchpoint 使うと IC 作れるっぽいですね.
iseki
@iseki-masaya
初歩的な質問になってしまうのですが、deoptimizationは何で必要なのですか?
compile済みのコードでは扱えない型が来てしまった場合、baseline(or interpreter)まで落としてしまうという方法では何か問題があるんですか?
Yusuke Suzuki
@Constellation
guard の check が外れた時に, 全く同じ場所に method の途中から移らなければいけないからです.
例えば, map の guard を入れていて, その type に specialized した code を走っている時, guard が外れると, 以降のコードは type specialized なので実行できないです. そこでgeneric なコードのちょうど該当する部分にうまく移る (具体的には method のどまんなかからどまんなかへ) 必要があります.
このとき, optimized code は register の中身は boxing していないでしょうし (type specialized なので boxing の必要はない),
stack layout も異なります.
inlining していたとして, inline 先の code のどまんなかで guard が外れれば,
generic code に戻った時には inline した関数を, ちゃんと呼び出してここまで来たかのような stack layout にしておく必要があります.
これが deoptimization です.
iseki
@iseki-masaya
説明ありがとうございます。
メソッドコンパイルの場合でもdeoptimizationは必要になりますか?
Yusuke Suzuki
@Constellation
Method JIT (currently called as breaker compiler), の場合は, 基本的に generic path を作成して, slow path / fast path を opcode 毎に作るので, 全体として generic なコードになります.
このため, guard が入りません. というのも, ある guard を入れた後, その情報 (type specialized) をつかって型を決め打った code を吐いていないからです.
このため, register の値はすべて boxed です.
iseki
@iseki-masaya

あー、だんだんと理解できてきました。
今回のLLVMを用いて作成するJITはTracingJITであるという理解であってますか。そして、TracingJITの目的はHot loopの高速化なので以下のようなコードを高速化します。

function f(x) {
    return 1 + x;
}

//しきい値をこえるような大きなsizeのarray
var arr = [1,2,3,...,1.5];
for (var i=0; i<arr.length; ++i) {
    f(arr[i]);
}

arrは十分大きなsizeの配列で最後の要素がdoubleで後はintであるとします。ループの途中でOSRで飛んでintに最適化されたコードを生成し、以降はそのコードを使って実行します。しかし、最後にdoubleが入力されてきてguardがfailしてしまい、deoptimizationする必要がある。
この理解であってますか?

Yusuke Suzuki
@Constellation
はい, そのとおりです.
iseki
@iseki-masaya
ありがとうございます。
Yusuke Suzuki
@Constellation
Need to track this change to follow LLVM 3.5
ldc-developers/ldc#600
Yusuke Suzuki
@Constellation
Added LLVM_SYSTEM_LIBRARIES to iv/lv5/CMakeLists.txt
To make sure building lv5 with LLVM 3.5
David Kreuter
@dkreuter
Hey, I just found this chatroom. Just wanted to say that this project is awesome. I contributed three lines of code back in November, if you remember.
Yusuke Suzuki
@Constellation
@dkreuter Oh, I remember that!
Thank you for your interest. I'm now considering
implementing LLVM based optimizing compiler
Before JSC FTL JIT,
LLVM doesn't have nice interface for deoptimization (If I understand correctly),
But, now, LLVM has 2 features, stackmap & repatchpoint.
It allows MCJIT to implement
deoptimization (& type speculative JIT)
polymorphic inline cache on optimizing JIT
Currently lv5 already has baseline JIT, it has PolyIC & MonoIC.
But lv5 doesn't have optimizing JIT compiler (SSA based),
so, I think it's very nice to use LLVM MCJIT to support optimizing JIT compiler.
Yusuke Suzuki
@Constellation
Currently I think what we need are,
  1. Adding high-level SSA based IR
  2. Adding deoptimization & type speculation on it
  3. Adding lowering path from it to LLVM IR
When I'm free, I'm planning to work on them :)