mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2025-01-09 21:32:49 +00:00
[Kaleidoscope][BuildingAJIT] More cleanup of Chapter 2.
Streamline some wording, fix a bug in the markup for the layer interface table. llvm-svn: 271917
This commit is contained in:
parent
4f6955f990
commit
b9bf9fd55e
@ -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.
|
||||
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: 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:
|
||||
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 |
|
||||
|
Loading…
Reference in New Issue
Block a user