Lines Matching full:we
60 Well, that was easy :). In practice, we recommend always using
84 We'd really like to see this generate "``tmp = x+3; result = tmp*tmp;``"
121 For Kaleidoscope, we are currently generating functions on the fly, one
122 at a time, as the user types them in. We aren't shooting for the
123 ultimate optimization experience in this setting, but we also want to
124 catch the easy and quick stuff where possible. As such, we will choose
126 in. If we wanted to make a "static Kaleidoscope compiler", we would use
127 exactly the code we have now, except that we would defer running the
130 In order to get per-function optimizations going, we need to set up a
132 and organize the LLVM optimizations that we want to run. Once we have
133 that, we can add a set of optimizations to run. We'll need a new
134 FunctionPassManager for each module that we want to optimize, so we'll
161 set up, we use a series of "add" calls to add a bunch of LLVM passes.
163 In this case, we choose to add four optimization passes.
164 The passes we choose here are a pretty standard set
168 Once the PassManager is set up, we need to make use of it. We do this by
189 place, improving (hopefully) its body. With this in place, we can try
203 As expected, we now get our nicely optimized code, saving a floating
214 Now that we have reasonable code coming out of our front-end, let's talk
221 applied to it. For example, you can run optimizations on it (as we did
227 In this section, we'll add JIT compiler support to our interpreter. The
228 basic idea that we want for Kaleidoscope is to have the user enter
230 expressions they type in. For example, if they type in "1 + 2;", we
234 In order to do this, we first prepare the environment to create code for
268 We also need to setup the data layout for the JIT:
284 In later chapters we will look at how it works and extend it with
285 new features, but for now we will take it as given. Its API is very simple:
291 We can take this simple API and change our code that parses top-level expressions to
302 // we can free it later.
311 // arguments, returns a double) so we can call it as a native function.
320 the top-level expression to the JIT. We do this by calling addModule, which
323 has been added to the JIT it can no longer be modified, so we also open a new
326 Once we've added the module to the JIT we need to get a pointer to the final
327 generated code. We do this by calling the JIT's findSymbol method, and passing
328 the name of the top-level expression function: ``__anon_expr``. Since we just
329 added this function, we assert that findSymbol returned a result.
331 Next, we get the in-memory address of the ``__anon_expr`` function by calling
332 ``getAddress()`` on the symbol. Recall that we compile top-level expressions
340 Finally, since we don't support re-evaluation of top-level expressions, we
341 remove the module from the JIT when we're done to free the associated memory.
342 Recall, however, that the module we created a few lines earlier (via
360 shows the "no argument function that always returns double" that we
362 demonstrates very basic functionality, but can we do more?
392 of the same module that contained anonymous expression. When we removed that
393 module from the JIT to free the memory for the anonymous expression, we deleted
394 the definition of ``testfunc`` along with it. Then, when we tried to call
401 anonymous expression in a different module we can delete it without affecting
404 In fact, we're going to go a step further and put every function in its own
435 To allow each function to live in its own module we'll need a way to
436 re-generate previous function declarations into each new module we open:
449 // If not, check whether we can codegen the declaration from some existing
477 To enable this, we'll start by adding a new global, ``FunctionProtos``, that
478 holds the most recent prototype for each function. We'll also add a convenience
482 it doesn't find one. In ``CallExprAST::codegen()`` we just need to replace the
483 call to ``TheModule->getFunction()``. In ``FunctionAST::codegen()`` we need to
485 done, we can always obtain a function declaration in the current module for any
488 We also need to update HandleDefinition and HandleExtern:
521 In HandleDefinition, we add two lines to transfer the newly defined function to
522 the JIT and open a new module. In HandleExtern, we just need to add one line to
545 Even with this simple code, we get some surprisingly powerful capabilities -
602 In the future we'll see how tweaking this symbol resolution rule can be used to
607 One immediate benefit of the symbol resolution rule is that we can now extend
609 if we add:
625 Note, that for Windows we need to actually export the functions because
628 Now we can produce simple output to the console by using things like:
635 tutorial. At this point, we can compile a non-Turing-complete
637 Next up we'll look into `extending the language with control flow