LLVM Programmer's Manual

From 261efe953b14da0446ba5bcafa7f01f247106e9f Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Tue, 25 Nov 2003 01:02:51 +0000 Subject: checkin reid's docpatch git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10200 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ProgrammersManual.html | 3292 +++++++++++++++++++++---------------------- 1 file changed, 1568 insertions(+), 1724 deletions(-) (limited to 'docs/ProgrammersManual.html') diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index bacb0d6b81..1ac08b42f4 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -1,68 +1,75 @@ -LLVM Programmer's Manual - - - - - -

LLVM Programmer's Manual

- + + + LLVM Programmer's Manual + + + + + + + + +

LLVM Programmer's Manual

Introduction +
Introduction
General Information -
- The C++ Standard Template Library - -
+-->
Important and useful LLVM APIs -
-
Helpful Hints for Common Operations -
+-->
The Core LLVM Class Hierarchy Reference -
- The Value class
  - The User class -
    - The Instruction class -
      - -
      -
    - The GlobalValue class +
    - The Value class
      - The BasicBlock class -
      - The Function class -
      - The GlobalVariable class +
      - The User class +
        +
        The Instruction class +
        +
        The GetElementPtrInst class
        +
        +
        +
        +
        The GlobalValue class +
        +
        The BasicBlock +class
        +
        The Function class
        +
        The GlobalVariable +class
        +
        +
        +
        The Module class
        +
        The Constant class +
        +
        
        +
        +
        
        +
        +
        +
        +
        +
      - The Type class
      - The Argument class
      -
    - The Module class -
    - The Constant class +
    - The SymbolTable class
    - The ilist and iplist classes
      - -
      - +
      - Creating, inserting, moving and deleting from LLVM lists
      -
    -
  - The Type class -
  - The Argument class -
  -
- The SymbolTable class -
- The ilist and iplist classes -
  - Creating, inserting, moving and deleting from LLVM lists +
  - Important iterator invalidation semantics to be aware of
  -
- Important iterator invalidation semantics to be aware of -
- -
Written by Chris Lattner, - Dinakar Dhurjati, and - Joel Stanley
+
Written by Chris Lattner,Dinakar Dhurjati, and Joel Stanley
+

+

- - - - -

-Introduction -

- -This document should get you oriented so that you can find your way in the -continuously growing source code that makes up the LLVM infrastructure. Note -that this manual is not intended to serve as a replacement for reading the -source code, so if you think there should be a method in one of these classes to -do something, but it's not listed, check the source. Links to the doxygen sources are provided to make this as easy as -possible.

- -The first section of this document describes general information that is useful -to know when working in the LLVM infrastructure, and the second describes the -Core LLVM classes. In the future this manual will be extended with information -describing how to use extension libraries, such as dominator information, CFG -traversal routines, and useful utilities like the InstVisitor template.

- - - -

-General Information -

Introduction

- - - -

- -The C++ Standard Template Library -

- -Here are some useful links:

- -

Dinkumware C++ -Library reference - an excellent reference for the STL and other parts of -the standard C++ library. - -
C++ In a Nutshell - This is an -O'Reilly book in the making. It has a decent Standard Library -Reference that rivals Dinkumware's, and is actually free until the book is -published. - -
C++ Frequently Asked -Questions - -
SGI's STL Programmer's Guide - -Contains a useful Introduction to the -STL. - -
Bjarne Stroustrup's C++ -Page - -

- -You are also encouraged to take a look at the LLVM Coding Standards guide which focuses on how -to write maintainable code more than where to put your curly braces.

- - -

- -Other useful references -

- -

CVS Branch and Tag -Primer

- +This document is meant to highlight some of the important classes and +interfaces available in the LLVM source-base. This manual is not +intended to explain what LLVM is, how it works, and what LLVM code looks +like. It assumes that you know the basics of LLVM and are interested +in writing transformations or otherwise analyzing or manipulating the +code. +

