<div dir="ltr">Hi Dave,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></div></blockquote></span><div><br>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.<br><br>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).<br> </div></div></div></div></blockquote><div><br></div><div>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. :)</div><div><br></div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>- Lang.</div></div></div></div></div>