X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;ds=sidebyside;f=docs%2FProgrammersManual.html;h=5932aaf727f22c3fa1ebed0ce310cc7e24e9142e;hb=17bcde9f9b18e1076a9f20d1dcd3b4a8e9985352;hp=df8f4abf470087c4e00004e70774bd52f1c3990a;hpb=263a98e4654f9fa6c6078446e21a958a33071d83;p=oota-llvm.git
diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html
index df8f4abf470..5932aaf727f 100644
--- a/docs/ProgrammersManual.html
+++ b/docs/ProgrammersManual.html
@@ -62,6 +62,7 @@ option
A sorted 'vector'
"llvm/ADT/SmallSet.h"
"llvm/ADT/SmallPtrSet.h"
+ "llvm/ADT/DenseSet.h"
"llvm/ADT/FoldingSet.h"
<set>
"llvm/ADT/SetVector.h"
@@ -77,6 +78,11 @@ option
<map>
Other Map-Like Container Options
+ BitVector-like containers
+
Helpful Hints for Common Operations
@@ -97,6 +103,8 @@ complex example
the same way
Iterating over def-use &
use-def chains
+ Iterating over predecessors &
+successors of blocks
Making simple changes
@@ -106,6 +114,7 @@ use-def chains
Deleting Instructions
Replacing an Instruction
with another Value
+ Deleting GlobalVariables
+
+
+
+
+
+DenseSet is a simple quadratically probed hash table. It excels at supporting
+small values: it uses a single allocation to hold all of the pairs that
+are currently inserted in the set. DenseSet is a great way to unique small
+values that are not simple pointers (use SmallPtrSet for pointers). Note that DenseSet has
+the same requirements for the value type that DenseMap has.
+
+
+
+
"llvm/ADT/FoldingSet.h"
@@ -1224,7 +1257,7 @@ iterators in a densemap are invalidated whenever an insertion occurs, unlike
map. Also, because DenseMap allocates space for a large number of key/value
pairs (it starts with 64 by default), it will waste a lot of space if your keys
or values are large. Finally, you must implement a partial specialization of
-DenseMapKeyInfo for the key that you want, if it isn't already supported. This
+DenseMapInfo for the key that you want, if it isn't already supported. This
is required to tell DenseMap about two special marker values (which can never be
inserted into the map) that it needs internally.
@@ -1275,6 +1308,52 @@ expensive. Element iteration does not visit elements in a useful order.
+
+
+
+
+
Unlike the other containers, there are only two bit storage containers, and
+choosing when to use each is relatively straightforward.
+
+
One additional option is
+std::vector<bool>: we discourage its use for two reasons 1) the
+implementation in many common compilers (e.g. commonly available versions of
+GCC) is extremely inefficient and 2) the C++ standards committee is likely to
+deprecate this container and/or change it significantly somehow. In any case,
+please don't use it.
+
+
+
+
+
+
+
The BitVector container provides a fixed size set of bits for manipulation.
+It supports individual bit setting/testing, as well as set operations. The set
+operations take time O(size of bitvector), but operations are performed one word
+at a time, instead of one bit at a time. This makes the BitVector very fast for
+set operations compared to other containers. Use the BitVector when you expect
+the number of set bits to be high (IE a dense set).
+
+
+
+
+
+
+
+
The SparseBitVector container is much like BitVector, with one major
+difference: Only the bits that are set, are stored. This makes the
+SparseBitVector much more space efficient than BitVector when the set is sparse,
+as well as making set operations O(number of set bits) instead of O(size of
+universe). The downside to the SparseBitVector is that setting and testing of random bits is O(N), and on large SparseBitVectors, this can be slower than BitVector. In our implementation, setting or testing bits in sorted order
+(either forwards or reverse) is O(1) worst case. Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1). As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit).
+
+
@@ -1459,7 +1538,7 @@ the last line of the last example,
-Instruction* pinst = &*i;
+Instruction *pinst = &*i;
@@ -1467,7 +1546,7 @@ Instruction* pinst = &*i;
-Instruction* pinst = i;
+Instruction *pinst = i;
@@ -1535,8 +1614,7 @@ class OurFunctionPass : public FunctionPass {
href="#CallInst">CallInst>(&*i)) {
//
We know we've encountered a call instruction, so we
//
need to determine if it's a call to the
- //
function pointed to by m_func or not
-
+ //
function pointed to by m_func or not.
if (callInst->getCalledFunction() == targetFunc)
++callCounter;
}
@@ -1545,7 +1623,7 @@ class OurFunctionPass : public FunctionPass {
}
private:
- unsigned callCounter;
+ unsigned callCounter;
};
@@ -1597,7 +1675,7 @@ of F:
-Function* F = ...;
+Function *F = ...;
for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i)
if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
@@ -1617,10 +1695,10 @@ the particular Instruction):
-Instruction* pi = ...;
+Instruction *pi = ...;
for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
- Value* v = *i;
+ Value *v = *i;
// ...
}
@@ -1633,6 +1711,36 @@ for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i)
+
+
+
+
+
+
Iterating over the predecessors and successors of a block is quite easy
+with the routines defined in "llvm/Support/CFG.h". Just use code like
+this to iterate over all predecessors of BB:
+
+
+
+#include "llvm/Support/CFG.h"
+BasicBlock *BB = ...;
+
+for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
+ BasicBlock *Pred = *PI;
+ // ...
+}
+
+
+
+
Similarly, to iterate over successors use
+succ_iterator/succ_begin/succ_end.
+
+
+
+
Making simple changes
@@ -1665,7 +1773,7 @@ parameters. For example, an
AllocaInst only
requires a
-AllocaInst* ai = new AllocaInst(Type::IntTy);
+AllocaInst* ai = new AllocaInst(Type::Int32Ty);
@@ -1693,7 +1801,7 @@ used as some kind of index by some other code. To accomplish this, I place an
-AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");
+AllocaInst* pa = new AllocaInst(Type::Int32Ty, 0, "indexLoc");
@@ -1806,9 +1914,7 @@ erase function to remove your instruction. For example:
Instruction *I = .. ;
-BasicBlock *BB = I->getParent();
-
-BB->getInstList().erase(I);
+I->eraseFromParent();
@@ -1845,7 +1951,7 @@ AllocaInst* instToReplace = ...;
BasicBlock::iterator ii(instToReplace);
ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
- Constant::getNullValue(PointerType::get(Type::IntTy)));
+ Constant::getNullValue(PointerType::get(Type::Int32Ty)));
ReplaceInstWithInst
@@ -1860,7 +1966,7 @@ AllocaInst* instToReplace = ...;
BasicBlock::iterator ii(instToReplace);
ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
- new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt"));
+ new AllocaInst(Type::Int32Ty, 0, "ptrToReplacedInt"));
@@ -1878,6 +1984,28 @@ ReplaceInstWithValue, ReplaceInstWithInst -->
+
+
+
+
+
+
Deleting a global variable from a module is just as easy as deleting an
+Instruction. First, you must have a pointer to the global variable that you wish
+ to delete. You use this pointer to erase it from its parent, the module.
+ For example:
+
+
+
+
+
Advanced Topics
@@ -1912,7 +2040,7 @@ recursive types and late resolution of opaque types makes the situation very
difficult to handle. Fortunately, for the most part, our implementation makes
most clients able to be completely unaware of the nasty internal details. The
primary case where clients are exposed to the inner workings of it are when
-building a recursive type. In addition to this case, the LLVM bytecode reader,
+building a recursive type. In addition to this case, the LLVM bitcode reader,
assembly parser, and linker also have to be aware of the inner workings of this
system.
@@ -1957,7 +2085,7 @@ To build this, use the following LLVM APIs:
PATypeHolder StructTy = OpaqueType::get();
std::vector<const Type*> Elts;
Elts.push_back(PointerType::get(StructTy));
-Elts.push_back(Type::IntTy);
+Elts.push_back(Type::Int32Ty);
StructType *NewSTy = StructType::get(Elts);
//
At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that
@@ -2195,7 +2323,7 @@ the
lib/VMCore directory.
point type.
StructType
Subclass of DerivedTypes for struct types.
-
FunctionType
+
FunctionType
Subclass of DerivedTypes for function types.
- bool isVarArg() const: Returns true if its a vararg
@@ -2389,7 +2517,7 @@ method. In addition, all LLVM values can be named. The "name" of the
-The name of this instruction is "foo". NOTE
+
The name of this instruction is "foo". NOTE
that the name of any value may be missing (an empty string), so names should
ONLY be used for debugging (making the source code easier to read,
debugging printouts), they should not be used to keep track of values or map
@@ -2621,10 +2749,20 @@ a subclass, which represents the address of a global variable or function.
ConstantInt : This subclass of Constant represents an integer constant of
any width.
- - int64_t getSExtValue() const: Returns the underlying value of
- this constant as a sign extended signed integer value.
- - uint64_t getZExtValue() const: Returns the underlying value
- of this constant as a zero extended unsigned integer value.
+ - const APInt& getValue() const: Returns the underlying
+ value of this constant, an APInt value.
+ - int64_t getSExtValue() const: Converts the underlying APInt
+ value to an int64_t via sign extension. If the value (not the bit width)
+ of the APInt is too large to fit in an int64_t, an assertion will result.
+ For this reason, use of this method is discouraged.
+ - uint64_t getZExtValue() const: Converts the underlying APInt
+ value to a uint64_t via zero extension. IF the value (not the bit width)
+ of the APInt is too large to fit in a uint64_t, an assertion will result.
+ For this reason, use of this method is discouraged.
+ - static ConstantInt* get(const APInt& Val): Returns the
+ ConstantInt object that represents the value provided by Val.
+ The type is implied as the IntegerType that corresponds to the bit width
+ of Val.
- static ConstantInt* get(const Type *Ty, uint64_t Val):
Returns the ConstantInt object that represents the value provided by
Val for integer type Ty.
@@ -2795,7 +2933,7 @@ is its address (after linking) which is guaranteed to be constant.
create and what type of linkage the function should have. The FunctionType argument
specifies the formal arguments and return value for the function. The same
- FunctionType value can be used to
+ FunctionType value can be used to
create multiple functions. The Parent argument specifies the Module
in which the function is defined. If this argument is provided, the function
will automatically be inserted into that module's list of