<div dir="ltr">Awesome, thanks for the detailed response.<div><br></div><div>I did not realize that going to the assembly backend would not produce a substantial improvement.  But after you explanation, I can see the reasons.</div>

<div><br></div><div style>I&#39;ll do some more testing to see the impact.  If I see it to be worthwhile and I can fix it, I&#39;ll submit a patch, otherwise a bug.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo <span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Yes.  You can use the assembly LLInt backend without using the JIT.  That&#39;s how I was running it when I first wrote it.<div><br></div><div>I think that the code in Platform.h is being conservative, in the sense that it assumes that if ENABLE(JIT) is not set then you&#39;re compiling for a target that the LLInt wouldn&#39;t have a backend for.  This makes sense, if you think about it: ENABLE_JIT is defined to 1 if we detect that we are on a hardware/OS configuration that the JIT knows how to handle, and the LLInt has backends for strictly fewer platforms than the JIT has backends for: JIT supports x86 (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and MIPS.  In short, requiring the JIT to use LLInt assembly backends is not a strong requirement of the LLInt; it&#39;s just an artifact of Platform.h&#39;s logic.</div>
<div><br></div><div>On hardware/OS configurations where ENABLE(JIT) is set, and the LLInt is compiled to assembly, it is still possible to run with the JIT disabled. The JIT ends up being disabled at run-time in that case. We often use this for testing - you can set the JSC_useJIT environment variable to &#39;false&#39; and then you&#39;re running in a LLInt-only mode. This allows for quickly checking if a bug is due to the JITs, or not.</div>
<div><br></div><div>But I would also note that the purpose of the LLInt assembly backends is _not_ performance of the LLInt itself, but for performance of the triple-tier system as a whole.  What those assembly backends give us is the ability to run the LLInt using the same ABI that the JSC JITs use; this in turn allows us to do two things: (1) zero-cost OSR from the LLInt to the baseline JIT, and (2) perform every JS function call assuming opportunistically that the callee has been JITed; if it isn&#39;t then the machine code entrypoint that the callee reports is just the shared LLInt entrypoint.  That entrypoint, in turn, doesn&#39;t really have to do anything special - it just loads the callee from the callee stack frame, loads the bytecode pointer from the callee, and indirect-jumps into the first bytecode instruction.  We wouldn&#39;t be able to do either (1) or (2) easily with a C (or C++) interpreter. I mean, we could do it, but JIT-&gt;interpreter calls would be more expensive (because of the need to set up a C interpreter stack frame). And OSR would take more effort - it wouldn&#39;t be possible for the LLInt to just jump straight into JITed code like it does now.</div>
<div><br></div><div>In summary, I don&#39;t expect the LLInt cloop backend to be any slower than the LLInt assembly backends. Last I checked, it wasn&#39;t slower. I would assume that a decent C compiler will take the LLInt cloop code and do sufficient optimizations that it ends up generating roughly the same assembly code that the LLInt assembly backends generate. So, I wouldn&#39;t devote too much effort to switching from the cloop to the assembly backends unless you had evidence that (a) it would actually be faster on the benchmarks you care about; or (b) you wanted to take advantage of the LLInt&#39;s ability to rapidly tier-up to one of the JSC JITs. It is because of (b), not (a), that JSC&#39;s triple tier configuration uses the LLInt assembly backends instead of cloop.</div>
<div><br></div><div>But if you have reason to believe that the LLInt assembly backends will be better for your purposes then I think all it will take is hacking Platform.h appropriately. If this turns out to be hard, then you should file a bug, or even better, I would love to see a patch from you to improve the logic in Platform.h to make this use case easier.</div>
<div><br></div><div>Hope this helps!</div><div><br></div><div>-Filip</div><div><br></div><div><br></div><div> <br><div><div><div class="h5"><div>On Mar 8, 2013, at 4:59 PM, Fritz Koenig &lt;<a href="mailto:frkoenig@google.com" target="_blank">frkoenig@google.com</a>&gt; wrote:</div>
<br></div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px">LowLevelInterpreter.asm is processed to create LLIntAssembly.h for the built platform.  It appears that if there is no jitting configured[1], this will always create the C Loop.</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Is there any way of using the assembly backends to create LLIntAssembly.h when not jitting?</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">[1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not available, enable the LLInt C Loop: */</div>

</div></div></div>
_______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>