This document should get you oriented so that you can find your +way in the continuously growing source code that makes up the LLVM +infrastructure. Note that this manual is not intended to serve as a +replacement for reading the source code, so if you think there should be +a method in one of these classes to do something, but it's not listed, +check the source. Links to the doxygen sources +are provided to make this as easy as possible.

The first section of this document describes general information +that is useful to know when working in the LLVM infrastructure, and the +second describes the Core LLVM classes. In the future this manual will +be extended with information describing how to use extension libraries, +such as dominator information, CFG traversal routines, and useful +utilities like the InstVisitor +template.

General Information

-Important and useful LLVM APIs -

The C++ Standard Template +Library

Here are some useful links:

Dinkumware C++ +Library reference - an excellent reference for the STL and other +parts of the standard C++ library.
C++ In a Nutshell - +This is an O'Reilly book in the making. It has a decent Standard Library +Reference that rivals Dinkumware's, and is actually free until the +book is published.
C++ Frequently +Asked Questions
SGI's STL Programmer's +Guide - Contains a useful Introduction +to the STL.
Bjarne +Stroustrup's C++ Page

You are also encouraged to take a look at the LLVM Coding Standards guide which +focuses on how to write maintainable code more than where to put your +curly braces.

Other useful references

CVS +Branch and Tag Primer

Important and useful LLVM +APIs

- - -

- -The isa<>, cast<> and dyn_cast<> templates -

dynamic_cast<>

Support/Casting.h

- -

isa<>: - -

The isa<> operator works exactly like the Java -"instanceof" operator. It returns true or false depending on whether a -reference or pointer points to an instance of the specified class. This can be -very useful for constraint checking of various sorts (example below).

- - -

cast<>: - -

The cast<> operator is a "checked cast" operation. It -converts a pointer or reference from a base class to a derived cast, causing an -assertion failure if it is not really an instance of the right type. This -should be used in cases where you have some information that makes you believe -that something is of the right type. An example of the isa<> and -cast<> template is:

- -

-static bool isLoopInvariant(const Value *V, const Loop *L) {
-  if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))
-    return true;
-
-  // Otherwise, it must be an instruction...
-  return !L->contains(cast<Instruction>(V)->getParent());
-

- -Note that you should not use an isa<> test followed by a -cast<>, for that use the dyn_cast<> operator.

- - -

dyn_cast<>: - -

The dyn_cast<> operator is a "checking cast" operation. It -checks to see if the operand is of the specified type, and if so, returns a -pointer to it (this operator does not work with references). If the operand is -not of the correct type, a null pointer is returned. Thus, this works very much -like the dynamic_cast operator in C++, and should be used in the same -circumstances. Typically, the dyn_cast<> operator is used in an -if statement or some other flow control statement like this:

- -

-  if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {
-    ...
-  }
-

- -This form of the if statement effectively combines together a call to -isa<> and a call to cast<> into one statement, -which is very convenient.

- -Another common example is:

- -

-  // Loop over all of the phi nodes in a basic block
-  BasicBlock::iterator BBI = BB->begin();
-  for (; PHINode *PN = dyn_cast<PHINode>(BBI); ++BBI)
-    cerr << *PN;
-

- -Note that the dyn_cast<> operator, like C++'s -dynamic_cast or Java's instanceof operator, can be abused. In -particular you should not use big chained if/then/else blocks to check -for lots of different variants of classes. If you find yourself wanting to do -this, it is much cleaner and more efficient to use the InstVisitor class to -dispatch over the instruction type directly.

- - -

cast_or_null<>: - -

The cast_or_null<> operator works just like the -cast<> operator, except that it allows for a null pointer as an -argument (which it then propagates). This can sometimes be useful, allowing you -to combine several null checks into one.

- - -

dyn_cast_or_null<>: - -

The dyn_cast_or_null<> operator works just like the -dyn_cast<> operator, except that it allows for a null pointer as -an argument (which it then propagates). This can sometimes be useful, allowing -you to combine several null checks into one.

