[LLVMdev] New JIT APIs

[Lang Hames]

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.

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.
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/20150114/23d09eab/attachment.html>