Lines Matching refs:we

28 In order to generate LLVM IR, we want some simple setup to get started.
29 First we define virtual code generation (codegen) methods in each AST
69 The second thing we want is an "Error" method like we used for the
99 With these basics in place, we can start talking about how to generate
101 has been set up to generate code *into* something. For now, we'll assume
102 that this has already been done, and we'll just use it to emit code.
109 First we'll do numeric literals:
134 version of Kaleidoscope, we assume that the variable has already been
139 it. In future chapters, we'll add support for `loop induction
164 that we recursively emit code for the left-hand side of the expression,
165 then the right-hand side, then we compute the result of the binary
166 expression. In this code, we do a simple switch on the opcode to create
191 value to be a 0.0 or 1.0 value. In order to get these semantics, we
195 unsigned value. In contrast, if we used the `sitofp
223 holds all of the functions we are JIT'ing. By giving each function the
224 same name as what the user specifies, we can use the LLVM symbol table
227 Once we have the function to call, we recursively codegen each argument
234 This wraps up our handling of the four basic expressions that we have so
291         // Delete the one we just made and get the existing one.
303 cases: first, we want to allow 'extern'ing a function more than once, as
305 the same type, we just have to check that the number of arguments
306 match). Second, we want to allow 'extern'ing a function and then
312 function we just created (by calling ``eraseFromParent``) and then
334 In order to verify the logic above, we first check to see if the
337 is a forward declaration. Since we don't allow anything after a full
339 reference to a function was an 'extern', we simply verify that the
341 we emit an error.
361 Function object to the caller. Note that we don't check for conflicting
363 straight-forward with the mechanics we have already used above.
374 Code generation for function definitions starts out simply enough: we
377 in it from the last function we compiled. Code generation of the
389 Now we get to the point where the ``Builder`` is set up. The first line
395 Graph <http://en.wikipedia.org/wiki/Control_flow_graph>`_. Since we
411 Once the insertion point is set up, we call the ``CodeGen()`` method for
414 value that was computed. Assuming no error, we then create an LLVM `ret
416 Once the function is built, we call ``verifyFunction``, which is
420 function is finished and validated, we return it.
430 we handle this by merely deleting the function we produced with the
432 that they incorrectly typed in before: if we didn't delete it, it would
450 we can look at the pretty IR calls. The sample code inserts calls to
465 functions for us. This will be handy when we add `JIT
488 LLVM builder calls that we use to create the instructions.
503 time to execute if you call it. In the future we'll add conditional
568 we'll describe how to `add JIT codegen and optimizer
569 support <LangImpl4.html>`_ to this so we can actually start running
576 the LLVM code generator. Because this uses the LLVM libraries, we need
577 to link them in. To do this, we use the