[LLVMdev] New JIT APIs

[David Blaikie]

On Wed, Jan 14, 2015 at 2:46 PM, Philip Reames <listmail at philipreames.com>
wrote:

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

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.


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

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?

- David


>
>
> - 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/38599fa4/attachment.html>