BuildingAJIT3.rst 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191
  1. =============================================
  2. Building a JIT: Per-function Lazy Compilation
  3. =============================================
  4. .. contents::
  5. :local:
  6. **This tutorial is under active development. It is incomplete and details may
  7. change frequently.** Nonetheless we invite you to try it out as it stands, and
  8. we welcome any feedback.
  9. Chapter 3 Introduction
  10. ======================
  11. **Warning: This text is currently out of date due to ORC API updates.**
  12. **The example code has been updated and can be used. The text will be updated
  13. once the API churn dies down.**
  14. Welcome to Chapter 3 of the "Building an ORC-based JIT in LLVM" tutorial. This
  15. chapter discusses lazy JITing and shows you how to enable it by adding an ORC
  16. CompileOnDemand layer the JIT from `Chapter 2 <BuildingAJIT2.html>`_.
  17. Lazy Compilation
  18. ================
  19. When we add a module to the KaleidoscopeJIT class from Chapter 2 it is
  20. immediately optimized, compiled and linked for us by the IRTransformLayer,
  21. IRCompileLayer and RTDyldObjectLinkingLayer respectively. This scheme, where all the
  22. work to make a Module executable is done up front, is simple to understand and
  23. its performance characteristics are easy to reason about. However, it will lead
  24. to very high startup times if the amount of code to be compiled is large, and
  25. may also do a lot of unnecessary compilation if only a few compiled functions
  26. are ever called at runtime. A truly "just-in-time" compiler should allow us to
  27. defer the compilation of any given function until the moment that function is
  28. first called, improving launch times and eliminating redundant work. In fact,
  29. the ORC APIs provide us with a layer to lazily compile LLVM IR:
  30. *CompileOnDemandLayer*.
  31. The CompileOnDemandLayer class conforms to the layer interface described in
  32. Chapter 2, but its addModule method behaves quite differently from the layers
  33. we have seen so far: rather than doing any work up front, it just scans the
  34. Modules being added and arranges for each function in them to be compiled the
  35. first time it is called. To do this, the CompileOnDemandLayer creates two small
  36. utilities for each function that it scans: a *stub* and a *compile
  37. callback*. The stub is a pair of a function pointer (which will be pointed at
  38. the function's implementation once the function has been compiled) and an
  39. indirect jump through the pointer. By fixing the address of the indirect jump
  40. for the lifetime of the program we can give the function a permanent "effective
  41. address", one that can be safely used for indirection and function pointer
  42. comparison even if the function's implementation is never compiled, or if it is
  43. compiled more than once (due to, for example, recompiling the function at a
  44. higher optimization level) and changes address. The second utility, the compile
  45. callback, represents a re-entry point from the program into the compiler that
  46. will trigger compilation and then execution of a function. By initializing the
  47. function's stub to point at the function's compile callback, we enable lazy
  48. compilation: The first attempted call to the function will follow the function
  49. pointer and trigger the compile callback instead. The compile callback will
  50. compile the function, update the function pointer for the stub, then execute
  51. the function. On all subsequent calls to the function, the function pointer
  52. will point at the already-compiled function, so there is no further overhead
  53. from the compiler. We will look at this process in more detail in the next
  54. chapter of this tutorial, but for now we'll trust the CompileOnDemandLayer to
  55. set all the stubs and callbacks up for us. All we need to do is to add the
  56. CompileOnDemandLayer to the top of our stack and we'll get the benefits of
  57. lazy compilation. We just need a few changes to the source:
  58. .. code-block:: c++
  59. ...
  60. #include "llvm/ExecutionEngine/SectionMemoryManager.h"
  61. #include "llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h"
  62. #include "llvm/ExecutionEngine/Orc/CompileUtils.h"
  63. ...
  64. ...
  65. class KaleidoscopeJIT {
  66. private:
  67. std::unique_ptr<TargetMachine> TM;
  68. const DataLayout DL;
  69. RTDyldObjectLinkingLayer ObjectLayer;
  70. IRCompileLayer<decltype(ObjectLayer), SimpleCompiler> CompileLayer;
  71. using OptimizeFunction =
  72. std::function<std::shared_ptr<Module>(std::shared_ptr<Module>)>;
  73. IRTransformLayer<decltype(CompileLayer), OptimizeFunction> OptimizeLayer;
  74. std::unique_ptr<JITCompileCallbackManager> CompileCallbackManager;
  75. CompileOnDemandLayer<decltype(OptimizeLayer)> CODLayer;
  76. public:
  77. using ModuleHandle = decltype(CODLayer)::ModuleHandleT;
  78. First we need to include the CompileOnDemandLayer.h header, then add two new
  79. members: a std::unique_ptr<JITCompileCallbackManager> and a CompileOnDemandLayer,
  80. to our class. The CompileCallbackManager member is used by the CompileOnDemandLayer
  81. to create the compile callback needed for each function.
  82. .. code-block:: c++
  83. KaleidoscopeJIT()
  84. : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()),
  85. ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }),
  86. CompileLayer(ObjectLayer, SimpleCompiler(*TM)),
  87. OptimizeLayer(CompileLayer,
  88. [this](std::shared_ptr<Module> M) {
  89. return optimizeModule(std::move(M));
  90. }),
  91. CompileCallbackManager(
  92. orc::createLocalCompileCallbackManager(TM->getTargetTriple(), 0)),
  93. CODLayer(OptimizeLayer,
  94. [this](Function &F) { return std::set<Function*>({&F}); },
  95. *CompileCallbackManager,
  96. orc::createLocalIndirectStubsManagerBuilder(
  97. TM->getTargetTriple())) {
  98. llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr);
  99. }
  100. Next we have to update our constructor to initialize the new members. To create
  101. an appropriate compile callback manager we use the
  102. createLocalCompileCallbackManager function, which takes a TargetMachine and a
  103. JITTargetAddress to call if it receives a request to compile an unknown
  104. function. In our simple JIT this situation is unlikely to come up, so we'll
  105. cheat and just pass '0' here. In a production quality JIT you could give the
  106. address of a function that throws an exception in order to unwind the JIT'd
  107. code's stack.
  108. Now we can construct our CompileOnDemandLayer. Following the pattern from
  109. previous layers we start by passing a reference to the next layer down in our
  110. stack -- the OptimizeLayer. Next we need to supply a 'partitioning function':
  111. when a not-yet-compiled function is called, the CompileOnDemandLayer will call
  112. this function to ask us what we would like to compile. At a minimum we need to
  113. compile the function being called (given by the argument to the partitioning
  114. function), but we could also request that the CompileOnDemandLayer compile other
  115. functions that are unconditionally called (or highly likely to be called) from
  116. the function being called. For KaleidoscopeJIT we'll keep it simple and just
  117. request compilation of the function that was called. Next we pass a reference to
  118. our CompileCallbackManager. Finally, we need to supply an "indirect stubs
  119. manager builder": a utility function that constructs IndirectStubManagers, which
  120. are in turn used to build the stubs for the functions in each module. The
  121. CompileOnDemandLayer will call the indirect stub manager builder once for each
  122. call to addModule, and use the resulting indirect stubs manager to create
  123. stubs for all functions in all modules in the set. If/when the module set is
  124. removed from the JIT the indirect stubs manager will be deleted, freeing any
  125. memory allocated to the stubs. We supply this function by using the
  126. createLocalIndirectStubsManagerBuilder utility.
  127. .. code-block:: c++
  128. // ...
  129. if (auto Sym = CODLayer.findSymbol(Name, false))
  130. // ...
  131. return cantFail(CODLayer.addModule(std::move(Ms),
  132. std::move(Resolver)));
  133. // ...
  134. // ...
  135. return CODLayer.findSymbol(MangledNameStream.str(), true);
  136. // ...
  137. // ...
  138. CODLayer.removeModule(H);
  139. // ...
  140. Finally, we need to replace the references to OptimizeLayer in our addModule,
  141. findSymbol, and removeModule methods. With that, we're up and running.
  142. **To be done:**
  143. ** Chapter conclusion.**
  144. Full Code Listing
  145. =================
  146. Here is the complete code listing for our running example with a CompileOnDemand
  147. layer added to enable lazy function-at-a-time compilation. To build this example, use:
  148. .. code-block:: bash
  149. # Compile
  150. clang++ -g toy.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core orcjit native` -O3 -o toy
  151. # Run
  152. ./toy
  153. Here is the code:
  154. .. literalinclude:: ../../examples/Kaleidoscope/BuildingAJIT/Chapter3/KaleidoscopeJIT.h
  155. :language: c++
  156. `Next: Extreme Laziness -- Using Compile Callbacks to JIT directly from ASTs <BuildingAJIT4.html>`_