Lines Matching refs:our

35 - `Chapter #4 <BuildingAJIT4.html>`_: Improve the laziness of our JIT by
43 To provide input for our JIT we will use the Kaleidoscope REPL from
46 code for that chapter and replace it with optimization support in our JIT class
61 compiler does. To support that aim our initial, bare-bones JIT API will be:
92 In the previous section we described our API, now we examine a simple
96 input for our JIT: Each time the user enters an expression the REPL will add a
99 use the findSymbol method of our JIT class find and execute the code for the
102 of this tutorial we'll modify the REPL to enable new interactions with our JIT
103 class, but for now we will take this setup for granted and focus our attention on
104 the implementation of our JIT itself.
107 usual include guards and #includes [2]_, we get to the definition of our class:
139 to build our LLVM compiler instance; A DataLayout, DL, which will be used for
144 The first layer, ObjectLinkingLayer, is the foundation of our JIT: it takes
149 this tutorial our ObjectLinkingLayer will just be used to support the next layer
150 in our stack: the IRCompileLayer, which will be responsible for taking LLVM IR,
155 ModuleHandle. This is the handle type that will be returned from our JIT's
158 (IRCompileLayer::ModuleSetHandleT), so we just alias our ModuleHandle to this.
170 Next up we have our class constructor. We begin by initializing TM using the
172 the current process. Next we use our newly created TargetMachine to initialize
173 DL, our DataLayout. Then we initialize our IRCompileLayer. Our IRCompile layer
174 needs two things: (1) A reference to our object linking layer, and (2) a
186     // Build our symbol resolver:
203     // Build a singlton module set to hold our module.
214 Now we come to the first of our JIT API methods: addModule. This method is
216 this initial implementation of our JIT we will make our modules "available for
218 immediately compile them. In later chapters we will teach our JIT to be lazier
222 To add our module to the IRCompileLayer we need to supply two auxiliary objects
226 tables (if the JIT'd code uses exceptions). For our memory manager we will use
259 implement this our first lambda (the one defining findSymbolInLogicalDylib) will
261 we don't find a symbol in the JIT itself we'll fall back to our second lambda,
265 these paths the JIT will refuse to accept our module, returning a "symbol not
268 Now that we've built our symbol resolver we're ready to add our module to the
271 create a vector of modules and add our module as the only member. Since we
272 have already typedef'd our ModuleHandle type to be the same as the
274 directly from our addModule method.
289 Now that we can add code to our JIT, we need a way to find the symbols we've
290 added to it. To do that we call the findSymbol method on our IRCompileLayer,
299 We now come to the last method in our JIT API: removeModule. This method is
302 process. In our Kaleidoscope demo we rely on this method to remove the module
321 Here is the complete code listing for our running example. To build this
338        impossible to re-define symbols in the REPL, but will make our symbol