the fact that <tt>dynamic_cast<></tt> only works on classes that
have a v-table). Because they are used so often, you must know what they
do and how they work. All of these templates are defined in the <a
- href="/doxygen/Casting_8h-source.html"><tt>Support/Casting.h</tt></a>
+ href="/doxygen/Casting_8h-source.html"><tt>llvm/Support/Casting.h</tt></a>
file (note that you very rarely have to include this file directly).</p>
<dl>
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.</p>
-<p>The "<tt><a href="/doxygen/Debug_8h-source.html">Support/Debug.h</a></tt>"
+<p>The "<tt><a href="/doxygen/Debug_8h-source.html">llvm/Support/Debug.h</a></tt>"
file provides a macro named <tt>DEBUG()</tt> that is a much nicer solution to
this problem. Basically, you can put arbitrary code into the argument of the
<tt>DEBUG</tt> macro, and it is only executed if '<tt>opt</tt>' (or any other
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE()</tt> and
+ <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and
the <tt>-debug-only</tt> option</a>
</div>
<p>Of course, in practice, you should only set <tt>DEBUG_TYPE</tt> at the top of
a file, to specify the debug type for the entire module (if you do this before
-you <tt>#include "Support/Debug.h"</tt>, you don't have to insert the ugly
+you <tt>#include "llvm/Support/Debug.h"</tt>, you don't have to insert the ugly
<tt>#undef</tt>'s). Also, you should use names more meaningful than "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
<div class="doc_text">
<p>The "<tt><a
-href="/doxygen/Statistic_8h-source.html">Support/Statistic.h</a></tt>" file
+href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file
provides a template named <tt>Statistic</tt> that is used as a unified way to
keep track of what the LLVM compiler is doing and how effective various
optimizations are. It is useful to see what optimizations are contributing to
system.
</p>
+<p>
+For our purposes below, we need three concepts. First, an "Opaque Type" is
+exactly as defined in the <a href="LangRef.html#t_opaque">language
+reference</a>. Second an "Abstract Type" is any type which includes an
+opaque type as part of its type graph (for example "<tt>{ opaque, int }</tt>").
+Third, a concrete type is a type that is not an abstract type (e.g. "<tt>[ int,
+float }</tt>").
+</p>
+
</div>
<!-- ______________________________________________________________________ -->
To support this, a class can derive from the AbstractTypeUser class. This class
allows it to get callbacks when certain types are resolved. To register to get
callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser
-methods can be called on a type. Note that these methods only work for {\em
-abstract} types. Concrete types (those that do not include an opaque objects
+methods can be called on a type. Note that these methods only work for <i>
+abstract</i> types. Concrete types (those that do not include an opaque objects
somewhere) can never be refined.
</p>
</div>
</body>
</html>
-<!-- vim: sw=2 noai
--->