- -

classof

- - - -

- -The DEBUG() macro & -debug option -

- -Naturally, because of this, you don't want to delete the debug printouts, but -you don't want them to always be noisy. A standard compromise is to comment -them out, allowing you to enable them if you need them in the future.

- -The "Support/Debug.h" file -provides a macro named DEBUG() that is a much nicer solution to this -problem. Basically, you can put arbitrary code into the argument of the -DEBUG macro, and it is only executed if 'opt' (or any other -tool) is run with the '-debug' command line argument: - -

-     ... 
-     DEBUG(std::cerr << "I am here!\n");
-     ...
-

- -Then you can run your pass like this:

- -

-  $ opt < a.bc > /dev/null -mypass
-    <no output>
-  $ opt < a.bc > /dev/null -mypass -debug
-    I am here!
-  $
-

- -Using the DEBUG() macro instead of a home-brewed solution allows you to -now have to create "yet another" command line option for the debug output for -your pass. Note that DEBUG() macros are disabled for optimized builds, -so they do not cause a performance impact at all (for the same reason, they -should also not contain side-effects!).

- -One additional nice thing about the DEBUG() macro is that you can -enable or disable it directly in gdb. Just use "set DebugFlag=0" or -"set DebugFlag=1" from the gdb if the program is running. If the -program hasn't been started yet, you can always just run it with --debug.

- - -

Fine grained debug info with - `DEBUG_TYPE()` and the `-debug-only` option

The isa<>, +cast<> and dyn_cast<> templates

dynamic_cast<>

Support/Casting.h

isa<>:

The isa<> operator works exactly like the Java "instanceof" +operator. It returns true or false depending on whether a reference or +pointer points to an instance of the specified class. This can be very +useful for constraint checking of various sorts (example below). +

cast<>:

The cast<> operator is a "checked cast" +operation. It converts a pointer or reference from a base class to a +derived cast, causing an assertion failure if it is not really an +instance of the right type. This should be used in cases where you have +some information that makes you believe that something is of the right +type. An example of the isa<> and cast<> +template is: +

static bool isLoopInvariant(const Value *V, const Loop *L) {
  if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))
    return true;

  // Otherwise, it must be an instruction...
  return !L->contains(cast<Instruction>(V)->getParent());

Note that you should not use an isa<> +test followed by a cast<>, for that use the dyn_cast<> +operator.

dyn_cast<>:

The dyn_cast<> operator is a "checking cast" +operation. It checks to see if the operand is of the specified type, and +if so, returns a pointer to it (this operator does not work with +references). If the operand is not of the correct type, a null pointer +is returned. Thus, this works very much like the dynamic_cast +operator in C++, and should be used in the same circumstances. +Typically, the dyn_cast<> operator is used in an if +statement or some other flow control statement like this: +

  if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {
    ...
  }

This form of the if statement effectively combines +together a call to isa<> and a call to cast<> +into one statement, which is very convenient.

Another common example is:

  // Loop over all of the phi nodes in a basic block
  BasicBlock::iterator BBI = BB->begin();
  for (; PHINode *PN = dyn_cast<PHINode>(BBI); ++BBI)
    cerr << *PN;

Note that the dyn_cast<> operator, like C++'s dynamic_cast +or Java's instanceof operator, can be abused. In particular +you should not use big chained if/then/else blocks to check for +lots of different variants of classes. If you find yourself wanting to +do this, it is much cleaner and more efficient to use the InstVisitor +class to dispatch over the instruction type directly.

cast_or_null<>:

The cast_or_null<> operator works just like the cast<> +operator, except that it allows for a null pointer as an argument (which +it then propagates). This can sometimes be useful, allowing you to +combine several null checks into one. +

dyn_cast_or_null<>:

