llvm.org GIT mirror llvm / 5d3458a
[Kaleidoscope][BuildingAJIT] More cleanup of Chapter 2. Streamline some wording, fix a bug in the markup for the layer interface table. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271917 91177308-0d34-0410-b5e6-96231b3b80d8 Lang Hames 3 years ago
1 changed file(s) with 19 addition(s) and 18 deletion(s). Raw diff Collapse all Expand all
146146 At the bottom of our JIT we add a private method to do the actual optimization:
147147 *optimizeModule*. This function sets up a FunctionPassManager, adds some passes
148148 to it, runs it over every function in the module, and then returns the mutated
149 module. The specific optimizations used are the same ones used in
149 module. The specific optimizations are the same ones used in
150150 `Chapter 4 `_ of the "Implementing a language with LLVM"
151 tutorial series -- readers may visit that chapter for a more in-depth
152 discussion of them, and of IR optimization in general.
153
154 And that's it: When a module is added to our JIT the OptimizeLayer will now
155 pass it to our optimizeModule function before passing the transformed module
156 on to the CompileLayer below. Of course, we could have called optimizeModule
157 directly in our addModule function and not gone to the bother of using the
158 IRTransformLayer, but it gives us an opportunity to see how layers compose, and
159 how one can be implemented, because IRTransformLayer turns out to be one of
160 the simplest implementations of the *layer* concept that can be devised:
151 tutorial series. Readers may visit that chapter for a more in-depth
152 discussion of these, and of IR optimization in general.
153
154 And that's it in terms of changes to KaleidoscopeJIT: When a module is added via
155 addModule the OptimizeLayer will call our optimizeModule function before passing
156 the transformed module on to the CompileLayer below. Of course, we could have
157 called optimizeModule directly in our addModule function and not gone to the
158 bother of using the IRTransformLayer, but doing so gives us another opportunity
159 to see how layers compose. It also provides a neat entry point to the *layer*
160 concept itself, because IRTransformLayer turns out to be one of the simplest
161 implementations of the layer concept that can be devised:
161162
162163 .. code-block:: c++
163164
210211 This is the whole definition of IRTransformLayer, from
211212 ``llvm/include/llvm/ExecutionEngine/Orc/IRTransformLayer.h``, stripped of its
212213 comments. It is a template class with two template arguments: ``BaesLayerT`` and
213 ``TransformFtor`` that provide the type of the base layer, and the type of the
214 "transform functor" (in our case a std::function) respectively. The body of the
215 class is concerned with two very simple jobs: (1) Running every IR Module that
216 is added with addModuleSet through the transform functor, and (2) conforming to
217 the ORC layer interface, which is:
218
219 +------------------------------------------------------------------------------+
214 ``TransformFtor`` that provide the type of the base layer and the type of the
215 "transform functor" (in our case a std::function) respectively. This class is
216 concerned with two very simple jobs: (1) Running every IR Module that is added
217 with addModuleSet through the transform functor, and (2) conforming to the ORC
218 layer interface. The interface consists of one typedef and five methods:
219
220 +------------------+-----------------------------------------------------------+
220221 | Interface | Description |
221222 +==================+===========================================================+
222223 | | Provides a handle that can be used to identify a module |