Lines Matching refs:we

43 To provide input for our JIT we will use the Kaleidoscope REPL from
53 we will make this connection with the earlier APIs explicit to help people who
83 The APIs that we build in these tutorials will all be variations on this simple
84 theme. Behind the API we will refine the implementation of the JIT to add
85 support for optimization and lazy compilation. Eventually we will extend the
92 In the previous section we described our API, now we examine a simple
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
107 usual include guards and #includes [2]_, we get to the definition of our class:
147 however the linker was hidden inside the MCJIT class. In ORC we expose the
154 That's it for member variables, after that we have a single typedef:
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
177 the body of the constructor, we call the DynamicLibrary::LoadLibraryPermanently
207     // Add the set to the JIT with the resolver we created above and a newly
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
228 the basic functionality we need. The second auxiliary class, the symbol
230 when it encounters an *external symbol* in the module we are adding.  External
234 JIT should "know about one another" by default, but since we would still have to
238 process. Should we search for definitions within the JIT first, then fall back
239 on external definitions? Or should we prefer external definitions where
240 available and only JIT code if we don't already have an available
241 implementation? By using a single symbol resolution scheme we are free to choose
257 tutorial we will adopt the following simple scheme: All modules added to the JIT
261 we don't find a symbol in the JIT itself we'll fall back to our second lambda,
264 within the program itself. If we can't find a symbol definition via either of
268 Now that we've built our symbol resolver we're ready to add our module to the
270 we only have a single Module and addModuleSet expects a collection, we will
271 create a vector of modules and add our module as the only member. Since we
273 CompileLayer's handle type, we can return the handle from addModuleSet
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,
291 but with a twist: We have to *mangle* the name of the symbol we're searching
296 remain portable and search based on the un-mangled name, we just re-produce
302 process. In our Kaleidoscope demo we rely on this method to remove the module
312 executable within the context of your JIT process. In the next chapter we'll
336 .. [1] Actually we use a cut-down version of KaleidoscopeJIT that makes a