annulen at yandex.ru
Sat Feb 18 01:39:00 PST 2012
18.02.2012, 10:51, "Filip Pizlo" <fpizlo at apple.com>:
> 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.
More information about the webkit-dev