From 31882b8831b3f82b9a7cce5eaa31eb29f45820cf Mon Sep 17 00:00:00 2001 From: Reid Spencer Date: Sat, 3 Feb 2007 21:06:43 +0000 Subject: [PATCH] Fix some spellos. llvm-svn: 33840 --- llvm/docs/ProgrammersManual.html | 38 ++++++++++++++++---------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/llvm/docs/ProgrammersManual.html b/llvm/docs/ProgrammersManual.html index 022d50bb68f7..4f91254e402d 100644 --- a/llvm/docs/ProgrammersManual.html +++ b/llvm/docs/ProgrammersManual.html @@ -645,14 +645,14 @@ systems with X11, install the graphviz toolkit, and make sure 'dot' and 'gv' are in your path. If you are running on Mac OS/X, download and install the Mac OS/X Graphviz program, and add -/Applications/Graphviz.app/Contents/MacOS/ (or whereever you install +/Applications/Graphviz.app/Contents/MacOS/ (or wherever you install it) to your path. Once in your system and path are set up, rerun the LLVM configure script and rebuild LLVM to enable this functionality.

SelectionDAG has been extended to make it easier to locate interesting nodes in large complex graphs. From gdb, if you call DAG.setGraphColor(node, "color"), then the -next call DAG.viewGraph() would hilight the node in the +next call DAG.viewGraph() would highlight the node in the specified color (choices of colors can be found at colors.) More complex node attributes can be provided with call @@ -671,8 +671,8 @@ attributes, then you can call DAG.clearGraphAttrs().

-

LLVM has a plethora of datastructures in the llvm/ADT/ directory, - and we commonly use STL datastructures. This section describes the tradeoffs +

LLVM has a plethora of data structures in the llvm/ADT/ directory, + and we commonly use STL data structures. This section describes the trade-offs you should consider when you pick one.

@@ -682,7 +682,7 @@ thing when choosing a container is the algorithmic properties of how you plan to access the container. Based on that, you should use:

    -
  • a map-like container if you need efficient lookup +
  • a map-like container if you need efficient look-up of an value based on another value. Map-like containers also support efficient queries for containment (whether a key is in the map). Map-like containers generally do not support efficient reverse mapping (values to @@ -701,15 +701,15 @@ access the container. Based on that, you should use:

  • a sequential container provides the most efficient way to add elements and keeps track of the order they are added to the collection. They permit duplicates and support efficient - iteration, but do not support efficient lookup based on a key. + iteration, but do not support efficient look-up based on a key.

-Once the proper catagory of container is determined, you can fine tune the +Once the proper category of container is determined, you can fine tune the memory use, constant factors, and cache behaviors of access by intelligently -picking a member of the catagory. Note that constant factors and cache behavior +picking a member of the category. Note that constant factors and cache behavior can be a big deal. If you have a vector that usually only contains a few elements (but could contain many), for example, it's much better to use SmallVector than vector @@ -751,7 +751,7 @@ before the array is allocated, and if the array is usually large (if not, consider a SmallVector). The cost of a heap allocated array is the cost of the new/delete (aka malloc/free). Also note that if you are allocating an array of a type with a constructor, the constructor and -destructors will be run for every element in the array (resizable vectors only +destructors will be run for every element in the array (re-sizable vectors only construct those elements actually used).

@@ -912,7 +912,7 @@ efficiently queried with a standard binary or radix search.

-

If you have a set-like datastructure that is usually small and whose elements +

If you have a set-like data structure that is usually small and whose elements are reasonably small, a SmallSet<Type, N> is a good choice. This set has space for N elements in place (thus, if the set is dynamically smaller than N, no malloc traffic is required) and accesses them with a simple linear search. @@ -936,7 +936,7 @@ and erasing, but does not support iteration.

SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is -transparently implemented with a SmallPtrSet), but also suports iterators. If +transparently implemented with a SmallPtrSet), but also supports iterators. If more than 'N' insertions are performed, a single quadratically probed hash table is allocated and grows as needed, providing extremely efficient access (constant time insertion/deleting/queries with low constant @@ -1126,7 +1126,7 @@ Strings are commonly used as keys in maps, and they are difficult to support efficiently: they are variable length, inefficient to hash and compare when long, expensive to copy, etc. CStringMap is a specialized container designed to cope with these issues. It supports mapping an arbitrary range of bytes that -does not have an embedded nul character in it ("C strings") to an arbitrary +does not have an embedded null character in it ("C strings") to an arbitrary other object.

The CStringMap implementation uses a quadratically-probed hash table, where @@ -1369,15 +1369,15 @@ small example that shows how to dump all instructions in a function to the stand 

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

Easy, isn't it? You can also use InstIterators to fill a -worklist with its initial contents. For example, if you wanted to -initialize a worklist to contain all instructions in a Function +work list with its initial contents. For example, if you wanted to +initialize a work list to contain all instructions in a Function F, all you would need to do is something like:

@@ -1467,7 +1467,7 @@ locations in the entire module (that is, across every Function) where a certain function (i.e., some Function*) is already in scope. As you'll learn later, you may want to use an InstVisitor to accomplish this in a much more straight-forward manner, but this example will allow us to explore how -you'd do it if you didn't have InstVisitor around. In pseudocode, this +you'd do it if you didn't have InstVisitor around. In pseudo-code, this is what we want to do:

@@ -1635,7 +1635,7 @@ AllocaInst* ai = new AllocaInst(Type::IntTy);

will create an AllocaInst instance that represents the allocation of -one integer in the current stack frame, at runtime. Each Instruction +one integer in the current stack frame, at run time. Each Instruction subclass is likely to have varying default parameters which change the semantics of the instruction, so refer to the doxygen documentation for the subclass of @@ -1649,7 +1649,7 @@ at generated LLVM machine code, you definitely want to have logical names associated with the results of instructions! By supplying a value for the Name (default) parameter of the Instruction constructor, you associate a logical name with the result of the instruction's execution at -runtime. For example, say that I'm writing a transformation that dynamically +run time. For example, say that I'm writing a transformation that dynamically allocates space for an integer on the stack, and that integer is going to be used as some kind of index by some other code. To accomplish this, I place an AllocaInst at the first point in the first BasicBlock of some @@ -1663,7 +1663,7 @@ AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");

where indexLoc is now the logical name of the instruction's -execution value, which is a pointer to an integer on the runtime stack.

+execution value, which is a pointer to an integer on the run time stack.

Inserting instructions