diff options
| -rw-r--r-- | llvm/docs/tutorial/BuildingAJIT2.rst | 35 |
1 files changed, 18 insertions, 17 deletions
diff --git a/llvm/docs/tutorial/BuildingAJIT2.rst b/llvm/docs/tutorial/BuildingAJIT2.rst index 87f1d299d42..4e68f37a079 100644 --- a/llvm/docs/tutorial/BuildingAJIT2.rst +++ b/llvm/docs/tutorial/BuildingAJIT2.rst @@ -147,18 +147,19 @@ inside our resolver, and the call through to addModuleSet. At the bottom of our JIT we add a private method to do the actual optimization: *optimizeModule*. This function sets up a FunctionPassManager, adds some passes to it, runs it over every function in the module, and then returns the mutated -module. The specific optimizations used are the same ones used in +module. The specific optimizations are the same ones used in `Chapter 4 <LangImpl4.html>`_ of the "Implementing a language with LLVM" -tutorial series -- readers may visit that chapter for a more in-depth -discussion of them, and of IR optimization in general. - -And that's it: When a module is added to our JIT the OptimizeLayer will now -pass it to our optimizeModule function before passing the transformed module -on to the CompileLayer below. Of course, we could have called optimizeModule -directly in our addModule function and not gone to the bother of using the -IRTransformLayer, but it gives us an opportunity to see how layers compose, and -how one can be implemented, because IRTransformLayer turns out to be one of -the simplest implementations of the *layer* concept that can be devised: +tutorial series. Readers may visit that chapter for a more in-depth +discussion of these, and of IR optimization in general. + +And that's it in terms of changes to KaleidoscopeJIT: When a module is added via +addModule the OptimizeLayer will call our optimizeModule function before passing +the transformed module on to the CompileLayer below. Of course, we could have +called optimizeModule directly in our addModule function and not gone to the +bother of using the IRTransformLayer, but doing so gives us another opportunity +to see how layers compose. It also provides a neat entry point to the *layer* +concept itself, because IRTransformLayer turns out to be one of the simplest +implementations of the layer concept that can be devised: .. code-block:: c++ @@ -211,13 +212,13 @@ the simplest implementations of the *layer* concept that can be devised: This is the whole definition of IRTransformLayer, from ``llvm/include/llvm/ExecutionEngine/Orc/IRTransformLayer.h``, stripped of its comments. It is a template class with two template arguments: ``BaesLayerT`` and -``TransformFtor`` that provide the type of the base layer, and the type of the -"transform functor" (in our case a std::function) respectively. The body of the -class is concerned with two very simple jobs: (1) Running every IR Module that -is added with addModuleSet through the transform functor, and (2) conforming to -the ORC layer interface, which is: +``TransformFtor`` that provide the type of the base layer and the type of the +"transform functor" (in our case a std::function) respectively. This class is +concerned with two very simple jobs: (1) Running every IR Module that is added +with addModuleSet through the transform functor, and (2) conforming to the ORC +layer interface. The interface consists of one typedef and five methods: -+------------------------------------------------------------------------------+ ++------------------+-----------------------------------------------------------+ | Interface | Description | +==================+===========================================================+ | | Provides a handle that can be used to identify a module | |
