From a1ad2bf890b9113886def1a99116ea8d425ffac0 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Sun, 10 Feb 2008 19:11:04 +0000 Subject: Various updates from Sam Bishop: "I have been working my way through the JIT and Kaleidoscope tutorials in my (minuscule) spare time. Thanks again for writing them! I have attached a patch containing some minor changes, ranging from spelling and grammar fixes to adding a "Next: " hyperlink to the bottom of each page. Every page has been given the "next link" treatment, but otherwise I'm only half way through the Kaleidoscope tutorial. I will send a follow-on patch if time permits." llvm-svn: 46933 --- llvm/docs/tutorial/JITTutorial2.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'llvm/docs/tutorial/JITTutorial2.html') diff --git a/llvm/docs/tutorial/JITTutorial2.html b/llvm/docs/tutorial/JITTutorial2.html index 261a7949e8c..ba72ea2abb0 100644 --- a/llvm/docs/tutorial/JITTutorial2.html +++ b/llvm/docs/tutorial/JITTutorial2.html @@ -32,7 +32,7 @@ unsigned gcd(unsigned x, unsigned y) { if(x == y) { return x; - } else if(x < y) { + } else if(x < y) { return gcd(x, y - x); } else { return gcd(x - y, y); @@ -45,7 +45,7 @@ unsigned gcd(unsigned x, unsigned y) {
GCD CFG
-

The above is a graphical representation of a program in LLVM IR. It places each basic block on a node of a graph, and uses directed edges to indicate flow control. These blocks will be serialized when written to a text or bitcode file, but it is often useful conceptually to think of them as a graph. Again, if you are unsure about the code in the diagram, you should skim through the LLVM Language Reference Manual and convince yourself that it is, in fact, the GCD algorithm.

+

This is a graphical representation of a program in LLVM IR. It places each basic block on a node of a graph and uses directed edges to indicate flow control. These blocks will be serialized when written to a text or bitcode file, but it is often useful conceptually to think of them as a graph. Again, if you are unsure about the code in the diagram, you should skim through the LLVM Language Reference Manual and convince yourself that it is, in fact, the GCD algorithm.

The first part of our code is practically the same as from the first tutorial. The same basic setup is required: creating a module, verifying it, and running the PrintModulePass on it. Even the first segment of makeLLVMModule() looks essentially the same, except that gcd takes one fewer parameter than mul_add.

@@ -94,7 +94,7 @@ Module* makeLLVMModule() {

Here, however, is where our code begins to diverge from the first tutorial. Because gcd has control flow, it is composed of multiple blocks interconnected by branching (br) instructions. For those familiar with assembly language, a block is similar to a labeled set of instructions. For those not familiar with assembly language, a block is basically a set of instructions that can be branched to and is executed linearly until the block is terminated by one of a small number of control flow instructions, such as br or ret.

-

Blocks corresponds to the nodes in the diagram we looked at in the beginning of this tutorial. From the diagram, we can see that this function contains five blocks, so we'll go ahead and create them. Note that, in this code sample, we're making use of LLVM's automatic name uniquing, since we're giving two blocks the same name.

+

Blocks correspond to the nodes in the diagram we looked at in the beginning of this tutorial. From the diagram, we can see that this function contains five blocks, so we'll go ahead and create them. Note that we're making use of LLVM's automatic name uniquing in this code sample, since we're giving two blocks the same name.

@@ -106,7 +106,7 @@ Module* makeLLVMModule() {
-

Now, we're ready to begin generate code! We'll start with the entry block. This block corresponds to the top-level if-statement in the original C code, so we need to compare x == y To achieve this, we perform an explicity comparison using ICmpEQ. ICmpEQ stands for an integer comparison for equality and returns a 1-bit integer result. This 1-bit result is then used as the input to a conditional branch, with ret as the true and cond_false as the false case.

+

Now we're ready to begin generating code! We'll start with the entry block. This block corresponds to the top-level if-statement in the original C code, so we need to compare x and y. To achieve this, we perform an explicit comparison using ICmpEQ. ICmpEQ stands for an integer comparison for equality and returns a 1-bit integer result. This 1-bit result is then used as the input to a conditional branch, with ret as the true and cond_false as the false case.

@@ -116,7 +116,7 @@ Module* makeLLVMModule() {
-

Our next block, ret, is pretty simple: it just returns the value of x. Recall that this block is only reached if x == y, so this is the correct behavior. Notice that, instead of creating a new LLVMBuilder for each block, we can use SetInsertPoint to retarget our existing one. This saves on construction and memory allocation costs.

+

Our next block, ret, is pretty simple: it just returns the value of x. Recall that this block is only reached if x == y, so this is the correct behavior. Notice that instead of creating a new LLVMBuilder for each block, we can use SetInsertPoint to retarget our existing one. This saves on construction and memory allocation costs.

@@ -127,7 +127,7 @@ Module* makeLLVMModule() {
 
 
cond_false is a more interesting block: we now know that x != y, so we must branch again to determine which of x and y is larger.  This is achieved using the ICmpULT instruction, which stands for integer comparison for unsigned less-than.  In LLVM, integer types do not carry sign; a 32-bit integer pseudo-register can interpreted as signed or unsigned without casting.  Whether a signed or unsigned interpretation is desired is specified in the instruction.  This is why several instructions in the LLVM IR, such as integer less-than, include a specifier for signed or unsigned.

 
-
Also, note that we're again making use of LLVM's automatic name uniquing, this time at a register level.  We've deliberately chosen to name every instruction "tmp", to illustrate that LLVM will give them all unique names without getting confused.

+
Also note that we're again making use of LLVM's automatic name uniquing, this time at a register level.  We've deliberately chosen to name every instruction "tmp" to illustrate that LLVM will give them all unique names without getting confused.

 
 

 
-- 
cgit v1.2.3