[LLVMdev] New JIT APIs

[David Blaikie]

On Wed, Jan 14, 2015 at 2:33 PM, David Blaikie <dblaikie at gmail.com> wrote:

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

Well, I suppose we've had a couple of register allocators banging around
for a while now (:


>
> 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/9d48332c/attachment.html>