The dyn_cast_or_null<> operator works just like +the dyn_cast<> operator, except that it allows for a null +pointer as an argument (which it then propagates). This can sometimes +be useful, allowing you to combine several null checks into one. +

classof

The DEBUG() macro +& -debug option

Naturally, because of this, you don't want to delete the debug +printouts, but you don't want them to always be noisy. A standard +compromise is to comment them out, allowing you to enable them if you +need them in the future.

The "Support/Debug.h" +file provides a macro named DEBUG() that is a much nicer +solution to this problem. Basically, you can put arbitrary code into +the argument of the DEBUG macro, and it is only executed if 'opt' +(or any other tool) is run with the '-debug' command line +argument:

     ... 
     DEBUG(std::cerr << "I am here!\n");
     ...

Then you can run your pass like this:

  $ opt < a.bc > /dev/null -mypass
    <no output>
  $ opt < a.bc > /dev/null -mypass -debug
    I am here!
  $

Using the DEBUG() macro instead of a home-brewed solution +allows you to now have to create "yet another" command line option for +the debug output for your pass. Note that DEBUG() macros are +disabled for optimized builds, so they do not cause a performance impact +at all (for the same reason, they should also not contain +side-effects!).

One additional nice thing about the DEBUG() macro is that +you can enable or disable it directly in gdb. Just use "set +DebugFlag=0" or "set DebugFlag=1" from the gdb if the +program is running. If the program hasn't been started yet, you can +always just run it with -debug.

+
Fine grained debug info with `DEBUG_TYPE()` and the `-debug-only` +option

-debug

too much

DEBUG_TYPE

-debug

- -

-     ...
-     DEBUG(std::cerr << "No debug type\n");
-     #undef  DEBUG_TYPE
-     #define DEBUG_TYPE "foo"
-     DEBUG(std::cerr << "'foo' debug type\n");
-     #undef  DEBUG_TYPE
-     #define DEBUG_TYPE "bar"
-     DEBUG(std::cerr << "'bar' debug type\n");
-     #undef  DEBUG_TYPE
-     #define DEBUG_TYPE ""
-     DEBUG(std::cerr << "No debug type (2)\n");
-     ...
-

- -Then you can run your pass like this:

- -

-  $ opt < a.bc > /dev/null -mypass
-    <no output>
-  $ opt < a.bc > /dev/null -mypass -debug
-    No debug type
-    'foo' debug type
-    'bar' debug type
-    No debug type (2)
-  $ opt < a.bc > /dev/null -mypass -debug-only=foo
-    'foo' debug type
-  $ opt < a.bc > /dev/null -mypass -debug-only=bar
-    'bar' debug type
-  $
-

