Lines Matching refs:we
60 Well, that was easy :). In practice, we recommend always using
113 For Kaleidoscope, we are currently generating functions on the fly, one
115 ultimate optimization experience in this setting, but we also want to
116 catch the easy and quick stuff where possible. As such, we will choose
118 in. If we wanted to make a "static Kaleidoscope compiler", we would use
119 exactly the code we have now, except that we would defer running the
122 In order to get per-function optimizations going, we need to set up a
124 and organize the LLVM optimizations that we want to run. Once we have
125 that, we can add a set of optimizations to run. We'll need a new
126 FunctionPassManager for each module that we want to optimize, so we'll
157 set up, we use a series of "add" calls to add a bunch of LLVM passes.
159 In this case, we choose to add five passes: one analysis pass (alias analysis),
160 and four optimization passes. The passes we choose here are a pretty standard set
164 Once the PassManager is set up, we need to make use of it. We do this by
185 place, improving (hopefully) its body. With this in place, we can try
199 As expected, we now get our nicely optimized code, saving a floating
210 Now that we have reasonable code coming out of our front-end, lets talk
217 applied to it. For example, you can run optimizations on it (as we did
223 In this section, we'll add JIT compiler support to our interpreter. The
224 basic idea that we want for Kaleidoscope is to have the user enter
226 expressions they type in. For example, if they type in "1 + 2;", we
230 In order to do this, we first declare and initialize the JIT. This is
249 tutorials. In later chapters we will look at how it works and extend it with
250 new features, but for now we will take it as given. Its API is very simple::
267 // we can free it later.
276 // arguments, returns a double) so we can call it as a native function.
288 has been added to the JIT it can no longer be modified, so we also open a new
291 Once we've added the module to the JIT we need to get a pointer to the final
293 the name of the top-level expression function: ``__anon_expr``. Since we just
294 added this function, we assert that findSymbol returned a result.
296 Next, we get the in-memory address of the ``__anon_expr`` function by calling
297 ``getAddress()`` on the symbol. Recall that we compile top-level expressions
305 Finally, since we don't support re-evaluation of top-level expressions, we
306 remove the module from the JIT when we're done to free the associated memory.
307 Recall, however, that the module we created a few lines earlier (via
325 shows the "no argument function that always returns double" that we
327 demonstrates very basic functionality, but can we do more?
357 of the same module that contained anonymous expression. When we removed that
358 module from the JIT to free the memory for the anonymous expression, we deleted
359 the definition of ``testfunc`` along with it. Then, when we tried to call
366 anonymous expression in a different module we can delete it without affecting
369 In fact, we're going to go a step further and put every function in its own
400 To allow each function to live in its own module we'll need a way to
401 re-generate previous function declarations into each new module we open:
414 // If not, check whether we can codegen the declaration from some existing
442 To enable this, we'll start by adding a new global, ``FunctionProtos``, that
447 it doesn't find one. In ``CallExprAST::codegen()`` we just need to replace the
448 call to ``TheModule->getFunction()``. In ``FunctionAST::codegen()`` we need to
450 done, we can always obtain a function declaration in the current module for any
484 In HandleDefinition, we add two lines to transfer the newly defined function to
485 the JIT and open a new module. In HandleExtern, we just need to add one line to
503 Even with this simple code, we get some surprisingly powerful capabilities -
557 In the future we'll see how tweaking this symbol resolution rule can be used to
562 One immediate benefit of the symbol resolution rule is that we can now extend
564 if we add:
574 Now we can produce simple output to the console by using things like:
581 tutorial. At this point, we can compile a non-Turing-complete
583 Next up we'll look into `extending the language with control flow