From d96b159fe3425c6680503ef3ff3c1d7d299fd730 Mon Sep 17 00:00:00 2001
From: Chris Lattner
Code generation for prototypes and functions has to handle a number of -details, which make their code less beautiful and elegant than expression code -generation, but they illustrate some important points. First, lets talk about -code generation for prototypes: this is used both for function bodies as well -as external function declarations. The code starts with:
+Code generation for prototypes and functions must handle a number of +details, which make their code less beautiful than expression code +generation, but allows us to illustrate some important points. First, lets +talk about code generation for prototypes: they are used both for function +bodies and external function declarations. The code starts with:
@@ -306,15 +306,15 @@ Function *PrototypeAST::Codegen() {
This code packs a lot of power into a few lines. Note first that this -function returns a Function* instead of a Value*. Because a "prototype" really -talks about the external interface for a function (not the value computed by -an expression), it makes sense for it to return the LLVM Function it corresponds -to when codegen'd.
+function returns a "Function*" instead of a "Value*". Because a "prototype" +really talks about the external interface for a function (not the value computed +by an expression), it makes sense for it to return the LLVM Function it +corresponds to when codegen'd. -The next step is to create +
The call to FunctionType::get creates the FunctionType that should be used for a given Prototype. Since all function arguments in Kaleidoscope are of type double, the first line creates -a vector of "N" LLVM Double types. It then uses the FunctionType::get +a vector of "N" LLVM double types. It then uses the FunctionType::get method to create a function type that takes "N" doubles as arguments, returns one double as a result, and that is not vararg (the false parameter indicates this). Note that Types in LLVM are uniqued just like Constants are, so you @@ -347,7 +347,7 @@ Module. The code above exploits this fact to tell if there was a previous definition of this function.
In Kaleidoscope, I choose to allow redefinitions of functions in two cases: -first, we want to allow 'extern'ing a function more than once, so long as the +first, we want to allow 'extern'ing a function more than once, as long as the prototypes for the externs match (since all arguments have the same type, we just have to check that the number of arguments match). Second, we want to allow 'extern'ing a function and then definining a body for it. This is useful @@ -378,9 +378,9 @@ it. The "erase" form unlinks the object and then deletes it.
In order to verify the logic above, we first check to see if the preexisting +
In order to verify the logic above, we first check to see if the pre-existing function is "empty". In this case, empty means that it has no basic blocks in -it, which means it has no body. If it has no body, this means its a forward +it, which means it has no body. If it has no body, it is a forward declaration. Since we don't allow anything after a full definition of the function, the code rejects this case. If the previous reference to a function was an 'extern', we simply verify that the number of arguments for that @@ -408,7 +408,7 @@ the arguments in the NamedValues map for future use by the VariableExprAST AST node. Once this is set up, it returns the Function object to the caller. Note that we don't check for conflicting argument names here (e.g. "extern foo(a b a)"). Doing so would be very -straight-forward.
+straight-forward with the mechanics we have already used above.@@ -445,7 +445,7 @@ the end of the new basic block. Basic blocks in LLVM are an important part of functions that define the Control Flow Graph. Since we don't have any control flow, our functions will only contain one -block so far. We'll fix this in a future installment :). +block so far. We'll fix this in Chapter 5 :).@@ -519,7 +519,7 @@ functions. For example:ready> 4+5; -ready> Read top-level expression: +Read top-level expression: define double @""() { entry: %addtmp = add double 4.000000e+00, 5.000000e+00 @@ -529,14 +529,16 @@ entry:Note how the parser turns the top-level expression into anonymous functions -for us. This will be handy when we add JIT support in the next chapter. Also -note that the code is very literally transcribed, no optimizations are being -performed. We will add optimizations explicitly in the next chapter.
+for us. This will be handy when we add JIT +support in the next chapter. Also note that the code is very literally +transcribed, no optimizations are being performed. We will +add optimizations explicitly in +the next chapter.ready> def foo(a b) a*a + 2*a*b + b*b; -ready> Read function definition: +Read function definition: define double @foo(double %a, double %b) { entry: %multmp = mul double %a, %a @@ -556,7 +558,7 @@ LLVM builder calls that we use to create the instructions.ready> def bar(a) foo(a, 4.0) + bar(31337); -ready> Read function definition: +Read function definition: define double @bar(double %a) { entry: %calltmp = call double @foo( double %a, double 4.000000e+00 ) @@ -574,11 +576,11 @@ flow to make recursion actually be useful :).ready> extern cos(x); -ready> Read extern: +Read extern: declare double @cos(double) ready> cos(1.234); -ready> Read top-level expression: +Read top-level expression: define double @""() { entry: %calltmp = call double @cos( double 1.234000e+00 ) @@ -657,7 +659,7 @@ our makefile/command line about which options to use:# Compile - g++ -g toy.cpp `llvm-config --cppflags --ldflags --libs core` -o toy + g++ -g -O3 toy.cpp `llvm-config --cppflags --ldflags --libs core` -o toy # Run ./toy-- 2.34.1