- -Of course, in practice, you should only set DEBUG_TYPE at the top of a -file, to specify the debug type for the entire module (if you do this before you -#include "Support/Debug.h", you don't have to insert the ugly -#undef's). Also, you should use names more meaningful that "foo" and -"bar", because there is no system in place to ensure that names do not conflict: -if two different modules use the same string, they will all be turned on when -the name is specified. This allows all, say, instruction scheduling, debug -information to be enabled with -debug-type=InstrSched, even if the -source lives in multiple files.

- - - -

- -The Statistic template & -stats -option -

Support/Statistic.h

Statistic

- -Often you may run your pass on some big program, and you're interested to see -how many times it makes a certain transformation. Although you can do this with -hand inspection, or some ad-hoc method, this is a real pain and not very useful -for big programs. Using the Statistic template makes it very easy to -keep track of this information, and the calculated information is presented in a -uniform manner with the rest of the passes being executed.

- -There are many examples of Statistic users, but this basics of using it -are as follows:

- -

Define your statistic like this:
- -
```
-static Statistic<> NumXForms("mypassname", "The # of times I did stuff");
-
```
- -The Statistic template can emulate just about any data-type, but if you -do not specify a template argument, it defaults to acting like an unsigned int -counter (this is usually what you want).
- -
Whenever you make a transformation, bump the counter:
- -
```
-   ++NumXForms;   // I did stuff
-
```
- -

- -That's all you have to do. To get 'opt' to print out the statistics -gathered, use the '-stats' option:

- -

-   $ opt -stats -mypassname < program.bc > /dev/null
-    ... statistic output ...
-

- -When running gccas on a C file from the SPEC benchmark suite, it gives -a report that looks like this:

- -

-   7646 bytecodewriter  - Number of normal instructions
-    725 bytecodewriter  - Number of oversized instructions
- 129996 bytecodewriter  - Number of bytecode bytes written
-   2817 raise           - Number of insts DCEd or constprop'd
-   3213 raise           - Number of cast-of-self removed
-   5046 raise           - Number of expression trees converted
-     75 raise           - Number of other getelementptr's formed
-    138 raise           - Number of load/store peepholes
-     42 deadtypeelim    - Number of unused typenames removed from symtab
-    392 funcresolve     - Number of varargs functions resolved
-     27 globaldce       - Number of global variables removed
-      2 adce            - Number of basic blocks removed
-    134 cee             - Number of branches revectored
-     49 cee             - Number of setcc instruction eliminated
-    532 gcse            - Number of loads removed
-   2919 gcse            - Number of instructions removed
-     86 indvars         - Number of canonical indvars added
-     87 indvars         - Number of aux indvars removed
-     25 instcombine     - Number of dead inst eliminate
-    434 instcombine     - Number of insts combined
-    248 licm            - Number of load insts hoisted
-   1298 licm            - Number of insts hoisted to a loop pre-header
-      3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
-     75 mem2reg         - Number of alloca's promoted
-   1444 cfgsimplify     - Number of blocks simplified
-

- -Obviously, with so many optimizations, having a unified framework for this stuff -is very nice. Making your pass fit well into the framework makes it more -maintainable and useful.

- - - -

-Helpful Hints for Common Operations -

The Statistic +template & -stats option

Support/Statistic.h

Statistic

Often you may run your pass on some big program, and you're +interested to see how many times it makes a certain transformation. +Although you can do this with hand inspection, or some ad-hoc method, +this is a real pain and not very useful for big programs. Using the Statistic +template makes it very easy to keep track of this information, and the +calculated information is presented in a uniform manner with the rest of +the passes being executed.

There are many examples of Statistic uses, but the basics +of using it are as follows:

Define your statistic like this: +

+
```
static Statistic<> NumXForms("mypassname", "The # of times I did stuff");
```
+
The Statistic template can emulate just about any +data-type, but if you do not specify a template argument, it defaults to +acting like an unsigned int counter (this is usually what you want).
+

+
Whenever you make a transformation, bump the counter: +

+
```
   ++NumXForms;   // I did stuff
```
+

+

That's all you have to do. To get 'opt' to print out the +statistics gathered, use the '-stats' option:

   $ opt -stats -mypassname < program.bc > /dev/null
    ... statistic output ...

When running gccas on a C file from the SPEC benchmark +suite, it gives a report that looks like this:

   7646 bytecodewriter  - Number of normal instructions
    725 bytecodewriter  - Number of oversized instructions
 129996 bytecodewriter  - Number of bytecode bytes written
   2817 raise           - Number of insts DCEd or constprop'd
   3213 raise           - Number of cast-of-self removed
   5046 raise           - Number of expression trees converted
     75 raise           - Number of other getelementptr's formed
    138 raise           - Number of load/store peepholes
     42 deadtypeelim    - Number of unused typenames removed from symtab
    392 funcresolve     - Number of varargs functions resolved
     27 globaldce       - Number of global variables removed
      2 adce            - Number of basic blocks removed
    134 cee             - Number of branches revectored
     49 cee             - Number of setcc instruction eliminated
    532 gcse            - Number of loads removed
   2919 gcse            - Number of instructions removed
     86 indvars         - Number of canonical indvars added
     87 indvars         - Number of aux indvars removed
     25 instcombine     - Number of dead inst eliminate
    434 instcombine     - Number of insts combined
    248 licm            - Number of load insts hoisted
   1298 licm            - Number of insts hoisted to a loop pre-header
      3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
     75 mem2reg         - Number of alloca's promoted
   1444 cfgsimplify     - Number of blocks simplified

Obviously, with so many optimizations, having a unified framework +for this stuff is very nice. Making your pass fit well into the +framework makes it more maintainable and useful.

Helpful Hints for Common +Operations

- -Because this is a "how-to" section, you should also read about the main classes -that you will be working with. The Core LLVM Class -Hierarchy Reference contains details and descriptions of the main classes -that you should know about.

- - - - - -

- -Basic Inspection and Traversal Routines -

XXXbegin()

XXXend()

XXXiterator

- -Because the pattern for iteration is common across many different aspects of the -program representation, the standard template library algorithms may be used on -them, and it is easier to remember how to iterate. First we show a few common -examples of the data structures that need to be traversed. Other data -structures are traversed in very similar ways.

- - - -

Iterating over the `BasicBlock`s in a `Function`

Because this is a "how-to" section, you should also read about the +main classes that you will be working with. The Core +LLVM Class Hierarchy Reference contains details and descriptions of +the main classes that you should know about.

Basic Inspection and +Traversal Routines

XXXbegin()

XXXend()

XXXiterator

Because the pattern for iteration is common across many different +aspects of the program representation, the standard template library +algorithms may be used on them, and it is easier to remember how to +iterate. First we show a few common examples of the data structures that +need to be traversed. Other data structures are traversed in very +similar ways.

+
Iterating over the `BasicBlock`s in a `Function`

Function

BasicBlock

Function

BasicBlock

Instruction

-  // func is a pointer to a Function instance
-  for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) {
-
-      // print out the name of the basic block if it has one, and then the
-      // number of instructions that it contains
-
-      cerr << "Basic block (name=" << i->getName() << ") has " 
-           << i->size() << " instructions.\n";
-  }
-

