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
156 set up, we use a series of "add" calls to add a bunch of LLVM passes.
158 In this case, we choose to add five passes: one analysis pass (alias analysis),
159 and four optimization passes. The passes we choose here are a pretty standard set
163 Once the PassManager is set up, we need to make use of it. We do this by
184 place, improving (hopefully) its body. With this in place, we can try
198 As expected, we now get our nicely optimized code, saving a floating
209 Now that we have reasonable code coming out of our front-end, lets talk
216 applied to it. For example, you can run optimizations on it (as we did
222 In this section, we'll add JIT compiler support to our interpreter. The
223 basic idea that we want for Kaleidoscope is to have the user enter
225 expressions they type in. For example, if they type in "1 + 2;", we
229 In order to do this, we first declare and initialize the JIT. This is
248 tutorials. In later chapters we will look at how it works and extend it with
249 new features, but for now we will take it as given. Its API is very simple::
266 // we can free it later.
275 // arguments, returns a double) so we can call it as a native function.
287 has been added to the JIT it can no longer be modified, so we also open a new
290 Once we've added the module to the JIT we need to get a pointer to the final
292 the name of the top-level expression function: ``__anon_expr``. Since we just
293 added this function, we assert that findSymbol returned a result.
295 Next, we get the in-memory address of the ``__anon_expr`` function by calling
296 ``getAddress()`` on the symbol. Recall that we compile top-level expressions
304 Finally, since we don't support re-evaluation of top-level expressions, we
305 remove the module from the JIT when we're done to free the associated memory.
306 Recall, however, that the module we created a few lines earlier (via
324 shows the "no argument function that always returns double" that we
326 demonstrates very basic functionality, but can we do more?
356 of the same module that contained anonymous expression. When we removed that
357 module from the JIT to free the memory for the anonymous expression, we deleted
358 the definition of ``testfunc`` along with it. Then, when we tried to call
365 anonymous expression in a different module we can delete it without affecting
368 In fact, we're going to go a step further and put every function in its own
399 To allow each function to live in its own module we'll need a way to
400 re-generate previous function declarations into each new module we open:
413 // If not, check whether we can codegen the declaration from some existing
441 To enable this, we'll start by adding a new global, ``FunctionProtos``, that
446 it doesn't find one. In ``CallExprAST::codegen()`` we just need to replace the
447 call to ``TheModule->getFunction()``. In ``FunctionAST::codegen()`` we need to
449 done, we can always obtain a function declaration in the current module for any
483 In HandleDefinition, we add two lines to transfer the newly defined function to
484 the JIT and open a new module. In HandleExtern, we just need to add one line to
502 Even with this simple code, we get some surprisingly powerful capabilities -
556 In the future we'll see how tweaking this symbol resolution rule can be used to
561 One immediate benefit of the symbol resolution rule is that we can now extend
563 if we add:
573 Now we can produce simple output to the console by using things like:
580 tutorial. At this point, we can compile a non-Turing-complete
582 Next up we'll look into `extending the language with control flow