[LLVMdev] New JIT APIs

[David Blaikie]

On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <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.

- 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/2949ea37/attachment.html>