Lines Matching refs:we

12 LLVM <index.html>`_" tutorial. In chapters 1 through 8, we've built a
19 source that the programmer wrote. In LLVM we generally use a format
23 The short summary of this chapter is that we'll go through the
27 Caveat: For now we can't debug via the JIT, so we'll need to compile
29 we'll make a few modifications to the running of the language and
30 how programs are compiled. This means that we'll have a source file
32 interactive JIT. It does involve a limitation that we can only
36 Here's the sample program we'll be compiling:
54 locations more difficult. In LLVM IR we keep the original source location
61 tutorial we're going to avoid optimization (as you'll see with one of the
69 we're going to make a few changes to Kaleidoscope to support compiling
73 First we make our anonymous function that contains our top level
83 Then we're going to remove the command line code wherever it exists:
102 Lastly we're going to disable all of the optimization passes and the JIT so
103 that the only thing that happens after we're done parsing and generating
118   -      // Cast it to the right type (takes no arguments, returns a double) so we
146 This relatively small set of changes get us to the point that we can compile
161 (read: one file of source code). So the first thing we need to do is
167 Similar to the ``IRBuilder`` class we have a
176 of our IR level descriptions. Construction for it takes a module so we
177 need to construct it shortly after we construct our module. We've left it
180 Next we're going to create a small container to cache some of our frequent
181 data. The first will be our compile unit, but we'll also write a bit of
182 code for our one type since we won't have to worry about multiple typed
204 And then later on in ``main`` when we're constructing our module:
213 There are a couple of things to note here. First, while we're producing a
214 compile unit for a language called Kaleidoscope we used the language
217 and we follow the C ABI in our llvm code generation so it's the closest
218 thing to accurate. This ensures we can actually call functions from the
221 we're using shell redirection to put our source into the Kaleidoscope
226 we need to "finalize" the debug information. The reasons are part of the
239 Now that we have our ``Compile Unit`` and our source locations, we can add
240 function definitions to the debug info. So in ``PrototypeAST::codegen()`` we
251 giving us an DIFile and asking the ``Compile Unit`` we created above for the
252 directory and filename where we are currently. Then, for now, we use some
267 and we now have an DISubprogram that contains a reference to all of our
276 or parser so we'll need to add it.
298 In this set of code we've added some functionality on how to keep track of the
299 line and column of the "source file". As we lex every token we set our current
303 and then we have added to all of our AST classes a source location:
320 that we pass down through when we create a new expression:
329 From this we can make sure to tell ``DIBuilder`` when we're at a new source
330 location so it can use that when we generate the rest of our code and make
346 that both tells the main ``IRBuilder`` where we are, but also what scope
347 we're in. Since we've just created a function above we can either be in
348 the main file scope (like when we created our function), or now we can be
349 in the function scope we just created. To represent this we create a stack
360 Then we make sure to:
366 emit the location every time we start to generate code for a new AST, and
373 store the scope (function) when we create it and use it:
377 when we start generating the code for each function.
384   // Pop off the lexical block for the function since we added it
391 Now that we have functions, we need to be able to print out the variables
392 we have in scope. Let's get our function arguments set up so we can get
394 a lot of code, and we generally handle it when we're creating the
409 Here we're doing a few things. First, we're grabbing our current scope
410 for the variable so we can say what range of code our variable is valid
411 through. Second, we're creating the variable, giving it the scope,
413 index. Third, we create an ``lvm.dbg.declare`` call to indicate at the IR
414 level that we've got a variable in an alloca (and it gives a starting
420 in the past. In this case we need to do a little bit of a hack to avoid
423 ``FunctionAST::CodeGen`` we add a couple of lines:
432 and then emit a new location when we actually start generating code for the
439 With this we have enough debug information to set breakpoints in functions,