[PATCH] D16188: LLVMRunStaticConstructors can be called before object is finalized, #24028

Lang Hames via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 16 10:44:45 PST 2016


Hi David,

>  ORC in general appears to be a bunch of classes helping you build a JIT.

That sums it up perfectly.

OrcMCJITReplacement is built with ORC classes, and aims to exactly
reproduce MCJIT's behaviour. It's intended as both a proof-of-concept and,
if we decide we're going to deprecate the MCJIT code, an upgrade path for
people who want to stick with MCJIT's behaviour and the ExecutionEngine
interface. We haven't added support for OrcMCJITReplacement to the C API
yet, but I expect we will in the future.

OrcCBindingsStack is, as you guessed, a new JIT implementation that is also
built with ORC components. Since we can't easily/efficiently express the
combination of ORC components in C, the intent is to build a stack with
"the lot", and design a C interface that allows the various pieces to be
accessed or disabled. I'm deliberately not going for 100% compatibility
with MCJIT's behaviour in OrcCBindingsStack, but I think it should come
close enough for 99% of MCJIT users. There is no common interface for all
ORC based JITs, but this is the only one that will be in-tree (apart from
the MCJIT replacement), so I think that's moot. It might be nice to have a
common interface between the OrcCBindingsStack and the interpreter, but I
expect that interface would be very limited.

As I mentioned - there's no nice way to express the combination of ORC
components that is possible in C++ in other languages. My aim is just to
provide all the functionality that users need within the OrcCBindingsStack,
then expose that classes interface as directly as possible.

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160116/bf39a051/attachment.html>


More information about the llvm-commits mailing list