BasicBlock

Function

BasicBlock

Instruction

  // func is a pointer to a Function instance
  for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) {

      // print out the name of the basic block if it has one, and then the
      // number of instructions that it contains

      cerr << "Basic block (name=" << i->getName() << ") has " 
           << i->size() << " instructions.\n";
  }

Instruction

i->size()

(*i).size()

Iterating over the `Instruction`s in a `BasicBlock`

BasicBlock

Function

BasicBlock

-  // blk is a pointer to a BasicBlock instance
-  for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
-     // the next statement works since operator<<(ostream&,...) 
-     // is overloaded for Instruction&
-     cerr << *i << "\n";
-

BasicBlock

cerr << *blk << -"\n";

- -Note that currently operator<< is implemented for Value*, so it -will print out the contents of the pointer, instead of -the pointer value you might expect. This is a deprecated interface that will -be removed in the future, so it's best not to depend on it. To print out the -pointer value for now, you must cast to void*.

- - - -

Iterating over the `Instruction`s in a `Function`

Function

BasicBlock

Instruction

InstIterator

llvm/Support/InstIterator.h

InstIterator

Note:

InstIterator

Instruction*

not

Instruction&

-#include "llvm/Support/InstIterator.h"
-...
-// Suppose F is a ptr to a function
-for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i)
-  cerr << **i << "\n";
-

(*i).size()

+
Iterating over the `Instruction`s in a `BasicBlock`

BasicBlock

Function

BasicBlock

  // blk is a pointer to a BasicBlock instance
  for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
     // the next statement works since operator<<(ostream&,...) 
     // is overloaded for Instruction&
     cerr << *i << "\n";

BasicBlock

cerr << *blk << "\n";

Note that currently operator<< is implemented for Value*, +so it will print out the contents of the pointer, instead of the +pointer value you might expect. This is a deprecated interface that +will be removed in the future, so it's best not to depend on it. To +print out the pointer value for now, you must cast to void*.

