18.02.2012, 10:51, "Filip Pizlo" <[email protected]>: > It might be possible. But you'd have to solve the following problems: > > - OSR exits at the rate of roughly one per opcode. I'm not sure if LLVM > supports them at all and if it does, I'm not sure that it can efficiently > support as many of them as our backend. We can provide meta-data for how to > reify baseline state at almost any point, which allows us to do aggressive > profile driven speculations. I don't know if LLVM would allow us to speculate > quite so aggressively. And remember, LLVM's main source languages are all > strongly typed, so speculation and OSR exit may be underexplored territory. > > - Idiom tuning. How you tune a compiler that mainly sees C style code is very > different from how you would tune a compiler for JS. This is due to (1) what > idioms a programmer is likely to use and (2) what idioms are likely to be > introduced by the frontend. If you wanted to get LLVM to compete with our > backend you'd have to probably do some tuning.
It's possible to write new JS-specific optimization passes for LLVM. > > - Code patching. We rely heavily on self modifying code. I'm not sure if LLVM > would give you quite enough flexibility to do that. If you removed code > patching, btw, you'd get destroyed on every benchmark. > > - Speed of compilation. We optimize for this with great zeal. Often we avoid > certain otherwise popular optimization strategies because we don't want to > hurt page load times. That said, you could avoid this with the right combo of > concurrent JIT and tiering. It's possible to configure which optimization passes are used, and avoid slow ones. -- Regards, Konstantin _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
