[LLVMdev] New JIT APIs

[David Blaikie]

On Wed, Jan 14, 2015 at 3:30 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Dave,
>
> 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.
>>
>>
>
> It's worth noting the distinction between API/feature replacement (e.g.
> the removal of the old JIT, which was seriously disruptive) and replacement
> of MCJIT's implementation, which should be a no-op.
>
> I have thought far enough ahead to imagine replacing the implementation of
> MCJIT with MCJITReplacement. I just wanted to emphatically re-assure people
> that I'm not going to break anything by replacing MCJIT's implementation
> hastily, or without consultation.
>

OK - that sounds great/reasonable/etc.


> As for API changes though, I can't imagine LLVM without the MCJIT API any
> time in the near future. There are big clients who are happy with this API.
> It has some warts, mostly to do with it deriving from ExecutionEngine, but
> it basically makes sense given MCJIT's purpose.
>
> If, in the distant future, all clients have moved onto some new Orc-based
> API then we could consider discarding the MCJIT API, but it wouldn't buy us
> much if the implementation has already been moved over to MCJITReplacement.
>

Yeah - providing a convenience utility based on ORC for some common (even
just historic) use case, hopefully it's cheap enough (& if it isn't, we can
improve ORC until it is /really/ easy to write that wrapper & comes as
close to zero cost to keep as possible) that there's no cost to keeping it
around.


> Any new Orc-based API that supports laziness is likely use a superset of
> the components required to compose MCJITReplacement, so the only thing
> you'd save yourself is a page or two of glue code.
>
> I'd be inclined to defer any further discussion of MCJIT succession for
> now. We'll definitely follow best practices: We won't leave two redundant
> JITs in tree, but we also won't consider removing MCJIT until it is
> actually redundant, and that's not on the horizon.
>
> - Lang.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150115/6e353ba3/attachment.html>