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. The code looks like
155 pointer to the ``Module`` to construct itself. Once it is set up, we use
159 "``TheExecutionEngine``" variable is related to the JIT, which we will
162 In this case, we choose to add 4 optimization passes. The passes we
167 Once the PassManager is set up, we need to make use of it. We do this by
188 place, improving (hopefully) its body. With this in place, we can try
202 As expected, we now get our nicely optimized code, saving a floating
213 Now that we have reasonable code coming out of our front-end, lets talk
220 applied to it. For example, you can run optimizations on it (as we did
226 In this section, we'll add JIT compiler support to our interpreter. The
227 basic idea that we want for Kaleidoscope is to have the user enter
229 expressions they type in. For example, if they type in "1 + 2;", we
233 In order to do this, we first declare and initialize the JIT. This is
256 machine code. In our case, this means that we can change the code that
270           // Cast it to the right type (takes no arguments, returns a double) so we
276 Recall that we compile top-level expressions into a self-contained LLVM
298 shows the "no argument function that always returns double" that we
300 demonstrates very basic functionality, but can we do more?
323 This illustrates that we can now call user code, but there is something
324 a bit subtle going on here. Note that we only invoke the JIT on the
325 anonymous functions that *call testfunc*, but we never invoked it on
333 etc. However, even with this simple code, we get some surprisingly
396 One interesting application of this is that we can now extend the
398 example, if we add:
409 Now we can produce simple output to the console by using things like:
416 tutorial. At this point, we can compile a non-Turing-complete
418 Next up we'll look into `extending the language with control flow