Lines Matching refs:we
12 LLVM <index.html>`_" tutorial. In chapters 1 through 6, we've built a
15 journey, we learned some parsing techniques, how to build and represent
51 In this case, we have the variable "X", whose value depends on the path
54 two values. The LLVM IR that we want for this example looks like this:
108 With this in mind, the high-level idea is that we want to make a stack
110 mutable object in a function. To take advantage of this trick, we need
138 above, we could rewrite the example to use the alloca technique to avoid
166 With this, we have discovered a way to handle arbitrary mutable
176 another one: we have now apparently introduced a lot of stack traffic
209 pass is the answer to dealing with mutable variables, and we highly
232 languages, and we'll illustrate it below with Kaleidoscope. The final
235 directly, avoiding use of the mem2reg optimization pass? In short, we
261 Now that we know the sort of problem we want to tackle, lets see what
268 While the first item is really what this is about, we only have
272 them. Here's a motivating example that shows how we could use these:
280 # Recursive fib, we could do this before.
299 In order to mutate variables, we have to change our existing variables
300 to use the "alloca trick". Once we have that, we'll add our new
309 to support mutation, we need to change this slightly, so that it
317 variable of 'for' loops. For consistency, we'll allow mutation of these
321 To start our transformation of Kaleidoscope, we'll change the
323 we do this, the C++ compiler will tell us what parts of the code we need
330 Also, since we will need to create these alloca's, we'll use a helper
351 With this in place, the first functionality change we want to make is to
368 As you can see, this is pretty straightforward. Now we need to update
401 This code is virtually identical to the code `before we allowed mutable
402 variables <LangImpl5.html#code-generation-for-the-for-loop>`_. The big difference is that we
403 no longer have to construct a PHI node, and we use load/store to access
406 To support mutable argument variables, we need to also make allocas for
427 For each argument, we make an alloca, store the input value to the
482 still see the extremely simple-minded code generation strategy we are
485 from the stack. Also, note that we didn't modify the if/then/else
486 expression, so it still inserts a PHI node. While we could make an
487 alloca for it, it is actually easier to create a PHI node for it, so we
521 After the rest of the optimizers run, we get:
544 Here we see that the simplifycfg pass decided to clone the return
549 we'll add the assignment operator.
576 // Special case '=' because we don't want to emit the LHS as an expression.
607 Once we have the variable, codegen'ing the assignment is
608 straightforward: we emit the RHS of the assignment, create a store, and
612 Now that we have an assignment operator, we can mutate loop variables
613 and arguments. For example, we can now run code like this:
631 When run, this example prints "123" and then "4", showing that we did
632 actually mutate the value! Okay, we have now officially implemented our
634 case. However, to be really useful, we want the ability to define our
640 Adding var/in is just like any other extension we made to
641 Kaleidoscope: we extend the lexer, the parser, the AST and the code
668 The next step is to define the AST node that we will construct. For
687 can optionally have an initializer value. As such, we capture this
691 With this in place, we can define the parser pieces. The first thing we
722 Next we define ParseVarExpr:
765 Once all the variables are parsed, we then parse the body and create the
770 // At this point, we have to have 'in'.
783 Now that we can parse and represent the code, we need to support
799 time. For each variable we put into the symbol table, we remember the
800 previous value that we replace in OldBindings.
821 // Remember the old variable binding so that we can restore the binding when
822 // we unrecurse.
829 There are more comments here than code. The basic idea is that we emit
832 we evaluate the body of the var/in expression:
841 Finally, before returning, we restore the previous variable bindings:
853 The end result of all of this is that we get properly scoped variable
854 definitions, and we even (trivially) allow mutation of them :).
856 With this, we completed what we set out to do. Our nice iterative fib