+
Iterating over the `Instruction`s in a `Function`

Function

BasicBlock

Instruction

InstIterator

llvm/Support/InstIterator.h

InstIterator

Note:

InstIterator

Instruction*

not

Instruction&

#include "llvm/Support/InstIterator.h"
...
// Suppose F is a ptr to a function
for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i)
  cerr << **i << "\n";

InstIterator

Function

-std::set<Instruction*> worklist;
-worklist.insert(inst_begin(F), inst_end(F));
-

worklist

Function

Turning an iterator into a class -pointer (and vice-versa)

- +initialize a worklist to contain all instructions in a Function +F, all you would need to do is something like: +

std::set<Instruction*> worklist;
worklist.insert(inst_begin(F), inst_end(F));

+The STL set worklist would now contain all instructions in the Function +pointed to by F. +

+
Turning an iterator into a class +pointer (and vice-versa)

i

BasicBlock::iterator

j

BasicBlock::const_iterator

-    Instruction& inst = *i;   // grab reference to instruction reference
-    Instruction* pinst = &*i; // grab pointer to instruction reference
-    const Instruction& inst = *j;
-

i

BasicBlock::iterator

j

BasicBlock::const_iterator

    Instruction& inst = *i;   // grab reference to instruction reference
    Instruction* pinst = &*i; // grab pointer to instruction reference
    const Instruction& inst = *j;

Instruction* pinst = &*i;

Instruction* pinst = &*i;

Instruction* pinst = i;

Instruction* pinst = i;

-void printNextInstruction(Instruction* inst) {
-    BasicBlock::iterator it(inst);
-    ++it; // after this line, it refers to the instruction after *inst.
-    if (it != inst->getParent()->end()) cerr << *it << "\n";
-}
-

void printNextInstruction(Instruction* inst) {
    BasicBlock::iterator it(inst);
    ++it; // after this line, it refers to the instruction after *inst.
    if (it != inst->getParent()->end()) cerr << *it << "\n";
}

Finding call sites: a slightly -more complex example

- +better to explicitly grab the next instruction directly from inst. +

+
Finding call sites: a slightly +more complex example

Function

InstVisitor

-initialize callCounter to zero
-for each Function f in the Module
-    for each BasicBlock b in f
-      for each Instruction i in b
-        if (i is a CallInst and calls the given function)
-          increment callCounter
-

FunctionPass

runOnFunction

-Function* targetFunc = ...;
-
-class OurFunctionPass : public FunctionPass {
-  public:
-    OurFunctionPass(): c

Fine grained debug info with - DEBUG_TYPE() and the -debug-only option

+Fine grained debug info with DEBUG_TYPE() and the -debug-only +option

Iterating over the BasicBlocks in a Function

+Iterating over the BasicBlocks in a Function

Iterating over the Instructions in a BasicBlock

Iterating over the Instructions in a Function

+Iterating over the Instructions in a BasicBlock

+Iterating over the Instructions in a Function

Turning an iterator into a class -pointer (and vice-versa)

+Turning an iterator into a class +pointer (and vice-versa)

Finding call sites: a slightly -more complex example

+Finding call sites: a slightly +more complex example

Fine grained debug info with - `DEBUG_TYPE()` and the `-debug-only` option

+
Fine grained debug info with `DEBUG_TYPE()` and the `-debug-only` +option

Iterating over the `BasicBlock`s in a `Function`

+
Iterating over the `BasicBlock`s in a `Function`

Iterating over the `Instruction`s in a `BasicBlock`

Iterating over the `Instruction`s in a `Function`

+
Iterating over the `Instruction`s in a `BasicBlock`

+
Iterating over the `Instruction`s in a `Function`

+
Turning an iterator into a class +pointer (and vice-versa)

+
Finding call sites: a slightly +more complex example