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
367 As you can see, this is pretty straightforward. Now we need to update
398 This code is virtually identical to the code `before we allowed mutable
399 variables <LangImpl5.html#forcodegen>`_. The big difference is that we
400 no longer have to construct a PHI node, and we use load/store to access
403 To support mutable argument variables, we need to also make allocas for
424 For each argument, we make an alloca, store the input value to the
479 still see the extremely simple-minded code generation strategy we are
482 from the stack. Also, note that we didn't modify the if/then/else
483 expression, so it still inserts a PHI node. While we could make an
484 alloca for it, it is actually easier to create a PHI node for it, so we
518 After the rest of the optimizers run, we get:
541 Here we see that the simplifycfg pass decided to clone the return
546 we'll add the assignment operator.
573 // Special case '=' because we don't want to emit the LHS as an expression.
602 Once we have the variable, codegen'ing the assignment is
603 straightforward: we emit the RHS of the assignment, create a store, and
607 Now that we have an assignment operator, we can mutate loop variables
608 and arguments. For example, we can now run code like this:
626 When run, this example prints "123" and then "4", showing that we did
627 actually mutate the value! Okay, we have now officially implemented our
629 case. However, to be really useful, we want the ability to define our
635 Adding var/in is just like any other extension we made to
636 Kaleidoscope: we extend the lexer, the parser, the AST and the code
659 The next step is to define the AST node that we will construct. For
677 can optionally have an initializer value. As such, we capture this
681 With this in place, we can define the parser pieces. The first thing we
705 Next we define ParseVarExpr:
748 Once all the variables are parsed, we then parse the body and create the
753 // At this point, we have to have 'in'.
764 Now that we can parse and represent the code, we need to support
780 time. For each variable we put into the symbol table, we remember the
781 previous value that we replace in OldBindings.
801 // Remember the old variable binding so that we can restore the binding when
802 // we unrecurse.
809 There are more comments here than code. The basic idea is that we emit
812 we evaluate the body of the var/in expression:
820 Finally, before returning, we restore the previous variable bindings:
832 The end result of all of this is that we get properly scoped variable
833 definitions, and we even (trivially) allow mutation of them :).
835 With this, we completed what we set out to do. Our nice iterative fib