<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 01/14/2015 02:56 PM, David Blaikie
wrote:<br>
</div>
<blockquote
cite="mid:CAENS6Etm0YTVTPAW47Qo0KRwHOOJ6wHcCP5NsgixzzrTqH--Pg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</div>
</div>
</blockquote>
I think Lang's response covered all the relevant points and we're
far off topic at this point. Let me know if there was something you
think Lang's comments didn't address that you'd like me to. <br>
<blockquote
cite="mid:CAENS6Etm0YTVTPAW47Qo0KRwHOOJ6wHcCP5NsgixzzrTqH--Pg@mail.gmail.com"
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 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>
</blockquote>
<br>
</body>
</html>