Hello,<div><br></div><div>LLINT C Loop implementation is a pure JS interpretation mode, so you can&#39;t enable along with JIT. But LLINT with assembly back-end is intended to have both JIT(baseline &amp; DFG) and interpreter mode simultaneously. The main goal of LLINT assembly backend is for JIT emulation, so that code running in JIT can easily fallback(vice versa) to interpreter mode with less or no cost and also to have a triple tier virtual machine.</div>
<div><br></div><div>PSB, &quot;Filip Pizlo&quot; explained about this very nicely in the current email thread :) </div><div><br></div><div>Regards,</div><div>Arun</div><div><br><div class="gmail_quote">On 13 March 2013 23:35, Gabor Rapcsanyi <span dir="ltr">&lt;<a href="mailto:rgabor@inf.u-szeged.hu" target="_blank">rgabor@inf.u-szeged.hu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div><tt>Hello!</tt><tt><br>
      </tt><tt><br>
      </tt><tt>I tried to compile JSC with LLInt CLoop backend and JIT
        but it didn&#39;t work for me. I tried it on Mac and Linux as well.</tt><tt><br>
      </tt><tt>When I looked into it a little I saw some strange guards
        like this:</tt><tt><br>
      </tt><tt><br>
      </tt><tt>Source/JavaScriptCore/llint/LLIntOpcode.h</tt><tt><br>
      </tt><tt><br>
      </tt><tt>#if ENABLE(LLINT_C_LOOP)</tt><tt><br>
      </tt><tt><br>
      </tt><tt>#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \</tt><tt><br>
      </tt><tt>    macro(getHostCallReturnValue, 1) \</tt><tt><br>
      </tt><tt>    macro(ctiOpThrowNotCaught, 1)</tt><tt><br>
      </tt><tt><br>
      </tt><tt>#else // !ENABLE(LLINT_C_LOOP)</tt><tt><br>
      </tt><tt><br>
      </tt><tt>#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \</tt><tt><br>
      </tt><tt>    // Nothing to do here. Use the JIT impl instead.</tt><tt><br>
      </tt><tt><br>
      </tt><tt>#endif // !ENABLE(LLINT_C_LOOP)</tt><tt><br>
      </tt><tt><br>
      </tt><tt><br>
      </tt><tt>It seems if we have CLoop we don&#39;t have JIT.</tt><tt><br>
      </tt><tt>So is this configuration supported anyway or we just want
        to use CLoop backend if we don&#39;t have JIT support?</tt><tt><br>
      </tt><tt><br>
      </tt><tt>Regards,</tt><tt><br>
      </tt><tt>  -Gabor</tt><tt><br>
      </tt><br>
      <br>
    </div><div><div class="h5">
    <blockquote type="cite">
      <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>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>
                      <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>
                        <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>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
webkit-dev mailing list
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><b><font size="4" face="arial, helvetica, sans-serif">Arunprasad Rajkumar</font></b></div><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,&#39;Nimbus Sans L&#39;,sans-serif;font-size:13px;line-height:15px;background-color:rgb(255,255,255)"><a href="http://in.linkedin.com/in/ararunprasad" title="View public profile" name="SafeHtmlFilter_SafeHtmlFilter_webProfileURL" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:initial;outline-width:initial;outline-style:none;outline-color:initial;font-style:inherit;font-size:13px;font-family:inherit;vertical-align:baseline;text-decoration:none;color:rgb(0,102,153)" target="_blank">http://in.linkedin.com/in/ararunprasad</a></span></div>

</div>