What's more, as previous mentioned, OrcJIT's layer still has no common interface and layer manger. Although it provides llvm::orc::OrcMCJITReplacement as an wrapper, the main author tends to use its own interface, this raises lots of questions and arguments on the mailing list from the debut of OrcJIT. On the other hand, OrcJIT does not use the llvm::ExecutionEngine interface. Pros of OrcJIT would be the decreasing compilation region, brings potential to add profiler for detecting hot method which is used in merely every dynamic compilation framework nowadays. OrcJIT would differ the compilation of each function until we called findSymbol. We would use CODLayer to add module by addModuleSet and invoke findSymbol to retrieve compiled function symbols. Where CODLayer is the instance of CompileOnDemandLayer and treated as the highest level class in OrcJIT.
The compilation flow would run as the order: ObjectLayer, CompileLayer, IRDumpLayer, CODLayer. Std::move(IndirectStubsMgrBuilder), InlineStubs), IRDumpLayer(CompileLayer, createDebugDumper()),ĬODLayer(IRDumpLayer, extractSingleFunction, *this->CCMgr, : TM(std::move(TM)), DL(this->TM->createDataLayout()),ĬompileLayer(ObjectLayer, orc::SimpleCompiler(*this->TM)), IndirectStubsManagerBuilder IndirectStubsMgrBuilder, For example, the lli program construct its compilation stack as below: Nevertheless, OrcJIT still lacks of central layer manager similar to llvm::PassManager and even common layer interface! In another word, we can only construct our own compilation "stack" by passing the base layer instance to the first argument of another layer constructor and non of the layer class inherit a common parent class as interface. It provides flexibilities for building your own JIT compilation flow. Layer is like LLVM's IR pass, but handles compilation procedure rather than IR. Even more, it introduced a concept called Layer. OrcJIT also build from scratch instead of building on MCJIT. As the name suggests, it lazily performs the compilation process of each functions within the module until it is used. Orc is the shorthand of on-request-compiling. There are several drawbacks on using module as compilation unit, in short, module scope is too big in comparison with method and trace, which may spend too much time on compilation procedure and increase latency. You can use the llvm::EngineBuilder class to build a llvm::ExecutionEngine, which is the main JIT interface, then you can either retrieve compiled symbols or run compiled functions directly by its rich APIs like getPointerToFunction or runFunction. MCJIT use non of strategies mentioned above, instead, it use LLVM's Module as the compilation unit. It adopted the popular MC- framework within LLVM, which is kind of LLVM's own assembler, as its backend to gain more flexibility. Which of them is better may required several academic papers to explain and the debate still goes on now.īack to LLVM, the main JIT implementation is called MCJIT. Firefox's TraceMonkey and Lua's JIT use this kind of approach. Trace-based JIT use traces, where we can treat them as a range of control flow, as the compilation units. Google's V8 Javascript engine is a well-known example. As their name suggests, method-based approach take functions or methods as minimum compilation units. Difference between them falls on the compilation scope they adopt. There are mainly two kinds of compilation strategies: method base and trace base.
#Quick note firefox Patch
More and more enhancements come up like native support for patch points and stack maps, which debut in version 3.8 as experiment features. It doesn't stop the community from working on this subsystem. Although applying LLVM on dynamic compilation has some drawbacks, for example, long running optimizations increase latencies and inadequate type system which is originally developed for static type rather than dynamic type.
However, LLVM, which is developed mainly for static type language like C/C++, also joined JIT's battlefield few years ago. JIT(Just in Time) compilation becomes more and more popular in recent years due to the rising demand on higher dynamic type language performance, Javascript and Python, to name a few.
0 kommentar(er)
