<li><a href="#dss_indexedmap">"llvm/ADT/IndexedMap.h"</a></li>
<li><a href="#dss_densemap">"llvm/ADT/DenseMap.h"</a></li>
<li><a href="#dss_valuemap">"llvm/ADT/ValueMap.h"</a></li>
+ <li><a href="#dss_intervalmap">"llvm/ADT/IntervalMap.h"</a></li>
<li><a href="#dss_map"><map></a></li>
<li><a href="#dss_othermap">Other Map-Like Container Options</a></li>
</ul></li>
<ol>
-<li><a href="http://www.dinkumware.com/refxcpp.html">Dinkumware C++ Library
-reference</a> - an excellent reference for the STL and other parts of the
-standard C++ library.</li>
+<li><a href="http://www.dinkumware.com/manuals/#Standard C++ Library">Dinkumware
+C++ Library reference</a> - an excellent reference for the STL and other parts
+of the standard C++ library.</li>
<li><a href="http://www.tempest-sw.com/cpp/">C++ In a Nutshell</a> - This is an
O'Reilly book in the making. It has a decent Standard Library
<div class="doc_text">
<ol>
-<li><a href="http://www.psc.edu/%7Esemke/cvs_branches.html">CVS
-Branch and Tag Primer</a></li>
<li><a href="http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html">Using
static and shared libraries across platforms</a></li>
</ol>
may have embedded null characters. Therefore, they cannot simply take
a <tt>const char *</tt>, and taking a <tt>const std::string&</tt> requires
clients to perform a heap allocation which is usually unnecessary. Instead,
-many LLVM APIs use a <tt>const StringRef&</tt> or a <tt>const
-Twine&</tt> for passing strings efficiently.</p>
+many LLVM APIs use a <tt>StringRef</tt> or a <tt>const Twine&</tt> for
+passing strings efficiently.</p>
</div>
an <tt>std::string</tt>, or explicitly with a character pointer and length.
For example, the <tt>StringRef</tt> find function is declared as:</p>
-<div class="doc_code">
- iterator find(const StringRef &Key);
-</div>
+<pre class="doc_code">
+ iterator find(StringRef Key);
+</pre>
<p>and clients can call it using any one of:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
Map.find("foo"); <i>// Lookup "foo"</i>
Map.find(std::string("bar")); <i>// Lookup "bar"</i>
Map.find(StringRef("\0baz", 4)); <i>// Lookup "\0baz"</i>
</pre>
-</div>
<p>Similarly, APIs which need to return a string may return a <tt>StringRef</tt>
instance, which can be used directly or converted to an <tt>std::string</tt>
<p>You should rarely use the <tt>StringRef</tt> class directly, because it contains
pointers to external memory it is not generally safe to store an instance of the
-class (unless you know that the external storage will not be freed).</p>
+class (unless you know that the external storage will not be freed). StringRef is
+small and pervasive enough in LLVM that it should always be passed by value.</p>
</div>
<p>The StringMap is very fast for several reasons: quadratic probing is very
cache efficient for lookups, the hash value of strings in buckets is not
-recomputed when lookup up an element, StringMap rarely has to touch the
+recomputed when looking up an element, StringMap rarely has to touch the
memory for unrelated objects when looking up a value (even when hash collisions
happen), hash table growth does not recompute the hash values for strings
already in the table, and each pair in the map is store in a single allocation
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="dss_intervalmap">"llvm/ADT/IntervalMap.h"</a>
+</div>
+
+<div class="doc_text">
+
+<p> IntervalMap is a compact map for small keys and values. It maps key
+intervals instead of single keys, and it will automatically coalesce adjacent
+intervals. When then map only contains a few intervals, they are stored in the
+map object itself to avoid allocations.</p>
+
+<p> The IntervalMap iterators are quite big, so they should not be passed around
+as STL iterators. The heavyweight iterators allow a smaller data structure.</p>
+
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="dss_map"><map></a>
<p>Unfortunately, these implicit conversions come at a cost; they prevent
these iterators from conforming to standard iterator conventions, and thus
-from being usable with standard algorithms and containers. For example, it
-prevents the following code, where <tt>B</tt> is a <tt>BasicBlock</tt>,
+from being usable with standard algorithms and containers. For example, they
+prevent the following code, where <tt>B</tt> is a <tt>BasicBlock</tt>,
from compiling:</p>
<div class="doc_code">
</div>
<p>Because of this, these implicit conversions may be removed some day,
-and <tt>operator*</tt> changed to return a pointer instead of a reference.
+and <tt>operator*</tt> changed to return a pointer instead of a reference.</p>
</div>
</pre>
</div>
-Note that dereferencing a <tt>Value::use_iterator</tt> is not a very cheap
+<p>Note that dereferencing a <tt>Value::use_iterator</tt> is not a very cheap
operation. Instead of performing <tt>*i</tt> above several times, consider
-doing it only once in the loop body and reusing its result.
+doing it only once in the loop body and reusing its result.</p>
<p>Alternatively, it's common to have an instance of the <a
href="/doxygen/classllvm_1_1User.html">User Class</a> and need to know what
</div>
<p>Declaring objects as <tt>const</tt> is an important tool of enforcing
-mutation free algorithms (such as analyses etc.). For this purpose above
+mutation free algorithms (such as analyses, etc.). For this purpose above
iterators come in constant flavors as <tt>Value::const_use_iterator</tt>
and <tt>Value::const_op_iterator</tt>. They automatically arise when
calling <tt>use/op_begin()</tt> on <tt>const Value*</tt>s or
<tt>const User*</tt>s respectively. Upon dereferencing, they return
-<tt>const Use*</tt>s. Otherwise the above patterns remain unchanged.
+<tt>const Use*</tt>s. Otherwise the above patterns remain unchanged.</p>
+
</div>
<!--_______________________________________________________________________-->
<div class="doc_text">
<p>Deleting an instruction from an existing sequence of instructions that form a
-<a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward. First,
-you must have a pointer to the instruction that you wish to delete. Second, you
-need to obtain the pointer to that instruction's basic block. You use the
-pointer to the basic block to get its list of instructions and then use the
-erase function to remove your instruction. For example:</p>
+<a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward: just
+call the instruction's eraseFromParent() method. For example:</p>
<div class="doc_code">
<pre>
</pre>
</div>
+<p>This unlinks the instruction from its containing basic block and deletes
+it. If you'd just like to unlink the instruction from its containing basic
+block but not delete it, you can use the <tt>removeFromParent()</tt> method.</p>
+
</div>
<!--_______________________________________________________________________-->
<dt><tt><a name="FunctionType">FunctionType</a></tt></dt>
<dd>Subclass of DerivedTypes for function types.
<ul>
- <li><tt>bool isVarArg() const</tt>: Returns true if its a vararg
+ <li><tt>bool isVarArg() const</tt>: Returns true if it's a vararg
function</li>
<li><tt> const Type * getReturnType() const</tt>: Returns the
return type of the function.</li>
<ul>
<li><tt>Value::use_iterator</tt> - Typedef for iterator over the
use-list<br>
- <tt>Value::use_const_iterator</tt> - Typedef for const_iterator over
+ <tt>Value::const_use_iterator</tt> - Typedef for const_iterator over
the use-list<br>
<tt>unsigned use_size()</tt> - Returns the number of users of the
value.<br>
Class</a><br>
Superclass: <a href="#Value"><tt>Value</tt></a></p>
-<p>This class represents a single entry multiple exit section of the code,
+<p>This class represents a single entry single exit section of the code,
commonly known as a basic block by the compiler community. The
<tt>BasicBlock</tt> class maintains a list of <a
href="#Instruction"><tt>Instruction</tt></a>s, which form the body of the block.