<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 14, 2015 at 2:46 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></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"><span class="">
    <br>
    <div>On 01/14/2015 02:33 PM, David Blaikie
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Jan 14, 2015 at 2:22 PM, Lang
            Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">Hi Dave,
                <div><br>
                  <div class="gmail_extra">
                    <div class="gmail_quote"><span>
                        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
                          <div dir="ltr">
                            <div class="gmail_extra">
                              <div class="gmail_quote"><span>
                                  <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
                                    <div dir="ltr">
                                      <div>
                                        <div class="gmail_extra">
                                          <div class="gmail_quote">
                                            <div>To confirm - I have no
                                              plans to remove MCJIT. I
                                              don't want to change any
                                              behavior for existing
                                              clients. The new stuff is
                                              opt-in.</div>
                                          </div>
                                        </div>
                                      </div>
                                    </div>
                                  </blockquote>
                                </span>
                                <div><br>
                                  Why not? We did work to remove the
                                  legacy JIT in favor of MCJIT for the
                                  usual reasons (less code/maintenance
                                  burden/etc) - it'd seem unfortunate to
                                  then go back to maintaining two JITs
                                  again.<br>
                                  <br>
                                  You mention the intent to provide a
                                  superset of MCJIT's behavior, at which
                                  point it seems it'd be preferable to
                                  kill of MCJIT in favor of ORC (heck,
                                  we killed of the legacy JIT before
                                  MCJIT had feature parity).<br>
                                   </div>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                      </span>
                      <div>Not having plans at the moment doesn't
                        preclude making plans in the future, it's just
                        premature to think about replacing MCJIT when
                        the "replacement" hasn't even been submitted to
                        llvm-commits yet. :)</div>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
              Not necessarily - it doesn't seem unreasonable to make a
              plan to ensure we don't end up with duplicate
              functionality to debug/test/fix indefinitely before adding
              the duplicate. Seems to be common in the project to make
              replacements, introduce them as an alternative but with an
              explicit goal/plan from the start that this is not a
              perpetual state. (for example, Chandler's pass manager
              work and I think most of the bits that Chandler's
              rewritten (shuffling, inlining, etc) were this way - maybe
              there are counterexamples where similar/duplicate
              functionality was introduced without such a goal, but none
              come to my mind)<br>
              <br>
              But I dunno, maybe other people find that to be an OK
              state of affairs, I'm not a code owner/authority in
              much/any of this.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    As a user of the JIT, I am *very* strongly in favour of Lang's
    espoused position.  <br>
    <br>
    p.s. I don't think we know what the "right" interface is for the JIT
    yet.  Until we do, having multiple interfaces (with a single shared
    implementation, based on the rest of LLVM) seems entirely reasonable
    and appropriate.  <br>
    <br>
    p.p.s. If Lang was proposing the replacement of MCJIT - he's not! -
    the review barrier would be far far higher.  He'd have to satisfy
    all existing - well, all vocal - users of the old interface that his
    new one met their needs.</div></blockquote><div><br>Not necessarily - It could simply be the stated plan (& he has stated it) to reach feature parity. At that point it seems it'd be hard to justify keeping both around when one has a superset of features of the other.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">  This would be a much slower process and we
    want to let things evolve more quickly than that.  We *don't* want
    to be looking at an old-JIT retirement v2.  That took literally
    years and blocked a lot of useful work on the JIT infrastructure.  <br></div></blockquote><div><br>Not sure I follow quite why the old JIT retirement was a blocker, but introducing a new JIT API with the intention to maintain both would block less work. Could you describe this in more detail?<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
              - David<br>
               </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div>The bar for transitioning is higher now, since
                      MCJIT has more substantial clients than the legacy
                      JIT had. The impetus for transitioning is also
                      lower: The legacy JIT required a lot of custom
                      infrastructure to be kept around. MCJIT is much
                      more lightweight, and shares most of its
                      foundation (RuntimeDyld) with Orc.<br>
                    </div>
                    <div><br>
                    </div>
                    <div>
                      <div>If MCJITReplacement reaches full feature and
                        performance parity with MCJIT (which I do
                        actually want to see), and the transition can be
                        done either transparently (by having
                        ExecutionEngineBuilder return an
                        MCJITReplacement instead of an MCJIT), or in a
                        manual way that all clients are happy to buy
                        into, then I'd be ok with deprecating and
                        eventually removing MCJIT. That's a discussion
                        for the future though.</div>
                    </div>
                    <div><br>
                    </div>
                    <div>So clients should rest easy: We just went
                      through a difficult transition from the legacy
                      JIT, and I don't want to put you through that
                      again any time soon.</div>
                    <span><font color="#888888">
                        <div><br>
                        </div>
                        <div>- Lang.</div>
                      </font></span></div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </span></div>

</blockquote></div><br></div></div>