LLInt is on if the target platform is a supported architecture (currently only x86, x86-64, and ARM w/Thumb2 I believe) on a platform with an ABI we understand (which I believe is normal unix-derivative cdecl)
--Oliver On Apr 18, 2012, at 4:35 AM, wingoog moon wrote: > > Thanks for anwers. > Can you please tell more about LLInt and is it turned on by default? > On Wed, Apr 18, 2012 at 12:48 PM, Filip Pizlo <[email protected]> wrote: > JavaScript is a dynamically typed language. Therefore, we cannot know for > sure what types of values may flow into an instruction at the time we compile > it. a + b may be an integer addition that produces an integer result, an > integer addition that overflows and produces a double, an addition of a > double to an integer, an addition of an integer to a double, a double > addition, a string concatenation, or an "object-to-value" conversion followed > by any of the previous. > > But the common case is typically going to be an integer addition or a double > addition. > > Therefore, the baseline JIT (which you seem to be looking at) has a fast path > for the common cases and a slow path for the uncommon ones. The slow path > almost always results in a C function call, which then does all of the magic > necessary to satisfy JS semantics. > > Similar things happen for almost all other JS instructions: there is a simple > path for the cases we have found to be common and a slow-path C function call > for the rare cases. > > The slow paths are emitted as a separate piece of out-of-line code because > that optimizes instruction cache locality for the main path, and helps a bit > with branch prediction. > > However, if you want to see how JSC actually makes JavaScript run fast, you > should probably also look at either the LLInt (which enables very fast > start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG > (which enables high throughput for longer-running code by leveraging value > profiling to avoid having to deal with JS's dynamism in most cases). The > baseline JIT is still probably important for performance, but this is > becoming less and less true as the LLInt is likely to get faster and the DFG > is likely to expand coverage to more kinds of code (DFG still cannot compile > some functions at all due to missing opcode support). > > -F > > > > On Apr 18, 2012, at 1:39 AM, wingoog moon wrote: > >> Hi! >> As I understand there are two passes to translate SFX bytecode to the native >> code(functions privateCompileMainPass() and privateCompileSlowCases()). >> So whats the purpose of privateCompileSlowCases(). Why we need slow cases >> for each bytecodeInstruction? Is it needed when arguments of instruction not >> integer or something else? >> >> Thanks for attention! >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
