[LLVMdev] New JIT APIs

[Philip Reames]

On 01/14/2015 02:33 PM, David Blaikie wrote:
>
>
> On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com 
> <mailto:lhames at gmail.com>> wrote:
>
>     Hi Dave,
>
>             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.
>
>
>         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.
>
>         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).
>
>
>     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. :)
>
>
> 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)
>
> 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.
As a user of the JIT, I am *very* strongly in favour of Lang's espoused 
position.

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.

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.  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.

>
> - David
>
>     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.
>
>     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.
>
>     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.
>
>     - Lang.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/8e41c052/attachment.html>