| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" | 
 | 2 |                       "http://www.w3.org/TR/html4/strict.dtd"> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 3 | <html> | 
 | 4 | <head> | 
 | 5 |   <title>LLVM Programmer's Manual</title> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 6 |   <link rel="stylesheet" href="llvm.css" type="text/css"> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 7 | </head> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 8 | <body> | 
 | 9 |  | 
 | 10 | <div class="doc_title"> | 
 | 11 |   LLVM Programmer's Manual | 
 | 12 | </div> | 
 | 13 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 14 | <ol> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 15 |   <li><a href="#introduction">Introduction</a></li> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 16 |   <li><a href="#general">General Information</a> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 17 |     <ul> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 18 |       <li><a href="#stl">The C++ Standard Template Library</a></li> | 
 | 19 | <!-- | 
 | 20 |       <li>The <tt>-time-passes</tt> option</li> | 
 | 21 |       <li>How to use the LLVM Makefile system</li> | 
 | 22 |       <li>How to write a regression test</li> | 
| Chris Lattner | 61db465 | 2004-12-08 19:05:44 +0000 | [diff] [blame] | 23 |  | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 24 | -->  | 
| Chris Lattner | 84b7f8d | 2003-08-01 22:20:59 +0000 | [diff] [blame] | 25 |     </ul> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 26 |   </li> | 
 | 27 |   <li><a href="#apis">Important and useful LLVM APIs</a> | 
 | 28 |     <ul> | 
 | 29 |       <li><a href="#isa">The <tt>isa<></tt>, <tt>cast<></tt> | 
 | 30 | and <tt>dyn_cast<></tt> templates</a> </li> | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 31 |       <li><a href="#DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 32 | option</a> | 
 | 33 |         <ul> | 
 | 34 |           <li><a href="#DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> | 
 | 35 | and the <tt>-debug-only</tt> option</a> </li> | 
 | 36 |         </ul> | 
 | 37 |       </li> | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 38 |       <li><a href="#Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 39 | option</a></li> | 
 | 40 | <!-- | 
 | 41 |       <li>The <tt>InstVisitor</tt> template | 
 | 42 |       <li>The general graph API | 
 | 43 | -->  | 
| Chris Lattner | f623a08 | 2005-10-17 01:36:23 +0000 | [diff] [blame] | 44 |       <li><a href="#ViewGraph">Viewing graphs while debugging code</a></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 45 |     </ul> | 
 | 46 |   </li> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 47 |   <li><a href="#datastructure">Picking the Right Data Structure for a Task</a> | 
 | 48 |     <ul> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 49 |     <li><a href="#ds_sequential">Sequential Containers (std::vector, std::list, etc)</a> | 
 | 50 |     <ul> | 
 | 51 |       <li><a href="#dss_fixedarrays">Fixed Size Arrays</a></li> | 
 | 52 |       <li><a href="#dss_heaparrays">Heap Allocated Arrays</a></li> | 
 | 53 |       <li><a href="#dss_smallvector">"llvm/ADT/SmallVector.h"</a></li> | 
 | 54 |       <li><a href="#dss_vector"><vector></a></li> | 
 | 55 |       <li><a href="#dss_deque"><deque></a></li> | 
 | 56 |       <li><a href="#dss_list"><list></a></li> | 
 | 57 |       <li><a href="#dss_ilist">llvm/ADT/ilist</a></li> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 58 |     </ul></li> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 59 |     <li><a href="#ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a> | 
 | 60 |     <ul> | 
 | 61 |       <li><a href="#dss_sortedvectorset">A sorted 'vector'</a></li> | 
 | 62 |       <li><a href="#dss_smallset">"llvm/ADT/SmallSet.h"</a></li> | 
 | 63 |       <li><a href="#dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a></li> | 
 | 64 |       <li><a href="#dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a></li> | 
 | 65 |       <li><a href="#dss_set"><set></a></li> | 
 | 66 |       <li><a href="#dss_setvector">"llvm/ADT/SetVector.h"</a></li> | 
 | 67 |       <li><a href="#dss_otherset">Other Options</a></li> | 
 | 68 |     </ul></li> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 69 |     <li><a href="#ds_map">Map-Like Containers (std::map, DenseMap, etc)</a></li> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 70 |   </ul> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 71 |   </li> | 
| Chris Lattner | ae7f759 | 2002-09-06 18:31:18 +0000 | [diff] [blame] | 72 |   <li><a href="#common">Helpful Hints for Common Operations</a> | 
| Chris Lattner | ae7f759 | 2002-09-06 18:31:18 +0000 | [diff] [blame] | 73 |     <ul> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 74 |       <li><a href="#inspection">Basic Inspection and Traversal Routines</a> | 
 | 75 |         <ul> | 
 | 76 |           <li><a href="#iterate_function">Iterating over the <tt>BasicBlock</tt>s | 
 | 77 | in a <tt>Function</tt></a> </li> | 
 | 78 |           <li><a href="#iterate_basicblock">Iterating over the <tt>Instruction</tt>s | 
 | 79 | in a <tt>BasicBlock</tt></a> </li> | 
 | 80 |           <li><a href="#iterate_institer">Iterating over the <tt>Instruction</tt>s | 
 | 81 | in a <tt>Function</tt></a> </li> | 
 | 82 |           <li><a href="#iterate_convert">Turning an iterator into a | 
 | 83 | class pointer</a> </li> | 
 | 84 |           <li><a href="#iterate_complex">Finding call sites: a more | 
 | 85 | complex example</a> </li> | 
 | 86 |           <li><a href="#calls_and_invokes">Treating calls and invokes | 
 | 87 | the same way</a> </li> | 
 | 88 |           <li><a href="#iterate_chains">Iterating over def-use & | 
 | 89 | use-def chains</a> </li> | 
 | 90 |         </ul> | 
 | 91 |       </li> | 
 | 92 |       <li><a href="#simplechanges">Making simple changes</a> | 
 | 93 |         <ul> | 
 | 94 |           <li><a href="#schanges_creating">Creating and inserting new | 
 | 95 | 		 <tt>Instruction</tt>s</a> </li> | 
 | 96 |           <li><a href="#schanges_deleting">Deleting 		 <tt>Instruction</tt>s</a> </li> | 
 | 97 |           <li><a href="#schanges_replacing">Replacing an 		 <tt>Instruction</tt> | 
 | 98 | with another <tt>Value</tt></a> </li> | 
 | 99 |         </ul> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 100 |       </li> | 
| Chris Lattner | ae7f759 | 2002-09-06 18:31:18 +0000 | [diff] [blame] | 101 | <!-- | 
 | 102 |     <li>Working with the Control Flow Graph | 
 | 103 |     <ul> | 
 | 104 |       <li>Accessing predecessors and successors of a <tt>BasicBlock</tt> | 
 | 105 |       <li> | 
 | 106 |       <li> | 
 | 107 |     </ul> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 108 | -->  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 109 |     </ul> | 
 | 110 |   </li> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 111 |  | 
 | 112 |   <li><a href="#advanced">Advanced Topics</a> | 
 | 113 |   <ul> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 114 |   <li><a href="#TypeResolve">LLVM Type Resolution</a> | 
 | 115 |   <ul> | 
 | 116 |     <li><a href="#BuildRecType">Basic Recursive Type Construction</a></li> | 
 | 117 |     <li><a href="#refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a></li> | 
 | 118 |     <li><a href="#PATypeHolder">The PATypeHolder Class</a></li> | 
 | 119 |     <li><a href="#AbstractTypeUser">The AbstractTypeUser Class</a></li> | 
 | 120 |   </ul></li> | 
 | 121 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 122 |   <li><a href="#SymbolTable">The <tt>SymbolTable</tt> class </a></li> | 
 | 123 |   </ul></li> | 
 | 124 |  | 
| Joel Stanley | 9b96c44 | 2002-09-06 21:55:13 +0000 | [diff] [blame] | 125 |   <li><a href="#coreclasses">The Core LLVM Class Hierarchy Reference</a> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 126 |     <ul> | 
| Reid Spencer | 303c4b4 | 2007-01-12 17:26:25 +0000 | [diff] [blame] | 127 |       <li><a href="#Type">The <tt>Type</tt> class</a> </li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 128 |       <li><a href="#Value">The <tt>Value</tt> class</a> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 129 |         <ul> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 130 |           <li><a href="#User">The <tt>User</tt> class</a> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 131 |             <ul> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 132 |               <li><a href="#Instruction">The <tt>Instruction</tt> class</a> | 
 | 133 |                 <ul> | 
 | 134 |                   <li><a href="#GetElementPtrInst">The <tt>GetElementPtrInst</tt> class</a></li> | 
 | 135 |                 </ul> | 
 | 136 |               </li> | 
 | 137 |               <li><a href="#Module">The <tt>Module</tt> class</a></li> | 
 | 138 |               <li><a href="#Constant">The <tt>Constant</tt> class</a> | 
 | 139 | 	        <ul> | 
 | 140 |                   <li><a href="#GlobalValue">The <tt>GlobalValue</tt> class</a> | 
 | 141 |                     <ul> | 
 | 142 |                       <li><a href="#BasicBlock">The <tt>BasicBlock</tt>class</a></li> | 
 | 143 |                       <li><a href="#Function">The <tt>Function</tt> class</a></li> | 
 | 144 |                       <li><a href="#GlobalVariable">The <tt>GlobalVariable</tt> class</a></li> | 
 | 145 |                     </ul> | 
 | 146 |                   </li> | 
 | 147 |                 </ul> | 
 | 148 |               </li> | 
| Reid Spencer | 8b2da7a | 2004-07-18 13:10:31 +0000 | [diff] [blame] | 149 | 	    </ul> | 
 | 150 | 	  </li> | 
| Reid Spencer | 096603a | 2004-05-26 08:41:35 +0000 | [diff] [blame] | 151 |           <li><a href="#Argument">The <tt>Argument</tt> class</a></li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 152 |         </ul> | 
 | 153 |       </li> | 
 | 154 |     </ul> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 155 |   </li> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 156 | </ol> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 157 |  | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 158 | <div class="doc_author">     | 
 | 159 |   <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>,  | 
| Chris Lattner | 94c4359 | 2004-05-26 16:52:55 +0000 | [diff] [blame] | 160 |                 <a href="mailto:dhurjati@cs.uiuc.edu">Dinakar Dhurjati</a>,  | 
 | 161 |                 <a href="mailto:jstanley@cs.uiuc.edu">Joel Stanley</a>, and | 
 | 162 |                 <a href="mailto:rspencer@x10sys.com">Reid Spencer</a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 163 | </div> | 
 | 164 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 165 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 166 | <div class="doc_section"> | 
 | 167 |   <a name="introduction">Introduction </a> | 
 | 168 | </div> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 169 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 170 |  | 
 | 171 | <div class="doc_text"> | 
 | 172 |  | 
 | 173 | <p>This document is meant to highlight some of the important classes and | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 174 | interfaces available in the LLVM source-base.  This manual is not | 
 | 175 | intended to explain what LLVM is, how it works, and what LLVM code looks | 
 | 176 | like.  It assumes that you know the basics of LLVM and are interested | 
 | 177 | in writing transformations or otherwise analyzing or manipulating the | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 178 | code.</p> | 
 | 179 |  | 
 | 180 | <p>This document should get you oriented so that you can find your | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 181 | way in the continuously growing source code that makes up the LLVM | 
 | 182 | infrastructure. Note that this manual is not intended to serve as a | 
 | 183 | replacement for reading the source code, so if you think there should be | 
 | 184 | a method in one of these classes to do something, but it's not listed, | 
 | 185 | check the source.  Links to the <a href="/doxygen/">doxygen</a> sources | 
 | 186 | are provided to make this as easy as possible.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 187 |  | 
 | 188 | <p>The first section of this document describes general information that is | 
 | 189 | useful to know when working in the LLVM infrastructure, and the second describes | 
 | 190 | the Core LLVM classes.  In the future this manual will be extended with | 
 | 191 | information describing how to use extension libraries, such as dominator | 
 | 192 | information, CFG traversal routines, and useful utilities like the <tt><a | 
 | 193 | href="/doxygen/InstVisitor_8h-source.html">InstVisitor</a></tt> template.</p> | 
 | 194 |  | 
 | 195 | </div> | 
 | 196 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 197 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 198 | <div class="doc_section"> | 
 | 199 |   <a name="general">General Information</a> | 
 | 200 | </div> | 
 | 201 | <!-- *********************************************************************** --> | 
 | 202 |  | 
 | 203 | <div class="doc_text"> | 
 | 204 |  | 
 | 205 | <p>This section contains general information that is useful if you are working | 
 | 206 | in the LLVM source-base, but that isn't specific to any particular API.</p> | 
 | 207 |  | 
 | 208 | </div> | 
 | 209 |  | 
 | 210 | <!-- ======================================================================= --> | 
 | 211 | <div class="doc_subsection"> | 
 | 212 |   <a name="stl">The C++ Standard Template Library</a> | 
 | 213 | </div> | 
 | 214 |  | 
 | 215 | <div class="doc_text"> | 
 | 216 |  | 
 | 217 | <p>LLVM makes heavy use of the C++ Standard Template Library (STL), | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 218 | perhaps much more than you are used to, or have seen before.  Because of | 
 | 219 | this, you might want to do a little background reading in the | 
 | 220 | techniques used and capabilities of the library.  There are many good | 
 | 221 | pages that discuss the STL, and several books on the subject that you | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 222 | can get, so it will not be discussed in this document.</p> | 
 | 223 |  | 
 | 224 | <p>Here are some useful links:</p> | 
 | 225 |  | 
 | 226 | <ol> | 
 | 227 |  | 
 | 228 | <li><a href="http://www.dinkumware.com/refxcpp.html">Dinkumware C++ Library | 
 | 229 | reference</a> - an excellent reference for the STL and other parts of the | 
 | 230 | standard C++ library.</li> | 
 | 231 |  | 
 | 232 | <li><a href="http://www.tempest-sw.com/cpp/">C++ In a Nutshell</a> - This is an | 
| Tanya Lattner | 09cf73c | 2004-06-22 04:24:55 +0000 | [diff] [blame] | 233 | O'Reilly book in the making.  It has a decent  | 
 | 234 | Standard Library | 
 | 235 | Reference that rivals Dinkumware's, and is unfortunately no longer free since the book has been  | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 236 | published.</li> | 
 | 237 |  | 
 | 238 | <li><a href="http://www.parashift.com/c++-faq-lite/">C++ Frequently Asked | 
 | 239 | Questions</a></li> | 
 | 240 |  | 
 | 241 | <li><a href="http://www.sgi.com/tech/stl/">SGI's STL Programmer's Guide</a> - | 
 | 242 | Contains a useful <a | 
 | 243 | href="http://www.sgi.com/tech/stl/stl_introduction.html">Introduction to the | 
 | 244 | STL</a>.</li> | 
 | 245 |  | 
 | 246 | <li><a href="http://www.research.att.com/%7Ebs/C++.html">Bjarne Stroustrup's C++ | 
 | 247 | Page</a></li> | 
 | 248 |  | 
| Tanya Lattner | 79445ba | 2004-12-08 18:34:56 +0000 | [diff] [blame] | 249 | <li><a href="http://64.78.49.204/"> | 
| Reid Spencer | 096603a | 2004-05-26 08:41:35 +0000 | [diff] [blame] | 250 | Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get | 
 | 251 | the book).</a></li> | 
 | 252 |  | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 253 | </ol> | 
 | 254 |    | 
 | 255 | <p>You are also encouraged to take a look at the <a | 
 | 256 | href="CodingStandards.html">LLVM Coding Standards</a> guide which focuses on how | 
 | 257 | to write maintainable code more than where to put your curly braces.</p> | 
 | 258 |  | 
 | 259 | </div> | 
 | 260 |  | 
 | 261 | <!-- ======================================================================= --> | 
 | 262 | <div class="doc_subsection"> | 
 | 263 |   <a name="stl">Other useful references</a> | 
 | 264 | </div> | 
 | 265 |  | 
 | 266 | <div class="doc_text"> | 
 | 267 |  | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 268 | <ol> | 
 | 269 | <li><a href="http://www.psc.edu/%7Esemke/cvs_branches.html">CVS | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 270 | Branch and Tag Primer</a></li> | 
| Misha Brukman | a0f71e4 | 2004-06-18 18:39:00 +0000 | [diff] [blame] | 271 | <li><a href="http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html">Using | 
 | 272 | static and shared libraries across platforms</a></li> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 273 | </ol> | 
 | 274 |  | 
 | 275 | </div> | 
 | 276 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 277 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 278 | <div class="doc_section"> | 
 | 279 |   <a name="apis">Important and useful LLVM APIs</a> | 
 | 280 | </div> | 
 | 281 | <!-- *********************************************************************** --> | 
 | 282 |  | 
 | 283 | <div class="doc_text"> | 
 | 284 |  | 
 | 285 | <p>Here we highlight some LLVM APIs that are generally useful and good to | 
 | 286 | know about when writing transformations.</p> | 
 | 287 |  | 
 | 288 | </div> | 
 | 289 |  | 
 | 290 | <!-- ======================================================================= --> | 
 | 291 | <div class="doc_subsection"> | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 292 |   <a name="isa">The <tt>isa<></tt>, <tt>cast<></tt> and | 
 | 293 |   <tt>dyn_cast<></tt> templates</a> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 294 | </div> | 
 | 295 |  | 
 | 296 | <div class="doc_text"> | 
 | 297 |  | 
 | 298 | <p>The LLVM source-base makes extensive use of a custom form of RTTI. | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 299 | These templates have many similarities to the C++ <tt>dynamic_cast<></tt> | 
 | 300 | operator, but they don't have some drawbacks (primarily stemming from | 
 | 301 | the fact that <tt>dynamic_cast<></tt> only works on classes that | 
 | 302 | have a v-table). Because they are used so often, you must know what they | 
 | 303 | do and how they work. All of these templates are defined in the <a | 
| Chris Lattner | 695b78b | 2005-04-26 22:56:16 +0000 | [diff] [blame] | 304 |  href="/doxygen/Casting_8h-source.html"><tt>llvm/Support/Casting.h</tt></a> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 305 | file (note that you very rarely have to include this file directly).</p> | 
 | 306 |  | 
 | 307 | <dl> | 
 | 308 |   <dt><tt>isa<></tt>: </dt> | 
 | 309 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 310 |   <dd><p>The <tt>isa<></tt> operator works exactly like the Java | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 311 |   "<tt>instanceof</tt>" operator.  It returns true or false depending on whether | 
 | 312 |   a reference or pointer points to an instance of the specified class.  This can | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 313 |   be very useful for constraint checking of various sorts (example below).</p> | 
 | 314 |   </dd> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 315 |  | 
 | 316 |   <dt><tt>cast<></tt>: </dt> | 
 | 317 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 318 |   <dd><p>The <tt>cast<></tt> operator is a "checked cast" operation. It | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 319 |   converts a pointer or reference from a base class to a derived cast, causing | 
 | 320 |   an assertion failure if it is not really an instance of the right type.  This | 
 | 321 |   should be used in cases where you have some information that makes you believe | 
 | 322 |   that something is of the right type.  An example of the <tt>isa<></tt> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 323 |   and <tt>cast<></tt> template is:</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 324 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 325 | <div class="doc_code"> | 
 | 326 | <pre> | 
 | 327 | static bool isLoopInvariant(const <a href="#Value">Value</a> *V, const Loop *L) { | 
 | 328 |   if (isa<<a href="#Constant">Constant</a>>(V) || isa<<a href="#Argument">Argument</a>>(V) || isa<<a href="#GlobalValue">GlobalValue</a>>(V)) | 
 | 329 |     return true; | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 330 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 331 |   // <i>Otherwise, it must be an instruction...</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 332 |   return !L->contains(cast<<a href="#Instruction">Instruction</a>>(V)->getParent()); | 
 | 333 | } | 
 | 334 | </pre> | 
 | 335 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 336 |  | 
 | 337 |   <p>Note that you should <b>not</b> use an <tt>isa<></tt> test followed | 
 | 338 |   by a <tt>cast<></tt>, for that use the <tt>dyn_cast<></tt> | 
 | 339 |   operator.</p> | 
 | 340 |  | 
 | 341 |   </dd> | 
 | 342 |  | 
 | 343 |   <dt><tt>dyn_cast<></tt>:</dt> | 
 | 344 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 345 |   <dd><p>The <tt>dyn_cast<></tt> operator is a "checking cast" operation. | 
 | 346 |   It checks to see if the operand is of the specified type, and if so, returns a | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 347 |   pointer to it (this operator does not work with references). If the operand is | 
 | 348 |   not of the correct type, a null pointer is returned.  Thus, this works very | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 349 |   much like the <tt>dynamic_cast<></tt> operator in C++, and should be | 
 | 350 |   used in the same circumstances.  Typically, the <tt>dyn_cast<></tt> | 
 | 351 |   operator is used in an <tt>if</tt> statement or some other flow control | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 352 |   statement like this:</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 353 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 354 | <div class="doc_code"> | 
 | 355 | <pre> | 
 | 356 | if (<a href="#AllocationInst">AllocationInst</a> *AI = dyn_cast<<a href="#AllocationInst">AllocationInst</a>>(Val)) { | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 357 |   // <i>...</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 358 | } | 
 | 359 | </pre> | 
 | 360 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 361 |     | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 362 |   <p>This form of the <tt>if</tt> statement effectively combines together a call | 
 | 363 |   to <tt>isa<></tt> and a call to <tt>cast<></tt> into one | 
 | 364 |   statement, which is very convenient.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 365 |  | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 366 |   <p>Note that the <tt>dyn_cast<></tt> operator, like C++'s | 
 | 367 |   <tt>dynamic_cast<></tt> or Java's <tt>instanceof</tt> operator, can be | 
 | 368 |   abused.  In particular, you should not use big chained <tt>if/then/else</tt> | 
 | 369 |   blocks to check for lots of different variants of classes.  If you find | 
 | 370 |   yourself wanting to do this, it is much cleaner and more efficient to use the | 
 | 371 |   <tt>InstVisitor</tt> class to dispatch over the instruction type directly.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 372 |  | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 373 |   </dd> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 374 |  | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 375 |   <dt><tt>cast_or_null<></tt>: </dt> | 
 | 376 |    | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 377 |   <dd><p>The <tt>cast_or_null<></tt> operator works just like the | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 378 |   <tt>cast<></tt> operator, except that it allows for a null pointer as an | 
 | 379 |   argument (which it then propagates).  This can sometimes be useful, allowing | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 380 |   you to combine several null checks into one.</p></dd> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 381 |  | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 382 |   <dt><tt>dyn_cast_or_null<></tt>: </dt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 383 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 384 |   <dd><p>The <tt>dyn_cast_or_null<></tt> operator works just like the | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 385 |   <tt>dyn_cast<></tt> operator, except that it allows for a null pointer | 
 | 386 |   as an argument (which it then propagates).  This can sometimes be useful, | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 387 |   allowing you to combine several null checks into one.</p></dd> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 388 |  | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 389 | </dl> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 390 |  | 
 | 391 | <p>These five templates can be used with any classes, whether they have a | 
 | 392 | v-table or not.  To add support for these templates, you simply need to add | 
 | 393 | <tt>classof</tt> static methods to the class you are interested casting | 
 | 394 | to. Describing this is currently outside the scope of this document, but there | 
 | 395 | are lots of examples in the LLVM source base.</p> | 
 | 396 |  | 
 | 397 | </div> | 
 | 398 |  | 
 | 399 | <!-- ======================================================================= --> | 
 | 400 | <div class="doc_subsection"> | 
| Misha Brukman | 2c122ce | 2005-11-01 21:12:49 +0000 | [diff] [blame] | 401 |   <a name="DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt> option</a> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 402 | </div> | 
 | 403 |  | 
 | 404 | <div class="doc_text"> | 
 | 405 |  | 
 | 406 | <p>Often when working on your pass you will put a bunch of debugging printouts | 
 | 407 | and other code into your pass.  After you get it working, you want to remove | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 408 | it, but you may need it again in the future (to work out new bugs that you run | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 409 | across).</p> | 
 | 410 |  | 
 | 411 | <p> Naturally, because of this, you don't want to delete the debug printouts, | 
 | 412 | but you don't want them to always be noisy.  A standard compromise is to comment | 
 | 413 | them out, allowing you to enable them if you need them in the future.</p> | 
 | 414 |  | 
| Chris Lattner | 695b78b | 2005-04-26 22:56:16 +0000 | [diff] [blame] | 415 | <p>The "<tt><a href="/doxygen/Debug_8h-source.html">llvm/Support/Debug.h</a></tt>" | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 416 | file provides a macro named <tt>DEBUG()</tt> that is a much nicer solution to | 
 | 417 | this problem.  Basically, you can put arbitrary code into the argument of the | 
 | 418 | <tt>DEBUG</tt> macro, and it is only executed if '<tt>opt</tt>' (or any other | 
 | 419 | tool) is run with the '<tt>-debug</tt>' command line argument:</p> | 
 | 420 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 421 | <div class="doc_code"> | 
 | 422 | <pre> | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 423 | DOUT << "I am here!\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 424 | </pre> | 
 | 425 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 426 |  | 
 | 427 | <p>Then you can run your pass like this:</p> | 
 | 428 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 429 | <div class="doc_code"> | 
 | 430 | <pre> | 
 | 431 | $ opt < a.bc > /dev/null -mypass | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 432 | <i><no output></i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 433 | $ opt < a.bc > /dev/null -mypass -debug | 
 | 434 | I am here! | 
 | 435 | </pre> | 
 | 436 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 437 |  | 
 | 438 | <p>Using the <tt>DEBUG()</tt> macro instead of a home-brewed solution allows you | 
 | 439 | to not have to create "yet another" command line option for the debug output for | 
 | 440 | your pass.  Note that <tt>DEBUG()</tt> macros are disabled for optimized builds, | 
 | 441 | so they do not cause a performance impact at all (for the same reason, they | 
 | 442 | should also not contain side-effects!).</p> | 
 | 443 |  | 
 | 444 | <p>One additional nice thing about the <tt>DEBUG()</tt> macro is that you can | 
 | 445 | enable or disable it directly in gdb.  Just use "<tt>set DebugFlag=0</tt>" or | 
 | 446 | "<tt>set DebugFlag=1</tt>" from the gdb if the program is running.  If the | 
 | 447 | program hasn't been started yet, you can always just run it with | 
 | 448 | <tt>-debug</tt>.</p> | 
 | 449 |  | 
 | 450 | </div> | 
 | 451 |  | 
 | 452 | <!-- _______________________________________________________________________ --> | 
 | 453 | <div class="doc_subsubsection"> | 
| Chris Lattner | c915108 | 2005-04-26 22:57:07 +0000 | [diff] [blame] | 454 |   <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 455 |   the <tt>-debug-only</tt> option</a> | 
 | 456 | </div> | 
 | 457 |  | 
 | 458 | <div class="doc_text"> | 
 | 459 |  | 
 | 460 | <p>Sometimes you may find yourself in a situation where enabling <tt>-debug</tt> | 
 | 461 | just turns on <b>too much</b> information (such as when working on the code | 
 | 462 | generator).  If you want to enable debug information with more fine-grained | 
 | 463 | control, you define the <tt>DEBUG_TYPE</tt> macro and the <tt>-debug</tt> only | 
 | 464 | option as follows:</p> | 
 | 465 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 466 | <div class="doc_code"> | 
 | 467 | <pre> | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 468 | DOUT << "No debug type\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 469 | #undef  DEBUG_TYPE | 
 | 470 | #define DEBUG_TYPE "foo" | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 471 | DOUT << "'foo' debug type\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 472 | #undef  DEBUG_TYPE | 
 | 473 | #define DEBUG_TYPE "bar" | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 474 | DOUT << "'bar' debug type\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 475 | #undef  DEBUG_TYPE | 
 | 476 | #define DEBUG_TYPE "" | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 477 | DOUT << "No debug type (2)\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 478 | </pre> | 
 | 479 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 480 |  | 
 | 481 | <p>Then you can run your pass like this:</p> | 
 | 482 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 483 | <div class="doc_code"> | 
 | 484 | <pre> | 
 | 485 | $ opt < a.bc > /dev/null -mypass | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 486 | <i><no output></i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 487 | $ opt < a.bc > /dev/null -mypass -debug | 
 | 488 | No debug type | 
 | 489 | 'foo' debug type | 
 | 490 | 'bar' debug type | 
 | 491 | No debug type (2) | 
 | 492 | $ opt < a.bc > /dev/null -mypass -debug-only=foo | 
 | 493 | 'foo' debug type | 
 | 494 | $ opt < a.bc > /dev/null -mypass -debug-only=bar | 
 | 495 | 'bar' debug type | 
 | 496 | </pre> | 
 | 497 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 498 |  | 
 | 499 | <p>Of course, in practice, you should only set <tt>DEBUG_TYPE</tt> at the top of | 
 | 500 | a file, to specify the debug type for the entire module (if you do this before | 
| Chris Lattner | 695b78b | 2005-04-26 22:56:16 +0000 | [diff] [blame] | 501 | you <tt>#include "llvm/Support/Debug.h"</tt>, you don't have to insert the ugly | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 502 | <tt>#undef</tt>'s).  Also, you should use names more meaningful than "foo" and | 
 | 503 | "bar", because there is no system in place to ensure that names do not | 
 | 504 | conflict. If two different modules use the same string, they will all be turned | 
 | 505 | on when the name is specified. This allows, for example, all debug information | 
 | 506 | for instruction scheduling to be enabled with <tt>-debug-type=InstrSched</tt>, | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 507 | even if the source lives in multiple files.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 508 |  | 
 | 509 | </div> | 
 | 510 |  | 
 | 511 | <!-- ======================================================================= --> | 
 | 512 | <div class="doc_subsection"> | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 513 |   <a name="Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 514 |   option</a> | 
 | 515 | </div> | 
 | 516 |  | 
 | 517 | <div class="doc_text"> | 
 | 518 |  | 
 | 519 | <p>The "<tt><a | 
| Chris Lattner | 695b78b | 2005-04-26 22:56:16 +0000 | [diff] [blame] | 520 | href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 521 | provides a class named <tt>Statistic</tt> that is used as a unified way to | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 522 | keep track of what the LLVM compiler is doing and how effective various | 
 | 523 | optimizations are.  It is useful to see what optimizations are contributing to | 
 | 524 | making a particular program run faster.</p> | 
 | 525 |  | 
 | 526 | <p>Often you may run your pass on some big program, and you're interested to see | 
 | 527 | how many times it makes a certain transformation.  Although you can do this with | 
 | 528 | hand inspection, or some ad-hoc method, this is a real pain and not very useful | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 529 | for big programs.  Using the <tt>Statistic</tt> class makes it very easy to | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 530 | keep track of this information, and the calculated information is presented in a | 
 | 531 | uniform manner with the rest of the passes being executed.</p> | 
 | 532 |  | 
 | 533 | <p>There are many examples of <tt>Statistic</tt> uses, but the basics of using | 
 | 534 | it are as follows:</p> | 
 | 535 |  | 
 | 536 | <ol> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 537 |     <li><p>Define your statistic like this:</p> | 
 | 538 |  | 
 | 539 | <div class="doc_code"> | 
 | 540 | <pre> | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 541 | #define <a href="#DEBUG_TYPE">DEBUG_TYPE</a> "mypassname"   <i>// This goes before any #includes.</i> | 
 | 542 | STATISTIC(NumXForms, "The # of times I did stuff"); | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 543 | </pre> | 
 | 544 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 545 |  | 
| Chris Lattner | 0be6fdf | 2006-12-19 21:46:21 +0000 | [diff] [blame] | 546 |   <p>The <tt>STATISTIC</tt> macro defines a static variable, whose name is | 
 | 547 |     specified by the first argument.  The pass name is taken from the DEBUG_TYPE | 
 | 548 |     macro, and the description is taken from the second argument.  The variable | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 549 |     defined ("NumXForms" in this case) acts like an unsigned integer.</p></li> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 550 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 551 |     <li><p>Whenever you make a transformation, bump the counter:</p> | 
 | 552 |  | 
 | 553 | <div class="doc_code"> | 
 | 554 | <pre> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 555 | ++NumXForms;   // <i>I did stuff!</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 556 | </pre> | 
 | 557 | </div> | 
 | 558 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 559 |     </li> | 
 | 560 |   </ol> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 561 |  | 
 | 562 |   <p>That's all you have to do.  To get '<tt>opt</tt>' to print out the | 
 | 563 |   statistics gathered, use the '<tt>-stats</tt>' option:</p> | 
 | 564 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 565 | <div class="doc_code"> | 
 | 566 | <pre> | 
 | 567 | $ opt -stats -mypassname < program.bc > /dev/null | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 568 | <i>... statistics output ...</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 569 | </pre> | 
 | 570 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 571 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 572 |   <p> When running <tt>gccas</tt> on a C file from the SPEC benchmark | 
 | 573 | suite, it gives a report that looks like this:</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 574 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 575 | <div class="doc_code"> | 
 | 576 | <pre> | 
 | 577 |    7646 bytecodewriter  - Number of normal instructions | 
 | 578 |     725 bytecodewriter  - Number of oversized instructions | 
 | 579 |  129996 bytecodewriter  - Number of bytecode bytes written | 
 | 580 |    2817 raise           - Number of insts DCEd or constprop'd | 
 | 581 |    3213 raise           - Number of cast-of-self removed | 
 | 582 |    5046 raise           - Number of expression trees converted | 
 | 583 |      75 raise           - Number of other getelementptr's formed | 
 | 584 |     138 raise           - Number of load/store peepholes | 
 | 585 |      42 deadtypeelim    - Number of unused typenames removed from symtab | 
 | 586 |     392 funcresolve     - Number of varargs functions resolved | 
 | 587 |      27 globaldce       - Number of global variables removed | 
 | 588 |       2 adce            - Number of basic blocks removed | 
 | 589 |     134 cee             - Number of branches revectored | 
 | 590 |      49 cee             - Number of setcc instruction eliminated | 
 | 591 |     532 gcse            - Number of loads removed | 
 | 592 |    2919 gcse            - Number of instructions removed | 
 | 593 |      86 indvars         - Number of canonical indvars added | 
 | 594 |      87 indvars         - Number of aux indvars removed | 
 | 595 |      25 instcombine     - Number of dead inst eliminate | 
 | 596 |     434 instcombine     - Number of insts combined | 
 | 597 |     248 licm            - Number of load insts hoisted | 
 | 598 |    1298 licm            - Number of insts hoisted to a loop pre-header | 
 | 599 |       3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header) | 
 | 600 |      75 mem2reg         - Number of alloca's promoted | 
 | 601 |    1444 cfgsimplify     - Number of blocks simplified | 
 | 602 | </pre> | 
 | 603 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 604 |  | 
 | 605 | <p>Obviously, with so many optimizations, having a unified framework for this | 
 | 606 | stuff is very nice.  Making your pass fit well into the framework makes it more | 
 | 607 | maintainable and useful.</p> | 
 | 608 |  | 
 | 609 | </div> | 
 | 610 |  | 
| Chris Lattner | f623a08 | 2005-10-17 01:36:23 +0000 | [diff] [blame] | 611 | <!-- ======================================================================= --> | 
 | 612 | <div class="doc_subsection"> | 
 | 613 |   <a name="ViewGraph">Viewing graphs while debugging code</a> | 
 | 614 | </div> | 
 | 615 |  | 
 | 616 | <div class="doc_text"> | 
 | 617 |  | 
 | 618 | <p>Several of the important data structures in LLVM are graphs: for example | 
 | 619 | CFGs made out of LLVM <a href="#BasicBlock">BasicBlock</a>s, CFGs made out of | 
 | 620 | LLVM <a href="CodeGenerator.html#machinebasicblock">MachineBasicBlock</a>s, and | 
 | 621 | <a href="CodeGenerator.html#selectiondag_intro">Instruction Selection | 
 | 622 | DAGs</a>.  In many cases, while debugging various parts of the compiler, it is | 
 | 623 | nice to instantly visualize these graphs.</p> | 
 | 624 |  | 
 | 625 | <p>LLVM provides several callbacks that are available in a debug build to do | 
 | 626 | exactly that.  If you call the <tt>Function::viewCFG()</tt> method, for example, | 
 | 627 | the current LLVM tool will pop up a window containing the CFG for the function | 
 | 628 | where each basic block is a node in the graph, and each node contains the | 
 | 629 | instructions in the block.  Similarly, there also exists  | 
 | 630 | <tt>Function::viewCFGOnly()</tt> (does not include the instructions), the | 
 | 631 | <tt>MachineFunction::viewCFG()</tt> and <tt>MachineFunction::viewCFGOnly()</tt>, | 
 | 632 | and the <tt>SelectionDAG::viewGraph()</tt> methods.  Within GDB, for example, | 
| Jim Laskey | 543a0ee | 2006-10-02 12:28:07 +0000 | [diff] [blame] | 633 | you can usually use something like <tt>call DAG.viewGraph()</tt> to pop | 
| Chris Lattner | f623a08 | 2005-10-17 01:36:23 +0000 | [diff] [blame] | 634 | up a window.  Alternatively, you can sprinkle calls to these functions in your | 
 | 635 | code in places you want to debug.</p> | 
 | 636 |  | 
 | 637 | <p>Getting this to work requires a small amount of configuration.  On Unix | 
 | 638 | systems with X11, install the <a href="http://www.graphviz.org">graphviz</a> | 
 | 639 | toolkit, and make sure 'dot' and 'gv' are in your path.  If you are running on | 
 | 640 | Mac OS/X, download and install the Mac OS/X <a  | 
 | 641 | href="http://www.pixelglow.com/graphviz/">Graphviz program</a>, and add | 
 | 642 | <tt>/Applications/Graphviz.app/Contents/MacOS/</tt> (or whereever you install | 
 | 643 | it) to your path.  Once in your system and path are set up, rerun the LLVM | 
 | 644 | configure script and rebuild LLVM to enable this functionality.</p> | 
 | 645 |  | 
| Jim Laskey | 543a0ee | 2006-10-02 12:28:07 +0000 | [diff] [blame] | 646 | <p><tt>SelectionDAG</tt> has been extended to make it easier to locate | 
 | 647 | <i>interesting</i> nodes in large complex graphs.  From gdb, if you | 
 | 648 | <tt>call DAG.setGraphColor(<i>node</i>, "<i>color</i>")</tt>, then the | 
 | 649 | next <tt>call DAG.viewGraph()</tt> would hilight the node in the | 
 | 650 | specified color (choices of colors can be found at <a | 
| Chris Lattner | 302da1e | 2007-02-03 03:05:57 +0000 | [diff] [blame] | 651 | href="http://www.graphviz.org/doc/info/colors.html">colors</a>.) More | 
| Jim Laskey | 543a0ee | 2006-10-02 12:28:07 +0000 | [diff] [blame] | 652 | complex node attributes can be provided with <tt>call | 
 | 653 | DAG.setGraphAttrs(<i>node</i>, "<i>attributes</i>")</tt> (choices can be | 
 | 654 | found at <a href="http://www.graphviz.org/doc/info/attrs.html">Graph | 
 | 655 | Attributes</a>.)  If you want to restart and clear all the current graph | 
 | 656 | attributes, then you can <tt>call DAG.clearGraphAttrs()</tt>. </p> | 
 | 657 |  | 
| Chris Lattner | f623a08 | 2005-10-17 01:36:23 +0000 | [diff] [blame] | 658 | </div> | 
 | 659 |  | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 660 | <!-- *********************************************************************** --> | 
 | 661 | <div class="doc_section"> | 
 | 662 |   <a name="datastructure">Picking the Right Data Structure for a Task</a> | 
 | 663 | </div> | 
 | 664 | <!-- *********************************************************************** --> | 
 | 665 |  | 
 | 666 | <div class="doc_text"> | 
 | 667 |  | 
 | 668 | <p>LLVM has a plethora of datastructures in the <tt>llvm/ADT/</tt> directory, | 
 | 669 |  and we commonly use STL datastructures.  This section describes the tradeoffs | 
 | 670 |  you should consider when you pick one.</p> | 
 | 671 |  | 
 | 672 | <p> | 
 | 673 | The first step is a choose your own adventure: do you want a sequential | 
 | 674 | container, a set-like container, or a map-like container?  The most important | 
 | 675 | thing when choosing a container is the algorithmic properties of how you plan to | 
 | 676 | access the container.  Based on that, you should use:</p> | 
 | 677 |  | 
 | 678 | <ul> | 
 | 679 | <li>a <a href="#ds_map">map-like</a> container if you need efficient lookup | 
 | 680 |     of an value based on another value.  Map-like containers also support | 
 | 681 |     efficient queries for containment (whether a key is in the map).  Map-like | 
 | 682 |     containers generally do not support efficient reverse mapping (values to | 
 | 683 |     keys).  If you need that, use two maps.  Some map-like containers also | 
 | 684 |     support efficient iteration through the keys in sorted order.  Map-like | 
 | 685 |     containers are the most expensive sort, only use them if you need one of | 
 | 686 |     these capabilities.</li> | 
 | 687 |  | 
 | 688 | <li>a <a href="#ds_set">set-like</a> container if you need to put a bunch of | 
 | 689 |     stuff into a container that automatically eliminates duplicates.  Some | 
 | 690 |     set-like containers support efficient iteration through the elements in | 
 | 691 |     sorted order.  Set-like containers are more expensive than sequential | 
 | 692 |     containers. | 
 | 693 | </li> | 
 | 694 |  | 
 | 695 | <li>a <a href="#ds_sequential">sequential</a> container provides | 
 | 696 |     the most efficient way to add elements and keeps track of the order they are | 
 | 697 |     added to the collection.  They permit duplicates and support efficient | 
 | 698 |     iteration, but do not support efficient lookup based on a key. | 
 | 699 | </li> | 
 | 700 |  | 
 | 701 | </ul> | 
 | 702 |  | 
 | 703 | <p> | 
 | 704 | Once the proper catagory of container is determined, you can fine tune the | 
 | 705 | memory use, constant factors, and cache behaviors of access by intelligently | 
 | 706 | picking a member of the catagory.  Note that constant factors and cache behavior | 
 | 707 | can be a big deal.  If you have a vector that usually only contains a few | 
 | 708 | elements (but could contain many), for example, it's much better to use | 
 | 709 | <a href="#dss_smallvector">SmallVector</a> than <a href="#dss_vector">vector</a> | 
 | 710 | .  Doing so avoids (relatively) expensive malloc/free calls, which dwarf the | 
 | 711 | cost of adding the elements to the container. </p> | 
 | 712 |  | 
 | 713 | </div> | 
 | 714 |  | 
 | 715 | <!-- ======================================================================= --> | 
 | 716 | <div class="doc_subsection"> | 
 | 717 |   <a name="ds_sequential">Sequential Containers (std::vector, std::list, etc)</a> | 
 | 718 | </div> | 
 | 719 |  | 
 | 720 | <div class="doc_text"> | 
 | 721 | There are a variety of sequential containers available for you, based on your | 
 | 722 | needs.  Pick the first in this section that will do what you want. | 
 | 723 | </div> | 
 | 724 |  | 
 | 725 | <!-- _______________________________________________________________________ --> | 
 | 726 | <div class="doc_subsubsection"> | 
 | 727 |   <a name="dss_fixedarrays">Fixed Size Arrays</a> | 
 | 728 | </div> | 
 | 729 |  | 
 | 730 | <div class="doc_text"> | 
 | 731 | <p>Fixed size arrays are very simple and very fast.  They are good if you know | 
 | 732 | exactly how many elements you have, or you have a (low) upper bound on how many | 
 | 733 | you have.</p> | 
 | 734 | </div> | 
 | 735 |  | 
 | 736 | <!-- _______________________________________________________________________ --> | 
 | 737 | <div class="doc_subsubsection"> | 
 | 738 |   <a name="dss_heaparrays">Heap Allocated Arrays</a> | 
 | 739 | </div> | 
 | 740 |  | 
 | 741 | <div class="doc_text"> | 
 | 742 | <p>Heap allocated arrays (new[] + delete[]) are also simple.  They are good if | 
 | 743 | the number of elements is variable, if you know how many elements you will need | 
 | 744 | before the array is allocated, and if the array is usually large (if not, | 
 | 745 | consider a <a href="#dss_smallvector">SmallVector</a>).  The cost of a heap | 
 | 746 | allocated array is the cost of the new/delete (aka malloc/free).  Also note that | 
 | 747 | if you are allocating an array of a type with a constructor, the constructor and | 
 | 748 | destructors will be run for every element in the array (resizable vectors only | 
 | 749 | construct those elements actually used).</p> | 
 | 750 | </div> | 
 | 751 |  | 
 | 752 | <!-- _______________________________________________________________________ --> | 
 | 753 | <div class="doc_subsubsection"> | 
 | 754 |   <a name="dss_smallvector">"llvm/ADT/SmallVector.h"</a> | 
 | 755 | </div> | 
 | 756 |  | 
 | 757 | <div class="doc_text"> | 
 | 758 | <p><tt>SmallVector<Type, N></tt> is a simple class that looks and smells | 
 | 759 | just like <tt>vector<Type></tt>: | 
 | 760 | it supports efficient iteration, lays out elements in memory order (so you can | 
 | 761 | do pointer arithmetic between elements), supports efficient push_back/pop_back | 
 | 762 | operations, supports efficient random access to its elements, etc.</p> | 
 | 763 |  | 
 | 764 | <p>The advantage of SmallVector is that it allocates space for | 
 | 765 | some number of elements (N) <b>in the object itself</b>.  Because of this, if | 
 | 766 | the SmallVector is dynamically smaller than N, no malloc is performed.  This can | 
 | 767 | be a big win in cases where the malloc/free call is far more expensive than the | 
 | 768 | code that fiddles around with the elements.</p> | 
 | 769 |  | 
 | 770 | <p>This is good for vectors that are "usually small" (e.g. the number of | 
 | 771 | predecessors/successors of a block is usually less than 8).  On the other hand, | 
 | 772 | this makes the size of the SmallVector itself large, so you don't want to | 
 | 773 | allocate lots of them (doing so will waste a lot of space).  As such, | 
 | 774 | SmallVectors are most useful when on the stack.</p> | 
 | 775 |  | 
 | 776 | <p>SmallVector also provides a nice portable and efficient replacement for | 
 | 777 | <tt>alloca</tt>.</p> | 
 | 778 |  | 
 | 779 | </div> | 
 | 780 |  | 
 | 781 | <!-- _______________________________________________________________________ --> | 
 | 782 | <div class="doc_subsubsection"> | 
 | 783 |   <a name="dss_vector"><vector></a> | 
 | 784 | </div> | 
 | 785 |  | 
 | 786 | <div class="doc_text"> | 
 | 787 | <p> | 
 | 788 | std::vector is well loved and respected.  It is useful when SmallVector isn't: | 
 | 789 | when the size of the vector is often large (thus the small optimization will | 
 | 790 | rarely be a benefit) or if you will be allocating many instances of the vector | 
 | 791 | itself (which would waste space for elements that aren't in the container). | 
 | 792 | vector is also useful when interfacing with code that expects vectors :). | 
 | 793 | </p> | 
 | 794 | </div> | 
 | 795 |  | 
 | 796 | <!-- _______________________________________________________________________ --> | 
 | 797 | <div class="doc_subsubsection"> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 798 |   <a name="dss_deque"><deque></a> | 
 | 799 | </div> | 
 | 800 |  | 
 | 801 | <div class="doc_text"> | 
 | 802 | <p>std::deque is, in some senses, a generalized version of std::vector.  Like | 
 | 803 | std::vector, it provides constant time random access and other similar | 
 | 804 | properties, but it also provides efficient access to the front of the list.  It | 
 | 805 | does not guarantee continuity of elements within memory.</p> | 
 | 806 |  | 
 | 807 | <p>In exchange for this extra flexibility, std::deque has significantly higher | 
 | 808 | constant factor costs than std::vector.  If possible, use std::vector or | 
 | 809 | something cheaper.</p> | 
 | 810 | </div> | 
 | 811 |  | 
 | 812 | <!-- _______________________________________________________________________ --> | 
 | 813 | <div class="doc_subsubsection"> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 814 |   <a name="dss_list"><list></a> | 
 | 815 | </div> | 
 | 816 |  | 
 | 817 | <div class="doc_text"> | 
 | 818 | <p>std::list is an extremely inefficient class that is rarely useful. | 
 | 819 | It performs a heap allocation for every element inserted into it, thus having an | 
 | 820 | extremely high constant factor, particularly for small data types.  std::list | 
 | 821 | also only supports bidirectional iteration, not random access iteration.</p> | 
 | 822 |  | 
 | 823 | <p>In exchange for this high cost, std::list supports efficient access to both | 
 | 824 | ends of the list (like std::deque, but unlike std::vector or SmallVector).  In | 
 | 825 | addition, the iterator invalidation characteristics of std::list are stronger | 
 | 826 | than that of a vector class: inserting or removing an element into the list does | 
 | 827 | not invalidate iterator or pointers to other elements in the list.</p> | 
 | 828 | </div> | 
 | 829 |  | 
 | 830 | <!-- _______________________________________________________________________ --> | 
 | 831 | <div class="doc_subsubsection"> | 
 | 832 |   <a name="dss_ilist">llvm/ADT/ilist</a> | 
 | 833 | </div> | 
 | 834 |  | 
 | 835 | <div class="doc_text"> | 
 | 836 | <p><tt>ilist<T></tt> implements an 'intrusive' doubly-linked list.  It is | 
 | 837 | intrusive, because it requires the element to store and provide access to the | 
 | 838 | prev/next pointers for the list.</p> | 
 | 839 |  | 
 | 840 | <p>ilist has the same drawbacks as std::list, and additionally requires an | 
 | 841 | ilist_traits implementation for the element type, but it provides some novel | 
 | 842 | characteristics.  In particular, it can efficiently store polymorphic objects, | 
 | 843 | the traits class is informed when an element is inserted or removed from the | 
 | 844 | list, and ilists are guaranteed to support a constant-time splice operation. | 
 | 845 | </p> | 
 | 846 |  | 
 | 847 | <p>These properties are exactly what we want for things like Instructions and | 
 | 848 | basic blocks, which is why these are implemented with ilists.</p> | 
 | 849 | </div> | 
 | 850 |  | 
 | 851 | <!-- _______________________________________________________________________ --> | 
 | 852 | <div class="doc_subsubsection"> | 
 | 853 |   <a name="dss_other">Other options</a> | 
 | 854 | </div> | 
 | 855 |  | 
 | 856 | <div class="doc_text"> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 857 | <p>Other STL containers are available, such as std::string.</p> | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 858 |  | 
 | 859 | <p>There are also various STL adapter classes such as std::queue, | 
 | 860 | std::priority_queue, std::stack, etc.  These provide simplified access to an | 
 | 861 | underlying container but don't affect the cost of the container itself.</p> | 
 | 862 |  | 
 | 863 | </div> | 
 | 864 |  | 
 | 865 |  | 
 | 866 | <!-- ======================================================================= --> | 
 | 867 | <div class="doc_subsection"> | 
 | 868 |   <a name="ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a> | 
 | 869 | </div> | 
 | 870 |  | 
 | 871 | <div class="doc_text"> | 
 | 872 |  | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 873 | <p>Set-like containers are useful when you need to canonicalize multiple values | 
 | 874 | into a single representation.  There are several different choices for how to do | 
 | 875 | this, providing various trade-offs.</p> | 
 | 876 |  | 
 | 877 | </div> | 
 | 878 |  | 
 | 879 |  | 
 | 880 | <!-- _______________________________________________________________________ --> | 
 | 881 | <div class="doc_subsubsection"> | 
 | 882 |   <a name="dss_sortedvectorset">A sorted 'vector'</a> | 
 | 883 | </div> | 
 | 884 |  | 
 | 885 | <div class="doc_text"> | 
 | 886 |  | 
| Chris Lattner | 3b23a8c | 2007-02-03 08:10:45 +0000 | [diff] [blame^] | 887 | <p>If you intend to insert a lot of elements, then do a lot of queries, a | 
 | 888 | great approach is to use a vector (or other sequential container) with | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 889 | std::sort+std::unique to remove duplicates.  This approach works really well if | 
| Chris Lattner | 3b23a8c | 2007-02-03 08:10:45 +0000 | [diff] [blame^] | 890 | your usage pattern has these two distinct phases (insert then query), and can be | 
 | 891 | coupled with a good choice of <a href="#ds_sequential">sequential container</a>. | 
 | 892 | </p> | 
 | 893 |  | 
 | 894 | <p> | 
 | 895 | This combination provides the several nice properties: the result data is | 
 | 896 | contiguous in memory (good for cache locality), has few allocations, is easy to | 
 | 897 | address (iterators in the final vector are just indices or pointers), and can be | 
 | 898 | efficiently queried with a standard binary or radix search.</p> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 899 |  | 
 | 900 | </div> | 
 | 901 |  | 
 | 902 | <!-- _______________________________________________________________________ --> | 
 | 903 | <div class="doc_subsubsection"> | 
 | 904 |   <a name="dss_smallset">"llvm/ADT/SmallSet.h"</a> | 
 | 905 | </div> | 
 | 906 |  | 
 | 907 | <div class="doc_text"> | 
 | 908 |  | 
 | 909 | <p>If you have a set-like datastructure that is usually small and whose elements | 
| Chris Lattner | 4ddfac1 | 2007-02-03 07:59:51 +0000 | [diff] [blame] | 910 | are reasonably small, a <tt>SmallSet<Type, N></tt> is a good choice.  This set | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 911 | has space for N elements in place (thus, if the set is dynamically smaller than | 
 | 912 | N, no malloc traffic is required) and access them with a simple linear search. | 
 | 913 | When the set grows beyond 'N', it allocates a more expensive representation that | 
 | 914 | guarantees efficient access (for most types, it falls back to std::set, but for | 
 | 915 | pointers it uses something far better, see <a  | 
 | 916 | href="#dss_smallptrset">SmallPtrSet</a>).</p> | 
 | 917 |  | 
 | 918 | <p>The magic of this class is that it handles small sets extremely efficiently, | 
 | 919 | but gracefully handles extremely large sets without loss of efficiency.  The | 
 | 920 | drawback is that the interface is quite small: it supports insertion, queries | 
 | 921 | and erasing, but does not support iteration.</p> | 
 | 922 |  | 
 | 923 | </div> | 
 | 924 |  | 
 | 925 | <!-- _______________________________________________________________________ --> | 
 | 926 | <div class="doc_subsubsection"> | 
 | 927 |   <a name="dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a> | 
 | 928 | </div> | 
 | 929 |  | 
 | 930 | <div class="doc_text"> | 
 | 931 |  | 
 | 932 | <p>SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is  | 
 | 933 | transparently implemented with a SmallPtrSet), but also suports iterators.  If | 
 | 934 | more than 'N' allocations are performed, a single quadratically | 
 | 935 | probed hash table is allocated and grows as needed, providing extremely | 
 | 936 | efficient access (constant time insertion/deleting/queries with low constant | 
 | 937 | factors) and is very stingy with malloc traffic.</p> | 
 | 938 |  | 
 | 939 | <p>Note that, unlike std::set, the iterators of SmallPtrSet are invalidated | 
 | 940 | whenever an insertion occurs.  Also, the values visited by the iterators are not | 
 | 941 | visited in sorted order.</p> | 
 | 942 |  | 
 | 943 | </div> | 
 | 944 |  | 
 | 945 | <!-- _______________________________________________________________________ --> | 
 | 946 | <div class="doc_subsubsection"> | 
 | 947 |   <a name="dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a> | 
 | 948 | </div> | 
 | 949 |  | 
 | 950 | <div class="doc_text"> | 
 | 951 |  | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 952 | <p> | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 953 | FoldingSet is an aggregate class that is really good at uniquing | 
 | 954 | expensive-to-create or polymorphic objects.  It is a combination of a chained | 
 | 955 | hash table with intrusive links (uniqued objects are required to inherit from | 
 | 956 | FoldingSetNode) that uses SmallVector as part of its ID process.</p> | 
 | 957 |  | 
 | 958 | <p>Consider a case where you want to implement a "getorcreate_foo" method for | 
 | 959 | a complex object (for example, a node in the code generator).  The client has a | 
 | 960 | description of *what* it wants to generate (it knows the opcode and all the | 
 | 961 | operands), but we don't want to 'new' a node, then try inserting it into a set | 
 | 962 | only to find out it already exists (at which point we would have to delete it | 
 | 963 | and return the node that already exists). | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 964 | </p> | 
 | 965 |  | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 966 | <p>To support this style of client, FoldingSet perform a query with a | 
 | 967 | FoldingSetNodeID (which wraps SmallVector) that can be used to describe the | 
 | 968 | element that we want to query for.  The query either returns the element | 
 | 969 | matching the ID or it returns an opaque ID that indicates where insertion should | 
 | 970 | take place.</p> | 
 | 971 |  | 
 | 972 | <p>Because FoldingSet uses intrusive links, it can support polymorphic objects | 
 | 973 | in the set (for example, you can have SDNode instances mixed with LoadSDNodes). | 
 | 974 | Because the elements are individually allocated, pointers to the elements are | 
 | 975 | stable: inserting or removing elements does not invalidate any pointers to other | 
 | 976 | elements. | 
 | 977 | </p> | 
 | 978 |  | 
 | 979 | </div> | 
 | 980 |  | 
 | 981 | <!-- _______________________________________________________________________ --> | 
 | 982 | <div class="doc_subsubsection"> | 
 | 983 |   <a name="dss_set"><set></a> | 
 | 984 | </div> | 
 | 985 |  | 
 | 986 | <div class="doc_text"> | 
 | 987 |  | 
 | 988 | <p>std::set is a reasonable all-around set class, which is good at many things | 
| Chris Lattner | 3b23a8c | 2007-02-03 08:10:45 +0000 | [diff] [blame^] | 989 | but great at nothing.  std::set allocates memory for each element | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 990 | inserted (thus it is very malloc intensive) and typically stores three pointers | 
 | 991 | with every element (thus adding a large amount of per-element space overhead). | 
 | 992 | It offers guaranteed log(n) performance, which is not particularly fast. | 
 | 993 | </p> | 
 | 994 |  | 
 | 995 | <p>The advantages of std::set is that its iterators are stable (deleting or | 
 | 996 | inserting an element from the set does not affect iterators or pointers to other | 
 | 997 | elements) and that iteration over the set is guaranteed to be in sorted order. | 
 | 998 | If the elements in the set are large, then the relative overhead of the pointers | 
 | 999 | and malloc traffic is not a big deal, but if the elements of the set are small, | 
 | 1000 | std::set is almost never a good choice.</p> | 
 | 1001 |  | 
 | 1002 | </div> | 
 | 1003 |  | 
 | 1004 | <!-- _______________________________________________________________________ --> | 
 | 1005 | <div class="doc_subsubsection"> | 
 | 1006 |   <a name="dss_setvector">"llvm/ADT/SetVector.h"</a> | 
 | 1007 | </div> | 
 | 1008 |  | 
 | 1009 | <div class="doc_text"> | 
 | 1010 | <p>LLVM's SetVector<Type> is actually a combination of a set along with | 
 | 1011 | a <a href="#ds_sequential">Sequential Container</a>.  The important property | 
 | 1012 | that this provides is efficient insertion with uniquing (duplicate elements are | 
 | 1013 | ignored) with iteration support.  It implements this by inserting elements into | 
 | 1014 | both a set-like container and the sequential container, using the set-like | 
 | 1015 | container for uniquing and the sequential container for iteration. | 
 | 1016 | </p> | 
 | 1017 |  | 
 | 1018 | <p>The difference between SetVector and other sets is that the order of | 
 | 1019 | iteration is guaranteed to match the order of insertion into the SetVector. | 
 | 1020 | This property is really important for things like sets of pointers.  Because | 
 | 1021 | pointer values are non-deterministic (e.g. vary across runs of the program on | 
 | 1022 | different machines), iterating over the pointers in a std::set or other set will | 
 | 1023 | not be in a well-defined order.</p> | 
 | 1024 |  | 
 | 1025 | <p> | 
 | 1026 | The drawback of SetVector is that it requires twice as much space as a normal | 
 | 1027 | set and has the sum of constant factors from the set-like container and the  | 
 | 1028 | sequential container that it uses.  Use it *only* if you need to iterate over  | 
 | 1029 | the elements in a deterministic order.  SetVector is also expensive to delete | 
 | 1030 | elements out of (linear time). | 
 | 1031 | </p> | 
 | 1032 |  | 
 | 1033 | </div> | 
 | 1034 |  | 
 | 1035 | <!-- _______________________________________________________________________ --> | 
 | 1036 | <div class="doc_subsubsection"> | 
 | 1037 |   <a name="dss_otherset">Other Options</a> | 
 | 1038 | </div> | 
 | 1039 |  | 
 | 1040 | <div class="doc_text"> | 
 | 1041 |  | 
 | 1042 | <p> | 
 | 1043 | The STL provides several other options, such as std::multiset and the various  | 
 | 1044 | "hash_set" like containers (whether from C++TR1 or from the SGI library).</p> | 
 | 1045 |  | 
 | 1046 | <p>std::multiset is useful if you're not interested in elimination of | 
 | 1047 | duplicates, but has all the drawbacks of std::set.  A sorted vector or some | 
 | 1048 | other approach is almost always better.</p> | 
 | 1049 |  | 
 | 1050 | <p>The various hash_set implementations (exposed portably by | 
 | 1051 | "llvm/ADT/hash_set") is a standard chained hashtable.  This algorithm is malloc | 
 | 1052 | intensive like std::set (performing an allocation for each element inserted, | 
 | 1053 | thus having really high constant factors) but (usually) provides O(1) | 
 | 1054 | insertion/deletion of elements.  This can be useful if your elements are large | 
 | 1055 | (thus making the constant-factor cost relatively low).  Element iteration does | 
 | 1056 | not visit elements in a useful order.</p> | 
 | 1057 |  | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 1058 | </div> | 
 | 1059 |  | 
 | 1060 | <!-- ======================================================================= --> | 
 | 1061 | <div class="doc_subsection"> | 
 | 1062 |   <a name="ds_map">Map-Like Containers (std::map, DenseMap, etc)</a> | 
 | 1063 | </div> | 
 | 1064 |  | 
 | 1065 | <div class="doc_text"> | 
 | 1066 | sorted vector | 
 | 1067 | std::map | 
 | 1068 | DenseMap | 
| Chris Lattner | 74c4ca1 | 2007-02-03 07:59:07 +0000 | [diff] [blame] | 1069 | UniqueVector | 
| Chris Lattner | 098129a | 2007-02-03 03:04:03 +0000 | [diff] [blame] | 1070 | IndexedMap | 
 | 1071 | hash_map | 
 | 1072 | CStringMap | 
 | 1073 | </div> | 
 | 1074 |  | 
| Chris Lattner | f623a08 | 2005-10-17 01:36:23 +0000 | [diff] [blame] | 1075 |  | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1076 | <!-- *********************************************************************** --> | 
 | 1077 | <div class="doc_section"> | 
 | 1078 |   <a name="common">Helpful Hints for Common Operations</a> | 
 | 1079 | </div> | 
 | 1080 | <!-- *********************************************************************** --> | 
 | 1081 |  | 
 | 1082 | <div class="doc_text"> | 
 | 1083 |  | 
 | 1084 | <p>This section describes how to perform some very simple transformations of | 
 | 1085 | LLVM code.  This is meant to give examples of common idioms used, showing the | 
 | 1086 | practical side of LLVM transformations.  <p> Because this is a "how-to" section, | 
 | 1087 | you should also read about the main classes that you will be working with.  The | 
 | 1088 | <a href="#coreclasses">Core LLVM Class Hierarchy Reference</a> contains details | 
 | 1089 | and descriptions of the main classes that you should know about.</p> | 
 | 1090 |  | 
 | 1091 | </div> | 
 | 1092 |  | 
 | 1093 | <!-- NOTE: this section should be heavy on example code --> | 
 | 1094 | <!-- ======================================================================= --> | 
 | 1095 | <div class="doc_subsection"> | 
 | 1096 |   <a name="inspection">Basic Inspection and Traversal Routines</a> | 
 | 1097 | </div> | 
 | 1098 |  | 
 | 1099 | <div class="doc_text"> | 
 | 1100 |  | 
 | 1101 | <p>The LLVM compiler infrastructure have many different data structures that may | 
 | 1102 | be traversed.  Following the example of the C++ standard template library, the | 
 | 1103 | techniques used to traverse these various data structures are all basically the | 
 | 1104 | same.  For a enumerable sequence of values, the <tt>XXXbegin()</tt> function (or | 
 | 1105 | method) returns an iterator to the start of the sequence, the <tt>XXXend()</tt> | 
 | 1106 | function returns an iterator pointing to one past the last valid element of the | 
 | 1107 | sequence, and there is some <tt>XXXiterator</tt> data type that is common | 
 | 1108 | between the two operations.</p> | 
 | 1109 |  | 
 | 1110 | <p>Because the pattern for iteration is common across many different aspects of | 
 | 1111 | the program representation, the standard template library algorithms may be used | 
 | 1112 | on them, and it is easier to remember how to iterate. First we show a few common | 
 | 1113 | examples of the data structures that need to be traversed.  Other data | 
 | 1114 | structures are traversed in very similar ways.</p> | 
 | 1115 |  | 
 | 1116 | </div> | 
 | 1117 |  | 
 | 1118 | <!-- _______________________________________________________________________ --> | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1119 | <div class="doc_subsubsection"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1120 |   <a name="iterate_function">Iterating over the </a><a | 
 | 1121 |   href="#BasicBlock"><tt>BasicBlock</tt></a>s in a <a | 
 | 1122 |   href="#Function"><tt>Function</tt></a> | 
 | 1123 | </div> | 
 | 1124 |  | 
 | 1125 | <div class="doc_text"> | 
 | 1126 |  | 
 | 1127 | <p>It's quite common to have a <tt>Function</tt> instance that you'd like to | 
 | 1128 | transform in some way; in particular, you'd like to manipulate its | 
 | 1129 | <tt>BasicBlock</tt>s.  To facilitate this, you'll need to iterate over all of | 
 | 1130 | the <tt>BasicBlock</tt>s that constitute the <tt>Function</tt>. The following is | 
 | 1131 | an example that prints the name of a <tt>BasicBlock</tt> and the number of | 
 | 1132 | <tt>Instruction</tt>s it contains:</p> | 
 | 1133 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1134 | <div class="doc_code"> | 
 | 1135 | <pre> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1136 | // <i>func is a pointer to a Function instance</i> | 
 | 1137 | for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) | 
 | 1138 |   // <i>Print out the name of the basic block if it has one, and then the</i> | 
 | 1139 |   // <i>number of instructions that it contains</i> | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1140 |   llvm::cerr << "Basic block (name=" << i->getName() << ") has " | 
 | 1141 |              << i->size() << " instructions.\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1142 | </pre> | 
 | 1143 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1144 |  | 
 | 1145 | <p>Note that i can be used as if it were a pointer for the purposes of | 
| Joel Stanley | 9b96c44 | 2002-09-06 21:55:13 +0000 | [diff] [blame] | 1146 | invoking member functions of the <tt>Instruction</tt> class.  This is | 
 | 1147 | because the indirection operator is overloaded for the iterator | 
| Chris Lattner | 7496ec5 | 2003-08-05 22:54:23 +0000 | [diff] [blame] | 1148 | classes.  In the above code, the expression <tt>i->size()</tt> is | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1149 | exactly equivalent to <tt>(*i).size()</tt> just like you'd expect.</p> | 
 | 1150 |  | 
 | 1151 | </div> | 
 | 1152 |  | 
 | 1153 | <!-- _______________________________________________________________________ --> | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1154 | <div class="doc_subsubsection"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1155 |   <a name="iterate_basicblock">Iterating over the </a><a | 
 | 1156 |   href="#Instruction"><tt>Instruction</tt></a>s in a <a | 
 | 1157 |   href="#BasicBlock"><tt>BasicBlock</tt></a> | 
 | 1158 | </div> | 
 | 1159 |  | 
 | 1160 | <div class="doc_text"> | 
 | 1161 |  | 
 | 1162 | <p>Just like when dealing with <tt>BasicBlock</tt>s in <tt>Function</tt>s, it's | 
 | 1163 | easy to iterate over the individual instructions that make up | 
 | 1164 | <tt>BasicBlock</tt>s. Here's a code snippet that prints out each instruction in | 
 | 1165 | a <tt>BasicBlock</tt>:</p> | 
 | 1166 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1167 | <div class="doc_code"> | 
| Chris Lattner | 55c0461 | 2005-03-06 06:00:13 +0000 | [diff] [blame] | 1168 | <pre> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1169 | // <i>blk is a pointer to a BasicBlock instance</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1170 | for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i) | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1171 |    // <i>The next statement works since operator<<(ostream&,...)</i> | 
 | 1172 |    // <i>is overloaded for Instruction&</i> | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1173 |    llvm::cerr << *i << "\n"; | 
| Chris Lattner | 55c0461 | 2005-03-06 06:00:13 +0000 | [diff] [blame] | 1174 | </pre> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1175 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1176 |  | 
 | 1177 | <p>However, this isn't really the best way to print out the contents of a | 
 | 1178 | <tt>BasicBlock</tt>!  Since the ostream operators are overloaded for virtually | 
 | 1179 | anything you'll care about, you could have just invoked the print routine on the | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1180 | basic block itself: <tt>llvm::cerr << *blk << "\n";</tt>.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1181 |  | 
 | 1182 | </div> | 
 | 1183 |  | 
 | 1184 | <!-- _______________________________________________________________________ --> | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1185 | <div class="doc_subsubsection"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1186 |   <a name="iterate_institer">Iterating over the </a><a | 
 | 1187 |   href="#Instruction"><tt>Instruction</tt></a>s in a <a | 
 | 1188 |   href="#Function"><tt>Function</tt></a> | 
 | 1189 | </div> | 
 | 1190 |  | 
 | 1191 | <div class="doc_text"> | 
 | 1192 |  | 
 | 1193 | <p>If you're finding that you commonly iterate over a <tt>Function</tt>'s | 
 | 1194 | <tt>BasicBlock</tt>s and then that <tt>BasicBlock</tt>'s <tt>Instruction</tt>s, | 
 | 1195 | <tt>InstIterator</tt> should be used instead. You'll need to include <a | 
 | 1196 | href="/doxygen/InstIterator_8h-source.html"><tt>llvm/Support/InstIterator.h</tt></a>, | 
 | 1197 | and then instantiate <tt>InstIterator</tt>s explicitly in your code.  Here's a | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1198 | small example that shows how to dump all instructions in a function to the standard error stream:<p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1199 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1200 | <div class="doc_code"> | 
 | 1201 | <pre> | 
 | 1202 | #include "<a href="/doxygen/InstIterator_8h-source.html">llvm/Support/InstIterator.h</a>" | 
 | 1203 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1204 | // <i>F is a ptr to a Function instance</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1205 | for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i) | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1206 |   llvm::cerr << *i << "\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1207 | </pre> | 
 | 1208 | </div> | 
 | 1209 |  | 
 | 1210 | <p>Easy, isn't it?  You can also use <tt>InstIterator</tt>s to fill a | 
| Joel Stanley | e7be650 | 2002-09-09 15:50:33 +0000 | [diff] [blame] | 1211 | worklist with its initial contents.  For example, if you wanted to | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1212 | initialize a worklist to contain all instructions in a <tt>Function</tt> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1213 | F, all you would need to do is something like:</p> | 
 | 1214 |  | 
 | 1215 | <div class="doc_code"> | 
 | 1216 | <pre> | 
 | 1217 | std::set<Instruction*> worklist; | 
 | 1218 | worklist.insert(inst_begin(F), inst_end(F)); | 
 | 1219 | </pre> | 
 | 1220 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1221 |  | 
 | 1222 | <p>The STL set <tt>worklist</tt> would now contain all instructions in the | 
 | 1223 | <tt>Function</tt> pointed to by F.</p> | 
 | 1224 |  | 
 | 1225 | </div> | 
 | 1226 |  | 
 | 1227 | <!-- _______________________________________________________________________ --> | 
 | 1228 | <div class="doc_subsubsection"> | 
 | 1229 |   <a name="iterate_convert">Turning an iterator into a class pointer (and | 
 | 1230 |   vice-versa)</a> | 
 | 1231 | </div> | 
 | 1232 |  | 
 | 1233 | <div class="doc_text"> | 
 | 1234 |  | 
 | 1235 | <p>Sometimes, it'll be useful to grab a reference (or pointer) to a class | 
| Joel Stanley | 9b96c44 | 2002-09-06 21:55:13 +0000 | [diff] [blame] | 1236 | instance when all you've got at hand is an iterator.  Well, extracting | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1237 | a reference or a pointer from an iterator is very straight-forward. | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1238 | Assuming that <tt>i</tt> is a <tt>BasicBlock::iterator</tt> and <tt>j</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1239 | is a <tt>BasicBlock::const_iterator</tt>:</p> | 
 | 1240 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1241 | <div class="doc_code"> | 
 | 1242 | <pre> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1243 | Instruction& inst = *i;   // <i>Grab reference to instruction reference</i> | 
 | 1244 | Instruction* pinst = &*i; // <i>Grab pointer to instruction reference</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1245 | const Instruction& inst = *j; | 
 | 1246 | </pre> | 
 | 1247 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1248 |  | 
 | 1249 | <p>However, the iterators you'll be working with in the LLVM framework are | 
 | 1250 | special: they will automatically convert to a ptr-to-instance type whenever they | 
 | 1251 | need to.  Instead of dereferencing the iterator and then taking the address of | 
 | 1252 | the result, you can simply assign the iterator to the proper pointer type and | 
 | 1253 | you get the dereference and address-of operation as a result of the assignment | 
 | 1254 | (behind the scenes, this is a result of overloading casting mechanisms).  Thus | 
 | 1255 | the last line of the last example,</p> | 
 | 1256 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1257 | <div class="doc_code"> | 
 | 1258 | <pre> | 
 | 1259 | Instruction* pinst = &*i; | 
 | 1260 | </pre> | 
 | 1261 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1262 |  | 
 | 1263 | <p>is semantically equivalent to</p> | 
 | 1264 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1265 | <div class="doc_code"> | 
 | 1266 | <pre> | 
 | 1267 | Instruction* pinst = i; | 
 | 1268 | </pre> | 
 | 1269 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1270 |  | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1271 | <p>It's also possible to turn a class pointer into the corresponding iterator, | 
 | 1272 | and this is a constant time operation (very efficient).  The following code | 
 | 1273 | snippet illustrates use of the conversion constructors provided by LLVM | 
 | 1274 | iterators.  By using these, you can explicitly grab the iterator of something | 
 | 1275 | without actually obtaining it via iteration over some structure:</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1276 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1277 | <div class="doc_code"> | 
 | 1278 | <pre> | 
 | 1279 | void printNextInstruction(Instruction* inst) { | 
 | 1280 |   BasicBlock::iterator it(inst); | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1281 |   ++it; // <i>After this line, it refers to the instruction after *inst</i> | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1282 |   if (it != inst->getParent()->end()) llvm::cerr << *it << "\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1283 | } | 
 | 1284 | </pre> | 
 | 1285 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1286 |  | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1287 | </div> | 
 | 1288 |  | 
 | 1289 | <!--_______________________________________________________________________--> | 
 | 1290 | <div class="doc_subsubsection"> | 
 | 1291 |   <a name="iterate_complex">Finding call sites: a slightly more complex | 
 | 1292 |   example</a> | 
 | 1293 | </div> | 
 | 1294 |  | 
 | 1295 | <div class="doc_text"> | 
 | 1296 |  | 
 | 1297 | <p>Say that you're writing a FunctionPass and would like to count all the | 
 | 1298 | locations in the entire module (that is, across every <tt>Function</tt>) where a | 
 | 1299 | certain function (i.e., some <tt>Function</tt>*) is already in scope.  As you'll | 
 | 1300 | learn later, you may want to use an <tt>InstVisitor</tt> to accomplish this in a | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1301 | much more straight-forward manner, but this example will allow us to explore how | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1302 | you'd do it if you didn't have <tt>InstVisitor</tt> around. In pseudocode, this | 
 | 1303 | is what we want to do:</p> | 
 | 1304 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1305 | <div class="doc_code"> | 
 | 1306 | <pre> | 
 | 1307 | initialize callCounter to zero | 
 | 1308 | for each Function f in the Module | 
 | 1309 |   for each BasicBlock b in f | 
 | 1310 |     for each Instruction i in b | 
 | 1311 |       if (i is a CallInst and calls the given function) | 
 | 1312 |         increment callCounter | 
 | 1313 | </pre> | 
 | 1314 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1315 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1316 | <p>And the actual code is (remember, because we're writing a | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1317 | <tt>FunctionPass</tt>, our <tt>FunctionPass</tt>-derived class simply has to | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1318 | override the <tt>runOnFunction</tt> method):</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1319 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1320 | <div class="doc_code"> | 
 | 1321 | <pre> | 
 | 1322 | Function* targetFunc = ...; | 
 | 1323 |  | 
 | 1324 | class OurFunctionPass : public FunctionPass { | 
 | 1325 |   public: | 
 | 1326 |     OurFunctionPass(): callCounter(0) { } | 
 | 1327 |  | 
 | 1328 |     virtual runOnFunction(Function& F) { | 
 | 1329 |       for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) { | 
 | 1330 |         for (BasicBlock::iterator i = b->begin(); ie = b->end(); i != ie; ++i) { | 
 | 1331 |           if (<a href="#CallInst">CallInst</a>* callInst = <a href="#isa">dyn_cast</a><<a | 
 | 1332 |  href="#CallInst">CallInst</a>>(&*i)) { | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1333 |             // <i>We know we've encountered a call instruction, so we</i> | 
 | 1334 |             // <i>need to determine if it's a call to the</i> | 
 | 1335 |             // <i>function pointed to by m_func or not</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1336 |  | 
 | 1337 |             if (callInst->getCalledFunction() == targetFunc) | 
 | 1338 |               ++callCounter; | 
 | 1339 |           } | 
 | 1340 |         } | 
 | 1341 |       } | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1342 |     } | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1343 |  | 
 | 1344 |   private: | 
 | 1345 |     unsigned  callCounter; | 
 | 1346 | }; | 
 | 1347 | </pre> | 
 | 1348 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1349 |  | 
 | 1350 | </div> | 
 | 1351 |  | 
| Brian Gaeke | f1972c6 | 2003-11-07 19:25:45 +0000 | [diff] [blame] | 1352 | <!--_______________________________________________________________________--> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1353 | <div class="doc_subsubsection"> | 
 | 1354 |   <a name="calls_and_invokes">Treating calls and invokes the same way</a> | 
 | 1355 | </div> | 
 | 1356 |  | 
 | 1357 | <div class="doc_text"> | 
 | 1358 |  | 
 | 1359 | <p>You may have noticed that the previous example was a bit oversimplified in | 
 | 1360 | that it did not deal with call sites generated by 'invoke' instructions. In | 
 | 1361 | this, and in other situations, you may find that you want to treat | 
 | 1362 | <tt>CallInst</tt>s and <tt>InvokeInst</tt>s the same way, even though their | 
 | 1363 | most-specific common base class is <tt>Instruction</tt>, which includes lots of | 
 | 1364 | less closely-related things. For these cases, LLVM provides a handy wrapper | 
 | 1365 | class called <a | 
| Reid Spencer | 05fe4b0 | 2006-03-14 05:39:39 +0000 | [diff] [blame] | 1366 | href="http://llvm.org/doxygen/classllvm_1_1CallSite.html"><tt>CallSite</tt></a>. | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1367 | It is essentially a wrapper around an <tt>Instruction</tt> pointer, with some | 
 | 1368 | methods that provide functionality common to <tt>CallInst</tt>s and | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1369 | <tt>InvokeInst</tt>s.</p> | 
 | 1370 |  | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1371 | <p>This class has "value semantics": it should be passed by value, not by | 
 | 1372 | reference and it should not be dynamically allocated or deallocated using | 
 | 1373 | <tt>operator new</tt> or <tt>operator delete</tt>. It is efficiently copyable, | 
 | 1374 | assignable and constructable, with costs equivalents to that of a bare pointer. | 
 | 1375 | If you look at its definition, it has only a single pointer member.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1376 |  | 
 | 1377 | </div> | 
 | 1378 |  | 
| Chris Lattner | 1a3105b | 2002-09-09 05:49:39 +0000 | [diff] [blame] | 1379 | <!--_______________________________________________________________________--> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1380 | <div class="doc_subsubsection"> | 
 | 1381 |   <a name="iterate_chains">Iterating over def-use & use-def chains</a> | 
 | 1382 | </div> | 
 | 1383 |  | 
 | 1384 | <div class="doc_text"> | 
 | 1385 |  | 
 | 1386 | <p>Frequently, we might have an instance of the <a | 
| Chris Lattner | 0081517 | 2007-01-04 22:01:45 +0000 | [diff] [blame] | 1387 | href="/doxygen/classllvm_1_1Value.html">Value Class</a> and we want to | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 1388 | determine which <tt>User</tt>s use the <tt>Value</tt>.  The list of all | 
 | 1389 | <tt>User</tt>s of a particular <tt>Value</tt> is called a <i>def-use</i> chain. | 
 | 1390 | For example, let's say we have a <tt>Function*</tt> named <tt>F</tt> to a | 
 | 1391 | particular function <tt>foo</tt>. Finding all of the instructions that | 
 | 1392 | <i>use</i> <tt>foo</tt> is as simple as iterating over the <i>def-use</i> chain | 
 | 1393 | of <tt>F</tt>:</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1394 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1395 | <div class="doc_code"> | 
 | 1396 | <pre> | 
 | 1397 | Function* F = ...; | 
 | 1398 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1399 | for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i) | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1400 |   if (Instruction *Inst = dyn_cast<Instruction>(*i)) { | 
| Bill Wendling | 832171c | 2006-12-07 20:04:42 +0000 | [diff] [blame] | 1401 |     llvm::cerr << "F is used in instruction:\n"; | 
 | 1402 |     llvm::cerr << *Inst << "\n"; | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1403 |   } | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1404 | </pre> | 
 | 1405 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1406 |  | 
 | 1407 | <p>Alternately, it's common to have an instance of the <a | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 1408 | href="/doxygen/classllvm_1_1User.html">User Class</a> and need to know what | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1409 | <tt>Value</tt>s are used by it.  The list of all <tt>Value</tt>s used by a | 
 | 1410 | <tt>User</tt> is known as a <i>use-def</i> chain.  Instances of class | 
 | 1411 | <tt>Instruction</tt> are common <tt>User</tt>s, so we might want to iterate over | 
 | 1412 | all of the values that a particular instruction uses (that is, the operands of | 
 | 1413 | the particular <tt>Instruction</tt>):</p> | 
 | 1414 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1415 | <div class="doc_code"> | 
 | 1416 | <pre> | 
 | 1417 | Instruction* pi = ...; | 
 | 1418 |  | 
 | 1419 | for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) { | 
 | 1420 |   Value* v = *i; | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1421 |   // <i>...</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1422 | } | 
 | 1423 | </pre> | 
 | 1424 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1425 |  | 
| Chris Lattner | 1a3105b | 2002-09-09 05:49:39 +0000 | [diff] [blame] | 1426 | <!-- | 
 | 1427 |   def-use chains ("finding all users of"): Value::use_begin/use_end | 
 | 1428 |   use-def chains ("finding all values used"): User::op_begin/op_end [op=operand] | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1429 | --> | 
 | 1430 |  | 
 | 1431 | </div> | 
 | 1432 |  | 
 | 1433 | <!-- ======================================================================= --> | 
 | 1434 | <div class="doc_subsection"> | 
 | 1435 |   <a name="simplechanges">Making simple changes</a> | 
 | 1436 | </div> | 
 | 1437 |  | 
 | 1438 | <div class="doc_text"> | 
 | 1439 |  | 
 | 1440 | <p>There are some primitive transformation operations present in the LLVM | 
| Joel Stanley | 753eb71 | 2002-09-11 22:32:24 +0000 | [diff] [blame] | 1441 | infrastructure that are worth knowing about.  When performing | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1442 | transformations, it's fairly common to manipulate the contents of basic | 
 | 1443 | blocks. This section describes some of the common methods for doing so | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1444 | and gives example code.</p> | 
 | 1445 |  | 
 | 1446 | </div> | 
 | 1447 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1448 | <!--_______________________________________________________________________--> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1449 | <div class="doc_subsubsection"> | 
 | 1450 |   <a name="schanges_creating">Creating and inserting new | 
 | 1451 |   <tt>Instruction</tt>s</a> | 
 | 1452 | </div> | 
 | 1453 |  | 
 | 1454 | <div class="doc_text"> | 
 | 1455 |  | 
 | 1456 | <p><i>Instantiating Instructions</i></p> | 
 | 1457 |  | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1458 | <p>Creation of <tt>Instruction</tt>s is straight-forward: simply call the | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1459 | constructor for the kind of instruction to instantiate and provide the necessary | 
 | 1460 | parameters. For example, an <tt>AllocaInst</tt> only <i>requires</i> a | 
 | 1461 | (const-ptr-to) <tt>Type</tt>. Thus:</p>  | 
 | 1462 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1463 | <div class="doc_code"> | 
 | 1464 | <pre> | 
 | 1465 | AllocaInst* ai = new AllocaInst(Type::IntTy); | 
 | 1466 | </pre> | 
 | 1467 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1468 |  | 
 | 1469 | <p>will create an <tt>AllocaInst</tt> instance that represents the allocation of | 
 | 1470 | one integer in the current stack frame, at runtime. Each <tt>Instruction</tt> | 
 | 1471 | subclass is likely to have varying default parameters which change the semantics | 
 | 1472 | of the instruction, so refer to the <a | 
| Misha Brukman | 31ca1de | 2004-06-03 23:35:54 +0000 | [diff] [blame] | 1473 | href="/doxygen/classllvm_1_1Instruction.html">doxygen documentation for the subclass of | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1474 | Instruction</a> that you're interested in instantiating.</p> | 
 | 1475 |  | 
 | 1476 | <p><i>Naming values</i></p> | 
 | 1477 |  | 
 | 1478 | <p>It is very useful to name the values of instructions when you're able to, as | 
 | 1479 | this facilitates the debugging of your transformations.  If you end up looking | 
 | 1480 | at generated LLVM machine code, you definitely want to have logical names | 
 | 1481 | associated with the results of instructions!  By supplying a value for the | 
 | 1482 | <tt>Name</tt> (default) parameter of the <tt>Instruction</tt> constructor, you | 
 | 1483 | associate a logical name with the result of the instruction's execution at | 
 | 1484 | runtime.  For example, say that I'm writing a transformation that dynamically | 
 | 1485 | allocates space for an integer on the stack, and that integer is going to be | 
 | 1486 | used as some kind of index by some other code.  To accomplish this, I place an | 
 | 1487 | <tt>AllocaInst</tt> at the first point in the first <tt>BasicBlock</tt> of some | 
 | 1488 | <tt>Function</tt>, and I'm intending to use it within the same | 
 | 1489 | <tt>Function</tt>. I might do:</p> | 
 | 1490 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1491 | <div class="doc_code"> | 
 | 1492 | <pre> | 
 | 1493 | AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc"); | 
 | 1494 | </pre> | 
 | 1495 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1496 |  | 
 | 1497 | <p>where <tt>indexLoc</tt> is now the logical name of the instruction's | 
 | 1498 | execution value, which is a pointer to an integer on the runtime stack.</p> | 
 | 1499 |  | 
 | 1500 | <p><i>Inserting instructions</i></p> | 
 | 1501 |  | 
 | 1502 | <p>There are essentially two ways to insert an <tt>Instruction</tt> | 
 | 1503 | into an existing sequence of instructions that form a <tt>BasicBlock</tt>:</p> | 
 | 1504 |  | 
| Joel Stanley | 9dd1ad6 | 2002-09-18 03:17:23 +0000 | [diff] [blame] | 1505 | <ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1506 |   <li>Insertion into an explicit instruction list | 
 | 1507 |  | 
 | 1508 |     <p>Given a <tt>BasicBlock* pb</tt>, an <tt>Instruction* pi</tt> within that | 
 | 1509 |     <tt>BasicBlock</tt>, and a newly-created instruction we wish to insert | 
 | 1510 |     before <tt>*pi</tt>, we do the following: </p> | 
 | 1511 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1512 | <div class="doc_code"> | 
 | 1513 | <pre> | 
 | 1514 | BasicBlock *pb = ...; | 
 | 1515 | Instruction *pi = ...; | 
 | 1516 | Instruction *newInst = new Instruction(...); | 
 | 1517 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1518 | pb->getInstList().insert(pi, newInst); // <i>Inserts newInst before pi in pb</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1519 | </pre> | 
 | 1520 | </div> | 
| Alkis Evlogimenos | 9a5dc4f | 2004-05-27 00:57:51 +0000 | [diff] [blame] | 1521 |  | 
 | 1522 |     <p>Appending to the end of a <tt>BasicBlock</tt> is so common that | 
 | 1523 |     the <tt>Instruction</tt> class and <tt>Instruction</tt>-derived | 
 | 1524 |     classes provide constructors which take a pointer to a | 
 | 1525 |     <tt>BasicBlock</tt> to be appended to. For example code that | 
 | 1526 |     looked like: </p> | 
 | 1527 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1528 | <div class="doc_code"> | 
 | 1529 | <pre> | 
 | 1530 | BasicBlock *pb = ...; | 
 | 1531 | Instruction *newInst = new Instruction(...); | 
 | 1532 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1533 | pb->getInstList().push_back(newInst); // <i>Appends newInst to pb</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1534 | </pre> | 
 | 1535 | </div> | 
| Alkis Evlogimenos | 9a5dc4f | 2004-05-27 00:57:51 +0000 | [diff] [blame] | 1536 |  | 
 | 1537 |     <p>becomes: </p> | 
 | 1538 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1539 | <div class="doc_code"> | 
 | 1540 | <pre> | 
 | 1541 | BasicBlock *pb = ...; | 
 | 1542 | Instruction *newInst = new Instruction(..., pb); | 
 | 1543 | </pre> | 
 | 1544 | </div> | 
| Alkis Evlogimenos | 9a5dc4f | 2004-05-27 00:57:51 +0000 | [diff] [blame] | 1545 |  | 
 | 1546 |     <p>which is much cleaner, especially if you are creating | 
 | 1547 |     long instruction streams.</p></li> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1548 |  | 
 | 1549 |   <li>Insertion into an implicit instruction list | 
 | 1550 |  | 
 | 1551 |     <p><tt>Instruction</tt> instances that are already in <tt>BasicBlock</tt>s | 
 | 1552 |     are implicitly associated with an existing instruction list: the instruction | 
 | 1553 |     list of the enclosing basic block. Thus, we could have accomplished the same | 
 | 1554 |     thing as the above code without being given a <tt>BasicBlock</tt> by doing: | 
 | 1555 |     </p> | 
 | 1556 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1557 | <div class="doc_code"> | 
 | 1558 | <pre> | 
 | 1559 | Instruction *pi = ...; | 
 | 1560 | Instruction *newInst = new Instruction(...); | 
 | 1561 |  | 
 | 1562 | pi->getParent()->getInstList().insert(pi, newInst); | 
 | 1563 | </pre> | 
 | 1564 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1565 |  | 
 | 1566 |     <p>In fact, this sequence of steps occurs so frequently that the | 
 | 1567 |     <tt>Instruction</tt> class and <tt>Instruction</tt>-derived classes provide | 
 | 1568 |     constructors which take (as a default parameter) a pointer to an | 
 | 1569 |     <tt>Instruction</tt> which the newly-created <tt>Instruction</tt> should | 
 | 1570 |     precede.  That is, <tt>Instruction</tt> constructors are capable of | 
 | 1571 |     inserting the newly-created instance into the <tt>BasicBlock</tt> of a | 
 | 1572 |     provided instruction, immediately before that instruction.  Using an | 
 | 1573 |     <tt>Instruction</tt> constructor with a <tt>insertBefore</tt> (default) | 
 | 1574 |     parameter, the above code becomes:</p> | 
 | 1575 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1576 | <div class="doc_code"> | 
 | 1577 | <pre> | 
 | 1578 | Instruction* pi = ...; | 
 | 1579 | Instruction* newInst = new Instruction(..., pi); | 
 | 1580 | </pre> | 
 | 1581 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1582 |  | 
 | 1583 |     <p>which is much cleaner, especially if you're creating a lot of | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1584 |     instructions and adding them to <tt>BasicBlock</tt>s.</p></li> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1585 | </ul> | 
 | 1586 |  | 
 | 1587 | </div> | 
 | 1588 |  | 
 | 1589 | <!--_______________________________________________________________________--> | 
 | 1590 | <div class="doc_subsubsection"> | 
 | 1591 |   <a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a> | 
 | 1592 | </div> | 
 | 1593 |  | 
 | 1594 | <div class="doc_text"> | 
 | 1595 |  | 
 | 1596 | <p>Deleting an instruction from an existing sequence of instructions that form a | 
| Chris Lattner | 69bf8a9 | 2004-05-23 21:06:58 +0000 | [diff] [blame] | 1597 | <a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward. First, | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1598 | you must have a pointer to the instruction that you wish to delete.  Second, you | 
 | 1599 | need to obtain the pointer to that instruction's basic block. You use the | 
 | 1600 | pointer to the basic block to get its list of instructions and then use the | 
 | 1601 | erase function to remove your instruction. For example:</p> | 
 | 1602 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1603 | <div class="doc_code"> | 
 | 1604 | <pre> | 
 | 1605 | <a href="#Instruction">Instruction</a> *I = .. ; | 
 | 1606 | <a href="#BasicBlock">BasicBlock</a> *BB = I->getParent(); | 
 | 1607 |  | 
 | 1608 | BB->getInstList().erase(I); | 
 | 1609 | </pre> | 
 | 1610 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1611 |  | 
 | 1612 | </div> | 
 | 1613 |  | 
 | 1614 | <!--_______________________________________________________________________--> | 
 | 1615 | <div class="doc_subsubsection"> | 
 | 1616 |   <a name="schanges_replacing">Replacing an <tt>Instruction</tt> with another | 
 | 1617 |   <tt>Value</tt></a> | 
 | 1618 | </div> | 
 | 1619 |  | 
 | 1620 | <div class="doc_text"> | 
 | 1621 |  | 
 | 1622 | <p><i>Replacing individual instructions</i></p> | 
 | 1623 |  | 
 | 1624 | <p>Including "<a href="/doxygen/BasicBlockUtils_8h-source.html">llvm/Transforms/Utils/BasicBlockUtils.h</a>" | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1625 | permits use of two very useful replace functions: <tt>ReplaceInstWithValue</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1626 | and <tt>ReplaceInstWithInst</tt>.</p> | 
 | 1627 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1628 | <h4><a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a></h4> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1629 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1630 | <ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1631 |   <li><tt>ReplaceInstWithValue</tt> | 
 | 1632 |  | 
 | 1633 |     <p>This function replaces all uses (within a basic block) of a given | 
 | 1634 |     instruction with a value, and then removes the original instruction. The | 
 | 1635 |     following example illustrates the replacement of the result of a particular | 
| Chris Lattner | 5836082 | 2005-01-17 00:12:04 +0000 | [diff] [blame] | 1636 |     <tt>AllocaInst</tt> that allocates memory for a single integer with a null | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1637 |     pointer to an integer.</p> | 
 | 1638 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1639 | <div class="doc_code"> | 
 | 1640 | <pre> | 
 | 1641 | AllocaInst* instToReplace = ...; | 
 | 1642 | BasicBlock::iterator ii(instToReplace); | 
 | 1643 |  | 
 | 1644 | ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii, | 
 | 1645 |                      Constant::getNullValue(PointerType::get(Type::IntTy))); | 
 | 1646 | </pre></div></li> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1647 |  | 
 | 1648 |   <li><tt>ReplaceInstWithInst</tt>  | 
 | 1649 |  | 
 | 1650 |     <p>This function replaces a particular instruction with another | 
 | 1651 |     instruction. The following example illustrates the replacement of one | 
 | 1652 |     <tt>AllocaInst</tt> with another.</p> | 
 | 1653 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1654 | <div class="doc_code"> | 
 | 1655 | <pre> | 
 | 1656 | AllocaInst* instToReplace = ...; | 
 | 1657 | BasicBlock::iterator ii(instToReplace); | 
 | 1658 |  | 
 | 1659 | ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii, | 
 | 1660 |                     new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt")); | 
 | 1661 | </pre></div></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 1662 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1663 |  | 
 | 1664 | <p><i>Replacing multiple uses of <tt>User</tt>s and <tt>Value</tt>s</i></p> | 
 | 1665 |  | 
 | 1666 | <p>You can use <tt>Value::replaceAllUsesWith</tt> and | 
 | 1667 | <tt>User::replaceUsesOfWith</tt> to change more than one use at a time.  See the | 
| Chris Lattner | 0081517 | 2007-01-04 22:01:45 +0000 | [diff] [blame] | 1668 | doxygen documentation for the <a href="/doxygen/classllvm_1_1Value.html">Value Class</a> | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 1669 | and <a href="/doxygen/classllvm_1_1User.html">User Class</a>, respectively, for more | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1670 | information.</p> | 
 | 1671 |  | 
 | 1672 | <!-- Value::replaceAllUsesWith User::replaceUsesOfWith Point out: | 
 | 1673 | include/llvm/Transforms/Utils/ especially BasicBlockUtils.h with: | 
 | 1674 | ReplaceInstWithValue, ReplaceInstWithInst --> | 
 | 1675 |  | 
 | 1676 | </div> | 
 | 1677 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 1678 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 1679 | <div class="doc_section"> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1680 |   <a name="advanced">Advanced Topics</a> | 
 | 1681 | </div> | 
 | 1682 | <!-- *********************************************************************** --> | 
 | 1683 |  | 
 | 1684 | <div class="doc_text"> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1685 | <p> | 
 | 1686 | This section describes some of the advanced or obscure API's that most clients | 
 | 1687 | do not need to be aware of.  These API's tend manage the inner workings of the | 
 | 1688 | LLVM system, and only need to be accessed in unusual circumstances. | 
 | 1689 | </p> | 
 | 1690 | </div> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1691 |  | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1692 | <!-- ======================================================================= --> | 
 | 1693 | <div class="doc_subsection"> | 
 | 1694 |   <a name="TypeResolve">LLVM Type Resolution</a> | 
 | 1695 | </div> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1696 |  | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1697 | <div class="doc_text"> | 
 | 1698 |  | 
 | 1699 | <p> | 
 | 1700 | The LLVM type system has a very simple goal: allow clients to compare types for | 
 | 1701 | structural equality with a simple pointer comparison (aka a shallow compare). | 
 | 1702 | This goal makes clients much simpler and faster, and is used throughout the LLVM | 
 | 1703 | system. | 
 | 1704 | </p> | 
 | 1705 |  | 
 | 1706 | <p> | 
 | 1707 | Unfortunately achieving this goal is not a simple matter.  In particular, | 
 | 1708 | recursive types and late resolution of opaque types makes the situation very | 
 | 1709 | difficult to handle.  Fortunately, for the most part, our implementation makes | 
 | 1710 | most clients able to be completely unaware of the nasty internal details.  The | 
 | 1711 | primary case where clients are exposed to the inner workings of it are when | 
 | 1712 | building a recursive type.  In addition to this case, the LLVM bytecode reader, | 
 | 1713 | assembly parser, and linker also have to be aware of the inner workings of this | 
 | 1714 | system. | 
 | 1715 | </p> | 
 | 1716 |  | 
| Chris Lattner | 0f876db | 2005-04-25 15:47:57 +0000 | [diff] [blame] | 1717 | <p> | 
 | 1718 | For our purposes below, we need three concepts.  First, an "Opaque Type" is  | 
 | 1719 | exactly as defined in the <a href="LangRef.html#t_opaque">language  | 
 | 1720 | reference</a>.  Second an "Abstract Type" is any type which includes an  | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 1721 | opaque type as part of its type graph (for example "<tt>{ opaque, i32 }</tt>"). | 
 | 1722 | Third, a concrete type is a type that is not an abstract type (e.g. "<tt>{ i32,  | 
| Chris Lattner | 0f876db | 2005-04-25 15:47:57 +0000 | [diff] [blame] | 1723 | float }</tt>"). | 
 | 1724 | </p> | 
 | 1725 |  | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1726 | </div> | 
 | 1727 |  | 
 | 1728 | <!-- ______________________________________________________________________ --> | 
 | 1729 | <div class="doc_subsubsection"> | 
 | 1730 |   <a name="BuildRecType">Basic Recursive Type Construction</a> | 
 | 1731 | </div> | 
 | 1732 |  | 
 | 1733 | <div class="doc_text"> | 
 | 1734 |  | 
 | 1735 | <p> | 
 | 1736 | Because the most common question is "how do I build a recursive type with LLVM", | 
 | 1737 | we answer it now and explain it as we go.  Here we include enough to cause this | 
 | 1738 | to be emitted to an output .ll file: | 
 | 1739 | </p> | 
 | 1740 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1741 | <div class="doc_code"> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1742 | <pre> | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 1743 | %mylist = type { %mylist*, i32 } | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1744 | </pre> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1745 | </div> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1746 |  | 
 | 1747 | <p> | 
 | 1748 | To build this, use the following LLVM APIs: | 
 | 1749 | </p> | 
 | 1750 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1751 | <div class="doc_code"> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1752 | <pre> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1753 | // <i>Create the initial outer struct</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1754 | <a href="#PATypeHolder">PATypeHolder</a> StructTy = OpaqueType::get(); | 
 | 1755 | std::vector<const Type*> Elts; | 
 | 1756 | Elts.push_back(PointerType::get(StructTy)); | 
 | 1757 | Elts.push_back(Type::IntTy); | 
 | 1758 | StructType *NewSTy = StructType::get(Elts); | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1759 |  | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 1760 | // <i>At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that</i> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1761 | // <i>the struct and the opaque type are actually the same.</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1762 | cast<OpaqueType>(StructTy.get())-><a href="#refineAbstractTypeTo">refineAbstractTypeTo</a>(NewSTy); | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1763 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1764 | // <i>NewSTy is potentially invalidated, but StructTy (a <a href="#PATypeHolder">PATypeHolder</a>) is</i> | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1765 | // <i>kept up-to-date</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1766 | NewSTy = cast<StructType>(StructTy.get()); | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1767 |  | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1768 | // <i>Add a name for the type to the module symbol table (optional)</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1769 | MyModule->addTypeName("mylist", NewSTy); | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1770 | </pre> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1771 | </div> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1772 |  | 
 | 1773 | <p> | 
 | 1774 | This code shows the basic approach used to build recursive types: build a | 
 | 1775 | non-recursive type using 'opaque', then use type unification to close the cycle. | 
 | 1776 | The type unification step is performed by the <tt><a | 
| Chris Lattner | aff26d1 | 2007-02-03 03:06:52 +0000 | [diff] [blame] | 1777 | href="#refineAbstractTypeTo">refineAbstractTypeTo</a></tt> method, which is | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1778 | described next.  After that, we describe the <a | 
 | 1779 | href="#PATypeHolder">PATypeHolder class</a>. | 
 | 1780 | </p> | 
 | 1781 |  | 
 | 1782 | </div> | 
 | 1783 |  | 
 | 1784 | <!-- ______________________________________________________________________ --> | 
 | 1785 | <div class="doc_subsubsection"> | 
 | 1786 |   <a name="refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a> | 
 | 1787 | </div> | 
 | 1788 |  | 
 | 1789 | <div class="doc_text"> | 
 | 1790 | <p> | 
 | 1791 | The <tt>refineAbstractTypeTo</tt> method starts the type unification process. | 
 | 1792 | While this method is actually a member of the DerivedType class, it is most | 
 | 1793 | often used on OpaqueType instances.  Type unification is actually a recursive | 
 | 1794 | process.  After unification, types can become structurally isomorphic to | 
 | 1795 | existing types, and all duplicates are deleted (to preserve pointer equality). | 
 | 1796 | </p> | 
 | 1797 |  | 
 | 1798 | <p> | 
 | 1799 | In the example above, the OpaqueType object is definitely deleted. | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 1800 | Additionally, if there is an "{ \2*, i32}" type already created in the system, | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1801 | the pointer and struct type created are <b>also</b> deleted.  Obviously whenever | 
 | 1802 | a type is deleted, any "Type*" pointers in the program are invalidated.  As | 
 | 1803 | such, it is safest to avoid having <i>any</i> "Type*" pointers to abstract types | 
 | 1804 | live across a call to <tt>refineAbstractTypeTo</tt> (note that non-abstract | 
 | 1805 | types can never move or be deleted).  To deal with this, the <a | 
 | 1806 | href="#PATypeHolder">PATypeHolder</a> class is used to maintain a stable | 
 | 1807 | reference to a possibly refined type, and the <a | 
 | 1808 | href="#AbstractTypeUser">AbstractTypeUser</a> class is used to update more | 
 | 1809 | complex datastructures. | 
 | 1810 | </p> | 
 | 1811 |  | 
 | 1812 | </div> | 
 | 1813 |  | 
 | 1814 | <!-- ______________________________________________________________________ --> | 
 | 1815 | <div class="doc_subsubsection"> | 
 | 1816 |   <a name="PATypeHolder">The PATypeHolder Class</a> | 
 | 1817 | </div> | 
 | 1818 |  | 
 | 1819 | <div class="doc_text"> | 
 | 1820 | <p> | 
 | 1821 | PATypeHolder is a form of a "smart pointer" for Type objects.  When VMCore | 
 | 1822 | happily goes about nuking types that become isomorphic to existing types, it | 
 | 1823 | automatically updates all PATypeHolder objects to point to the new type.  In the | 
 | 1824 | example above, this allows the code to maintain a pointer to the resultant | 
 | 1825 | resolved recursive type, even though the Type*'s are potentially invalidated. | 
 | 1826 | </p> | 
 | 1827 |  | 
 | 1828 | <p> | 
 | 1829 | PATypeHolder is an extremely light-weight object that uses a lazy union-find | 
 | 1830 | implementation to update pointers.  For example the pointer from a Value to its | 
 | 1831 | Type is maintained by PATypeHolder objects. | 
 | 1832 | </p> | 
 | 1833 |  | 
 | 1834 | </div> | 
 | 1835 |  | 
 | 1836 | <!-- ______________________________________________________________________ --> | 
 | 1837 | <div class="doc_subsubsection"> | 
 | 1838 |   <a name="AbstractTypeUser">The AbstractTypeUser Class</a> | 
 | 1839 | </div> | 
 | 1840 |  | 
 | 1841 | <div class="doc_text"> | 
 | 1842 |  | 
 | 1843 | <p> | 
 | 1844 | Some data structures need more to perform more complex updates when types get | 
 | 1845 | resolved.  The <a href="#SymbolTable">SymbolTable</a> class, for example, needs | 
 | 1846 | move and potentially merge type planes in its representation when a pointer | 
 | 1847 | changes.</p> | 
 | 1848 |  | 
 | 1849 | <p> | 
 | 1850 | To support this, a class can derive from the AbstractTypeUser class.  This class | 
 | 1851 | allows it to get callbacks when certain types are resolved.  To register to get | 
 | 1852 | callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser | 
| Chris Lattner | 0f876db | 2005-04-25 15:47:57 +0000 | [diff] [blame] | 1853 | methods can be called on a type.  Note that these methods only work for <i> | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 1854 |   abstract</i> types.  Concrete types (those that do not include any opaque  | 
 | 1855 | objects) can never be refined. | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1856 | </p> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1857 | </div> | 
 | 1858 |  | 
 | 1859 |  | 
 | 1860 | <!-- ======================================================================= --> | 
 | 1861 | <div class="doc_subsection"> | 
 | 1862 |   <a name="SymbolTable">The <tt>SymbolTable</tt> class</a> | 
 | 1863 | </div> | 
| Chris Lattner | f1b200b | 2005-04-23 17:27:36 +0000 | [diff] [blame] | 1864 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1865 | <div class="doc_text"> | 
 | 1866 | <p>This class provides a symbol table that the <a | 
 | 1867 | href="#Function"><tt>Function</tt></a> and <a href="#Module"> | 
 | 1868 | <tt>Module</tt></a> classes use for naming definitions. The symbol table can | 
| Reid Spencer | a636224 | 2007-01-07 00:41:39 +0000 | [diff] [blame] | 1869 | provide a name for any <a href="#Value"><tt>Value</tt></a>.  | 
 | 1870 | <tt>SymbolTable</tt> is an abstract data type. It hides the data it contains  | 
 | 1871 | and provides access to it through a controlled interface.</p> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1872 |  | 
| Reid Spencer | a636224 | 2007-01-07 00:41:39 +0000 | [diff] [blame] | 1873 | <p>Note that the <tt>SymbolTable</tt> class should not be directly accessed  | 
 | 1874 | by most clients.  It should only be used when iteration over the symbol table  | 
 | 1875 | names themselves are required, which is very special purpose.  Note that not  | 
 | 1876 | all LLVM | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1877 | <a href="#Value">Value</a>s have names, and those without names (i.e. they have | 
 | 1878 | an empty name) do not exist in the symbol table. | 
 | 1879 | </p> | 
 | 1880 |  | 
 | 1881 | <p>To use the <tt>SymbolTable</tt> well, you need to understand the  | 
 | 1882 | structure of the information it holds. The class contains two  | 
 | 1883 | <tt>std::map</tt> objects. The first, <tt>pmap</tt>, is a map of  | 
 | 1884 | <tt>Type*</tt> to maps of name (<tt>std::string</tt>) to <tt>Value*</tt>.  | 
| Reid Spencer | a636224 | 2007-01-07 00:41:39 +0000 | [diff] [blame] | 1885 | Thus, Values are stored in two-dimensions and accessed by <tt>Type</tt> and  | 
 | 1886 | name.</p>  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1887 |  | 
 | 1888 | <p>The interface of this class provides three basic types of operations: | 
 | 1889 | <ol> | 
 | 1890 |   <li><em>Accessors</em>. Accessors provide read-only access to information | 
 | 1891 |   such as finding a value for a name with the  | 
 | 1892 |   <a href="#SymbolTable_lookup">lookup</a> method.</li>  | 
 | 1893 |   <li><em>Mutators</em>. Mutators allow the user to add information to the | 
 | 1894 |   <tt>SymbolTable</tt> with methods like  | 
 | 1895 |   <a href="#SymbolTable_insert"><tt>insert</tt></a>.</li> | 
 | 1896 |   <li><em>Iterators</em>. Iterators allow the user to traverse the content | 
 | 1897 |   of the symbol table in well defined ways, such as the method | 
| Reid Spencer | a636224 | 2007-01-07 00:41:39 +0000 | [diff] [blame] | 1898 |   <a href="#SymbolTable_plane_begin"><tt>plane_begin</tt></a>.</li> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1899 | </ol> | 
 | 1900 |  | 
 | 1901 | <h3>Accessors</h3> | 
 | 1902 | <dl> | 
 | 1903 |   <dt><tt>Value* lookup(const Type* Ty, const std::string& name) const</tt>: | 
 | 1904 |   </dt> | 
 | 1905 |   <dd>The <tt>lookup</tt> method searches the type plane given by the | 
 | 1906 |   <tt>Ty</tt> parameter for a <tt>Value</tt> with the provided <tt>name</tt>. | 
 | 1907 |   If a suitable <tt>Value</tt> is not found, null is returned.</dd> | 
 | 1908 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1909 |   <dt><tt>bool isEmpty() const</tt>:</dt> | 
 | 1910 |   <dd>This function returns true if both the value and types maps are | 
 | 1911 |   empty</dd> | 
 | 1912 | </dl> | 
 | 1913 |  | 
 | 1914 | <h3>Mutators</h3> | 
 | 1915 | <dl> | 
 | 1916 |   <dt><tt>void insert(Value *Val)</tt>:</dt> | 
 | 1917 |   <dd>This method adds the provided value to the symbol table.  The Value must | 
 | 1918 |   have both a name and a type which are extracted and used to place the value | 
 | 1919 |   in the correct type plane under the value's name.</dd> | 
 | 1920 |  | 
 | 1921 |   <dt><tt>void insert(const std::string& Name, Value *Val)</tt>:</dt> | 
 | 1922 |   <dd> Inserts a constant or type into the symbol table with the specified | 
 | 1923 |   name. There can be a many to one mapping between names and constants | 
 | 1924 |   or types.</dd> | 
 | 1925 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1926 |   <dt><tt>void remove(Value* Val)</tt>:</dt> | 
 | 1927 |  <dd> This method removes a named value from the symbol table. The | 
 | 1928 |   type and name of the Value are extracted from \p N and used to | 
 | 1929 |   lookup the Value in the correct type plane. If the Value is | 
 | 1930 |   not in the symbol table, this method silently ignores the | 
 | 1931 |   request.</dd> | 
 | 1932 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1933 |   <dt><tt>Value* remove(const std::string& Name, Value *Val)</tt>:</dt> | 
 | 1934 |   <dd> Remove a constant or type with the specified name from the  | 
 | 1935 |   symbol table.</dd> | 
 | 1936 |  | 
| Reid Spencer | a636224 | 2007-01-07 00:41:39 +0000 | [diff] [blame] | 1937 |   <dt><tt>Value *remove(const value_iterator& It)</tt>:</dt> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1938 |   <dd> Removes a specific value from the symbol table.  | 
 | 1939 |   Returns the removed value.</dd> | 
 | 1940 |  | 
 | 1941 |   <dt><tt>bool strip()</tt>:</dt> | 
 | 1942 |   <dd> This method will strip the symbol table of its names leaving | 
 | 1943 |   the type and values. </dd> | 
 | 1944 |  | 
 | 1945 |   <dt><tt>void clear()</tt>:</dt> | 
 | 1946 |   <dd>Empty the symbol table completely.</dd> | 
 | 1947 | </dl> | 
 | 1948 |  | 
 | 1949 | <h3>Iteration</h3> | 
 | 1950 | <p>The following functions describe three types of iterators you can obtain | 
 | 1951 | the beginning or end of the sequence for both const and non-const. It is | 
 | 1952 | important to keep track of the different kinds of iterators. There are | 
 | 1953 | three idioms worth pointing out:</p> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1954 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1955 | <table> | 
 | 1956 |   <tr><th>Units</th><th>Iterator</th><th>Idiom</th></tr> | 
 | 1957 |   <tr> | 
 | 1958 |     <td align="left">Planes Of name/Value maps</td><td>PI</td> | 
 | 1959 |     <td align="left"><pre><tt> | 
 | 1960 | for (SymbolTable::plane_const_iterator PI = ST.plane_begin(), | 
 | 1961 |      PE = ST.plane_end(); PI != PE; ++PI ) { | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1962 |   PI->first  // <i>This is the Type* of the plane</i> | 
 | 1963 |   PI->second // <i>This is the SymbolTable::ValueMap of name/Value pairs</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1964 | } | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1965 |     </tt></pre></td> | 
 | 1966 |   </tr> | 
 | 1967 |   <tr> | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1968 |     <td align="left">name/Value pairs in a plane</td><td>VI</td> | 
 | 1969 |     <td align="left"><pre><tt> | 
 | 1970 | for (SymbolTable::value_const_iterator VI = ST.value_begin(SomeType), | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1971 |      VE = ST.value_end(SomeType); VI != VE; ++VI ) { | 
| Bill Wendling | 82e2eea | 2006-10-11 18:00:22 +0000 | [diff] [blame] | 1972 |   VI->first  // <i>This is the name of the Value</i> | 
 | 1973 |   VI->second // <i>This is the Value* value associated with the name</i> | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 1974 | } | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 1975 |     </tt></pre></td> | 
 | 1976 |   </tr> | 
 | 1977 | </table> | 
 | 1978 |  | 
 | 1979 | <p>Using the recommended iterator names and idioms will help you avoid | 
 | 1980 | making mistakes. Of particular note, make sure that whenever you use | 
 | 1981 | value_begin(SomeType) that you always compare the resulting iterator | 
 | 1982 | with value_end(SomeType) not value_end(SomeOtherType) or else you  | 
 | 1983 | will loop infinitely.</p> | 
 | 1984 |  | 
 | 1985 | <dl> | 
 | 1986 |  | 
 | 1987 |   <dt><tt>plane_iterator plane_begin()</tt>:</dt> | 
 | 1988 |   <dd>Get an iterator that starts at the beginning of the type planes. | 
 | 1989 |   The iterator will iterate over the Type/ValueMap pairs in the | 
 | 1990 |   type planes. </dd> | 
 | 1991 |  | 
 | 1992 |   <dt><tt>plane_const_iterator plane_begin() const</tt>:</dt> | 
 | 1993 |   <dd>Get a const_iterator that starts at the beginning of the type  | 
 | 1994 |   planes.  The iterator will iterate over the Type/ValueMap pairs  | 
 | 1995 |   in the type planes. </dd> | 
 | 1996 |  | 
 | 1997 |   <dt><tt>plane_iterator plane_end()</tt>:</dt> | 
 | 1998 |   <dd>Get an iterator at the end of the type planes. This serves as | 
 | 1999 |   the marker for end of iteration over the type planes.</dd> | 
 | 2000 |  | 
 | 2001 |   <dt><tt>plane_const_iterator plane_end() const</tt>:</dt> | 
 | 2002 |   <dd>Get a const_iterator at the end of the type planes. This serves as | 
 | 2003 |   the marker for end of iteration over the type planes.</dd> | 
 | 2004 |  | 
 | 2005 |   <dt><tt>value_iterator value_begin(const Type *Typ)</tt>:</dt> | 
 | 2006 |   <dd>Get an iterator that starts at the beginning of a type plane. | 
 | 2007 |   The iterator will iterate over the name/value pairs in the type plane. | 
 | 2008 |   Note: The type plane must already exist before using this.</dd> | 
 | 2009 |  | 
 | 2010 |   <dt><tt>value_const_iterator value_begin(const Type *Typ) const</tt>:</dt> | 
 | 2011 |   <dd>Get a const_iterator that starts at the beginning of a type plane. | 
 | 2012 |   The iterator will iterate over the name/value pairs in the type plane. | 
 | 2013 |   Note: The type plane must already exist before using this.</dd> | 
 | 2014 |  | 
 | 2015 |   <dt><tt>value_iterator value_end(const Type *Typ)</tt>:</dt> | 
 | 2016 |   <dd>Get an iterator to the end of a type plane. This serves as the marker | 
 | 2017 |   for end of iteration of the type plane. | 
 | 2018 |   Note: The type plane must already exist before using this.</dd> | 
 | 2019 |  | 
 | 2020 |   <dt><tt>value_const_iterator value_end(const Type *Typ) const</tt>:</dt> | 
 | 2021 |   <dd>Get a const_iterator to the end of a type plane. This serves as the | 
 | 2022 |   marker for end of iteration of the type plane. | 
 | 2023 |   Note: the type plane must already exist before using this.</dd> | 
 | 2024 |  | 
| Chris Lattner | d9d6e10 | 2005-04-23 16:10:52 +0000 | [diff] [blame] | 2025 |   <dt><tt>plane_const_iterator find(const Type* Typ ) const</tt>:</dt> | 
 | 2026 |   <dd>This method returns a plane_const_iterator for iteration over | 
 | 2027 |   the type planes starting at a specific plane, given by \p Ty.</dd> | 
 | 2028 |  | 
 | 2029 |   <dt><tt>plane_iterator find( const Type* Typ </tt>:</dt> | 
 | 2030 |   <dd>This method returns a plane_iterator for iteration over the | 
 | 2031 |   type planes starting at a specific plane, given by \p Ty.</dd> | 
 | 2032 |  | 
 | 2033 | </dl> | 
 | 2034 | </div> | 
 | 2035 |  | 
 | 2036 |  | 
 | 2037 |  | 
 | 2038 | <!-- *********************************************************************** --> | 
 | 2039 | <div class="doc_section"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2040 |   <a name="coreclasses">The Core LLVM Class Hierarchy Reference </a> | 
 | 2041 | </div> | 
 | 2042 | <!-- *********************************************************************** --> | 
 | 2043 |  | 
 | 2044 | <div class="doc_text"> | 
| Reid Spencer | 303c4b4 | 2007-01-12 17:26:25 +0000 | [diff] [blame] | 2045 | <p><tt>#include "<a href="/doxygen/Type_8h-source.html">llvm/Type.h</a>"</tt> | 
 | 2046 | <br>doxygen info: <a href="/doxygen/classllvm_1_1Type.html">Type Class</a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2047 |  | 
 | 2048 | <p>The Core LLVM classes are the primary means of representing the program | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2049 | being inspected or transformed.  The core LLVM classes are defined in | 
 | 2050 | header files in the <tt>include/llvm/</tt> directory, and implemented in | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2051 | the <tt>lib/VMCore</tt> directory.</p> | 
 | 2052 |  | 
 | 2053 | </div> | 
 | 2054 |  | 
 | 2055 | <!-- ======================================================================= --> | 
 | 2056 | <div class="doc_subsection"> | 
| Reid Spencer | 303c4b4 | 2007-01-12 17:26:25 +0000 | [diff] [blame] | 2057 |   <a name="Type">The <tt>Type</tt> class and Derived Types</a> | 
 | 2058 | </div> | 
 | 2059 |  | 
 | 2060 | <div class="doc_text"> | 
 | 2061 |  | 
 | 2062 |   <p><tt>Type</tt> is a superclass of all type classes. Every <tt>Value</tt> has | 
 | 2063 |   a <tt>Type</tt>. <tt>Type</tt> cannot be instantiated directly but only | 
 | 2064 |   through its subclasses. Certain primitive types (<tt>VoidType</tt>, | 
 | 2065 |   <tt>LabelType</tt>, <tt>FloatType</tt> and <tt>DoubleType</tt>) have hidden  | 
 | 2066 |   subclasses. They are hidden because they offer no useful functionality beyond | 
 | 2067 |   what the <tt>Type</tt> class offers except to distinguish themselves from  | 
 | 2068 |   other subclasses of <tt>Type</tt>.</p> | 
 | 2069 |   <p>All other types are subclasses of <tt>DerivedType</tt>.  Types can be  | 
 | 2070 |   named, but this is not a requirement. There exists exactly  | 
 | 2071 |   one instance of a given shape at any one time.  This allows type equality to | 
 | 2072 |   be performed with address equality of the Type Instance. That is, given two  | 
 | 2073 |   <tt>Type*</tt> values, the types are identical if the pointers are identical. | 
 | 2074 |   </p> | 
 | 2075 | </div> | 
 | 2076 |  | 
 | 2077 | <!-- _______________________________________________________________________ --> | 
 | 2078 | <div class="doc_subsubsection"> | 
 | 2079 |   <a name="m_Value">Important Public Methods</a> | 
 | 2080 | </div> | 
 | 2081 |  | 
 | 2082 | <div class="doc_text"> | 
 | 2083 |  | 
 | 2084 | <ul> | 
| Chris Lattner | 8f79df3 | 2007-01-15 01:55:32 +0000 | [diff] [blame] | 2085 |   <li><tt>bool isInteger() const</tt>: Returns true for any integer type.</li> | 
| Reid Spencer | 303c4b4 | 2007-01-12 17:26:25 +0000 | [diff] [blame] | 2086 |  | 
 | 2087 |   <li><tt>bool isFloatingPoint()</tt>: Return true if this is one of the two | 
 | 2088 |   floating point types.</li> | 
 | 2089 |  | 
 | 2090 |   <li><tt>bool isAbstract()</tt>: Return true if the type is abstract (contains | 
 | 2091 |   an OpaqueType anywhere in its definition).</li> | 
 | 2092 |  | 
 | 2093 |   <li><tt>bool isSized()</tt>: Return true if the type has known size. Things | 
 | 2094 |   that don't have a size are abstract types, labels and void.</li> | 
 | 2095 |  | 
 | 2096 | </ul> | 
 | 2097 | </div> | 
 | 2098 |  | 
 | 2099 | <!-- _______________________________________________________________________ --> | 
 | 2100 | <div class="doc_subsubsection"> | 
 | 2101 |   <a name="m_Value">Important Derived Types</a> | 
 | 2102 | </div> | 
 | 2103 | <div class="doc_text"> | 
 | 2104 | <dl> | 
 | 2105 |   <dt><tt>IntegerType</tt></dt> | 
 | 2106 |   <dd>Subclass of DerivedType that represents integer types of any bit width.  | 
 | 2107 |   Any bit width between <tt>IntegerType::MIN_INT_BITS</tt> (1) and  | 
 | 2108 |   <tt>IntegerType::MAX_INT_BITS</tt> (~8 million) can be represented. | 
 | 2109 |   <ul> | 
 | 2110 |     <li><tt>static const IntegerType* get(unsigned NumBits)</tt>: get an integer | 
 | 2111 |     type of a specific bit width.</li> | 
 | 2112 |     <li><tt>unsigned getBitWidth() const</tt>: Get the bit width of an integer | 
 | 2113 |     type.</li> | 
 | 2114 |   </ul> | 
 | 2115 |   </dd> | 
 | 2116 |   <dt><tt>SequentialType</tt></dt> | 
 | 2117 |   <dd>This is subclassed by ArrayType and PointerType | 
 | 2118 |     <ul> | 
 | 2119 |       <li><tt>const Type * getElementType() const</tt>: Returns the type of each | 
 | 2120 |       of the elements in the sequential type. </li> | 
 | 2121 |     </ul> | 
 | 2122 |   </dd> | 
 | 2123 |   <dt><tt>ArrayType</tt></dt> | 
 | 2124 |   <dd>This is a subclass of SequentialType and defines the interface for array  | 
 | 2125 |   types. | 
 | 2126 |     <ul> | 
 | 2127 |       <li><tt>unsigned getNumElements() const</tt>: Returns the number of  | 
 | 2128 |       elements in the array. </li> | 
 | 2129 |     </ul> | 
 | 2130 |   </dd> | 
 | 2131 |   <dt><tt>PointerType</tt></dt> | 
| Chris Lattner | 302da1e | 2007-02-03 03:05:57 +0000 | [diff] [blame] | 2132 |   <dd>Subclass of SequentialType for pointer types.</dd> | 
| Reid Spencer | 303c4b4 | 2007-01-12 17:26:25 +0000 | [diff] [blame] | 2133 |   <dt><tt>PackedType</tt></dt> | 
 | 2134 |   <dd>Subclass of SequentialType for packed (vector) types. A  | 
 | 2135 |   packed type is similar to an ArrayType but is distinguished because it is  | 
 | 2136 |   a first class type wherease ArrayType is not. Packed types are used for  | 
 | 2137 |   vector operations and are usually small vectors of of an integer or floating  | 
 | 2138 |   point type.</dd> | 
 | 2139 |   <dt><tt>StructType</tt></dt> | 
 | 2140 |   <dd>Subclass of DerivedTypes for struct types.</dd> | 
 | 2141 |   <dt><tt>FunctionType</tt></dt> | 
 | 2142 |   <dd>Subclass of DerivedTypes for function types. | 
 | 2143 |     <ul> | 
 | 2144 |       <li><tt>bool isVarArg() const</tt>: Returns true if its a vararg | 
 | 2145 |       function</li> | 
 | 2146 |       <li><tt> const Type * getReturnType() const</tt>: Returns the | 
 | 2147 |       return type of the function.</li> | 
 | 2148 |       <li><tt>const Type * getParamType (unsigned i)</tt>: Returns | 
 | 2149 |       the type of the ith parameter.</li> | 
 | 2150 |       <li><tt> const unsigned getNumParams() const</tt>: Returns the | 
 | 2151 |       number of formal parameters.</li> | 
 | 2152 |     </ul> | 
 | 2153 |   </dd> | 
 | 2154 |   <dt><tt>OpaqueType</tt></dt> | 
 | 2155 |   <dd>Sublcass of DerivedType for abstract types. This class  | 
 | 2156 |   defines no content and is used as a placeholder for some other type. Note  | 
 | 2157 |   that OpaqueType is used (temporarily) during type resolution for forward  | 
 | 2158 |   references of types. Once the referenced type is resolved, the OpaqueType  | 
 | 2159 |   is replaced with the actual type. OpaqueType can also be used for data  | 
 | 2160 |   abstraction. At link time opaque types can be resolved to actual types  | 
 | 2161 |   of the same name.</dd> | 
 | 2162 | </dl> | 
 | 2163 | </div> | 
 | 2164 |  | 
 | 2165 | <!-- ======================================================================= --> | 
 | 2166 | <div class="doc_subsection"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2167 |   <a name="Value">The <tt>Value</tt> class</a> | 
 | 2168 | </div> | 
 | 2169 |  | 
 | 2170 | <div> | 
 | 2171 |  | 
 | 2172 | <p><tt>#include "<a href="/doxygen/Value_8h-source.html">llvm/Value.h</a>"</tt> | 
 | 2173 | <br>  | 
| Chris Lattner | 0081517 | 2007-01-04 22:01:45 +0000 | [diff] [blame] | 2174 | doxygen info: <a href="/doxygen/classllvm_1_1Value.html">Value Class</a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2175 |  | 
 | 2176 | <p>The <tt>Value</tt> class is the most important class in the LLVM Source | 
 | 2177 | base.  It represents a typed value that may be used (among other things) as an | 
 | 2178 | operand to an instruction.  There are many different types of <tt>Value</tt>s, | 
 | 2179 | such as <a href="#Constant"><tt>Constant</tt></a>s,<a | 
 | 2180 | href="#Argument"><tt>Argument</tt></a>s. Even <a | 
 | 2181 | href="#Instruction"><tt>Instruction</tt></a>s and <a | 
 | 2182 | href="#Function"><tt>Function</tt></a>s are <tt>Value</tt>s.</p> | 
 | 2183 |  | 
 | 2184 | <p>A particular <tt>Value</tt> may be used many times in the LLVM representation | 
 | 2185 | for a program.  For example, an incoming argument to a function (represented | 
 | 2186 | with an instance of the <a href="#Argument">Argument</a> class) is "used" by | 
 | 2187 | every instruction in the function that references the argument.  To keep track | 
 | 2188 | of this relationship, the <tt>Value</tt> class keeps a list of all of the <a | 
 | 2189 | href="#User"><tt>User</tt></a>s that is using it (the <a | 
 | 2190 | href="#User"><tt>User</tt></a> class is a base class for all nodes in the LLVM | 
 | 2191 | graph that can refer to <tt>Value</tt>s).  This use list is how LLVM represents | 
 | 2192 | def-use information in the program, and is accessible through the <tt>use_</tt>* | 
 | 2193 | methods, shown below.</p> | 
 | 2194 |  | 
 | 2195 | <p>Because LLVM is a typed representation, every LLVM <tt>Value</tt> is typed, | 
 | 2196 | and this <a href="#Type">Type</a> is available through the <tt>getType()</tt> | 
 | 2197 | method. In addition, all LLVM values can be named.  The "name" of the | 
 | 2198 | <tt>Value</tt> is a symbolic string printed in the LLVM code:</p> | 
 | 2199 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 2200 | <div class="doc_code"> | 
 | 2201 | <pre> | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 2202 | %<b>foo</b> = add i32 1, 2 | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 2203 | </pre> | 
 | 2204 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2205 |  | 
 | 2206 | <p><a name="#nameWarning">The name of this instruction is "foo".</a> <b>NOTE</b> | 
 | 2207 | that the name of any value may be missing (an empty string), so names should | 
 | 2208 | <b>ONLY</b> be used for debugging (making the source code easier to read, | 
 | 2209 | debugging printouts), they should not be used to keep track of values or map | 
 | 2210 | between them.  For this purpose, use a <tt>std::map</tt> of pointers to the | 
 | 2211 | <tt>Value</tt> itself instead.</p> | 
 | 2212 |  | 
 | 2213 | <p>One important aspect of LLVM is that there is no distinction between an SSA | 
 | 2214 | variable and the operation that produces it.  Because of this, any reference to | 
 | 2215 | the value produced by an instruction (or the value available as an incoming | 
| Chris Lattner | d5fc4fc | 2004-03-18 14:58:55 +0000 | [diff] [blame] | 2216 | argument, for example) is represented as a direct pointer to the instance of | 
 | 2217 | the class that | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2218 | represents this value.  Although this may take some getting used to, it | 
 | 2219 | simplifies the representation and makes it easier to manipulate.</p> | 
 | 2220 |  | 
 | 2221 | </div> | 
 | 2222 |  | 
 | 2223 | <!-- _______________________________________________________________________ --> | 
 | 2224 | <div class="doc_subsubsection"> | 
 | 2225 |   <a name="m_Value">Important Public Members of the <tt>Value</tt> class</a> | 
 | 2226 | </div> | 
 | 2227 |  | 
 | 2228 | <div class="doc_text"> | 
 | 2229 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2230 | <ul> | 
 | 2231 |   <li><tt>Value::use_iterator</tt> - Typedef for iterator over the | 
 | 2232 | use-list<br> | 
 | 2233 |     <tt>Value::use_const_iterator</tt> - Typedef for const_iterator over | 
 | 2234 | the use-list<br> | 
 | 2235 |     <tt>unsigned use_size()</tt> - Returns the number of users of the | 
 | 2236 | value.<br> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 2237 |     <tt>bool use_empty()</tt> - Returns true if there are no users.<br> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2238 |     <tt>use_iterator use_begin()</tt> - Get an iterator to the start of | 
 | 2239 | the use-list.<br> | 
 | 2240 |     <tt>use_iterator use_end()</tt> - Get an iterator to the end of the | 
 | 2241 | use-list.<br> | 
 | 2242 |     <tt><a href="#User">User</a> *use_back()</tt> - Returns the last | 
 | 2243 | element in the list. | 
 | 2244 |     <p> These methods are the interface to access the def-use | 
 | 2245 | information in LLVM.  As with all other iterators in LLVM, the naming | 
 | 2246 | conventions follow the conventions defined by the <a href="#stl">STL</a>.</p> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2247 |   </li> | 
 | 2248 |   <li><tt><a href="#Type">Type</a> *getType() const</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2249 |     <p>This method returns the Type of the Value.</p> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2250 |   </li> | 
 | 2251 |   <li><tt>bool hasName() const</tt><br> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 2252 |     <tt>std::string getName() const</tt><br> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2253 |     <tt>void setName(const std::string &Name)</tt> | 
 | 2254 |     <p> This family of methods is used to access and assign a name to a <tt>Value</tt>, | 
 | 2255 | be aware of the <a href="#nameWarning">precaution above</a>.</p> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2256 |   </li> | 
 | 2257 |   <li><tt>void replaceAllUsesWith(Value *V)</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2258 |  | 
 | 2259 |     <p>This method traverses the use list of a <tt>Value</tt> changing all <a | 
 | 2260 |     href="#User"><tt>User</tt>s</a> of the current value to refer to | 
 | 2261 |     "<tt>V</tt>" instead.  For example, if you detect that an instruction always | 
 | 2262 |     produces a constant value (for example through constant folding), you can | 
 | 2263 |     replace all uses of the instruction with the constant like this:</p> | 
 | 2264 |  | 
| Bill Wendling | 3cd5ca6 | 2006-10-11 06:30:10 +0000 | [diff] [blame] | 2265 | <div class="doc_code"> | 
 | 2266 | <pre> | 
 | 2267 | Inst->replaceAllUsesWith(ConstVal); | 
 | 2268 | </pre> | 
 | 2269 | </div> | 
 | 2270 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2271 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2272 |  | 
 | 2273 | </div> | 
 | 2274 |  | 
 | 2275 | <!-- ======================================================================= --> | 
 | 2276 | <div class="doc_subsection"> | 
 | 2277 |   <a name="User">The <tt>User</tt> class</a> | 
 | 2278 | </div> | 
 | 2279 |  | 
 | 2280 | <div class="doc_text"> | 
 | 2281 |    | 
 | 2282 | <p> | 
 | 2283 | <tt>#include "<a href="/doxygen/User_8h-source.html">llvm/User.h</a>"</tt><br> | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 2284 | doxygen info: <a href="/doxygen/classllvm_1_1User.html">User Class</a><br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2285 | Superclass: <a href="#Value"><tt>Value</tt></a></p> | 
 | 2286 |  | 
 | 2287 | <p>The <tt>User</tt> class is the common base class of all LLVM nodes that may | 
 | 2288 | refer to <a href="#Value"><tt>Value</tt></a>s.  It exposes a list of "Operands" | 
 | 2289 | that are all of the <a href="#Value"><tt>Value</tt></a>s that the User is | 
 | 2290 | referring to.  The <tt>User</tt> class itself is a subclass of | 
 | 2291 | <tt>Value</tt>.</p> | 
 | 2292 |  | 
 | 2293 | <p>The operands of a <tt>User</tt> point directly to the LLVM <a | 
 | 2294 | href="#Value"><tt>Value</tt></a> that it refers to.  Because LLVM uses Static | 
 | 2295 | Single Assignment (SSA) form, there can only be one definition referred to, | 
 | 2296 | allowing this direct connection.  This connection provides the use-def | 
 | 2297 | information in LLVM.</p> | 
 | 2298 |  | 
 | 2299 | </div> | 
 | 2300 |  | 
 | 2301 | <!-- _______________________________________________________________________ --> | 
 | 2302 | <div class="doc_subsubsection"> | 
 | 2303 |   <a name="m_User">Important Public Members of the <tt>User</tt> class</a> | 
 | 2304 | </div> | 
 | 2305 |  | 
 | 2306 | <div class="doc_text"> | 
 | 2307 |  | 
 | 2308 | <p>The <tt>User</tt> class exposes the operand list in two ways: through | 
 | 2309 | an index access interface and through an iterator based interface.</p> | 
 | 2310 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2311 | <ul> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2312 |   <li><tt>Value *getOperand(unsigned i)</tt><br> | 
 | 2313 |     <tt>unsigned getNumOperands()</tt> | 
 | 2314 |     <p> These two methods expose the operands of the <tt>User</tt> in a | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2315 | convenient form for direct access.</p></li> | 
 | 2316 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2317 |   <li><tt>User::op_iterator</tt> - Typedef for iterator over the operand | 
 | 2318 | list<br> | 
| Chris Lattner | 5836082 | 2005-01-17 00:12:04 +0000 | [diff] [blame] | 2319 |     <tt>op_iterator op_begin()</tt> - Get an iterator to the start of  | 
 | 2320 | the operand list.<br> | 
 | 2321 |     <tt>op_iterator op_end()</tt> - Get an iterator to the end of the | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2322 | operand list. | 
 | 2323 |     <p> Together, these methods make up the iterator based interface to | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2324 | the operands of a <tt>User</tt>.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2325 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2326 |  | 
 | 2327 | </div>     | 
 | 2328 |  | 
 | 2329 | <!-- ======================================================================= --> | 
 | 2330 | <div class="doc_subsection"> | 
 | 2331 |   <a name="Instruction">The <tt>Instruction</tt> class</a> | 
 | 2332 | </div> | 
 | 2333 |  | 
 | 2334 | <div class="doc_text"> | 
 | 2335 |  | 
 | 2336 | <p><tt>#include "</tt><tt><a | 
 | 2337 | href="/doxygen/Instruction_8h-source.html">llvm/Instruction.h</a>"</tt><br> | 
| Misha Brukman | 31ca1de | 2004-06-03 23:35:54 +0000 | [diff] [blame] | 2338 | doxygen info: <a href="/doxygen/classllvm_1_1Instruction.html">Instruction Class</a><br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2339 | Superclasses: <a href="#User"><tt>User</tt></a>, <a | 
 | 2340 | href="#Value"><tt>Value</tt></a></p> | 
 | 2341 |  | 
 | 2342 | <p>The <tt>Instruction</tt> class is the common base class for all LLVM | 
 | 2343 | instructions.  It provides only a few methods, but is a very commonly used | 
 | 2344 | class.  The primary data tracked by the <tt>Instruction</tt> class itself is the | 
 | 2345 | opcode (instruction type) and the parent <a | 
 | 2346 | href="#BasicBlock"><tt>BasicBlock</tt></a> the <tt>Instruction</tt> is embedded | 
 | 2347 | into.  To represent a specific type of instruction, one of many subclasses of | 
 | 2348 | <tt>Instruction</tt> are used.</p> | 
 | 2349 |  | 
 | 2350 | <p> Because the <tt>Instruction</tt> class subclasses the <a | 
 | 2351 | href="#User"><tt>User</tt></a> class, its operands can be accessed in the same | 
 | 2352 | way as for other <a href="#User"><tt>User</tt></a>s (with the | 
 | 2353 | <tt>getOperand()</tt>/<tt>getNumOperands()</tt> and | 
 | 2354 | <tt>op_begin()</tt>/<tt>op_end()</tt> methods).</p> <p> An important file for | 
 | 2355 | the <tt>Instruction</tt> class is the <tt>llvm/Instruction.def</tt> file. This | 
 | 2356 | file contains some meta-data about the various different types of instructions | 
 | 2357 | in LLVM.  It describes the enum values that are used as opcodes (for example | 
| Reid Spencer | c92d25d | 2006-12-19 19:47:19 +0000 | [diff] [blame] | 2358 | <tt>Instruction::Add</tt> and <tt>Instruction::ICmp</tt>), as well as the | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2359 | concrete sub-classes of <tt>Instruction</tt> that implement the instruction (for | 
 | 2360 | example <tt><a href="#BinaryOperator">BinaryOperator</a></tt> and <tt><a | 
| Reid Spencer | c92d25d | 2006-12-19 19:47:19 +0000 | [diff] [blame] | 2361 | href="#CmpInst">CmpInst</a></tt>).  Unfortunately, the use of macros in | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2362 | this file confuses doxygen, so these enum values don't show up correctly in the | 
| Misha Brukman | 31ca1de | 2004-06-03 23:35:54 +0000 | [diff] [blame] | 2363 | <a href="/doxygen/classllvm_1_1Instruction.html">doxygen output</a>.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2364 |  | 
 | 2365 | </div> | 
 | 2366 |  | 
 | 2367 | <!-- _______________________________________________________________________ --> | 
 | 2368 | <div class="doc_subsubsection"> | 
| Reid Spencer | c92d25d | 2006-12-19 19:47:19 +0000 | [diff] [blame] | 2369 |   <a name="s_Instruction">Important Subclasses of the <tt>Instruction</tt> | 
 | 2370 |   class</a> | 
 | 2371 | </div> | 
 | 2372 | <div class="doc_text"> | 
 | 2373 |   <ul> | 
 | 2374 |     <li><tt><a name="BinaryOperator">BinaryOperator</a></tt> | 
 | 2375 |     <p>This subclasses represents all two operand instructions whose operands | 
 | 2376 |     must be the same type, except for the comparison instructions.</p></li> | 
 | 2377 |     <li><tt><a name="CastInst">CastInst</a></tt> | 
 | 2378 |     <p>This subclass is the parent of the 12 casting instructions. It provides | 
 | 2379 |     common operations on cast instructions.</p> | 
 | 2380 |     <li><tt><a name="CmpInst">CmpInst</a></tt> | 
 | 2381 |     <p>This subclass respresents the two comparison instructions,  | 
 | 2382 |     <a href="LangRef.html#i_icmp">ICmpInst</a> (integer opreands), and | 
 | 2383 |     <a href="LangRef.html#i_fcmp">FCmpInst</a> (floating point operands).</p> | 
 | 2384 |     <li><tt><a name="TerminatorInst">TerminatorInst</a></tt> | 
 | 2385 |     <p>This subclass is the parent of all terminator instructions (those which | 
 | 2386 |     can terminate a block).</p> | 
 | 2387 |   </ul> | 
 | 2388 |   </div> | 
 | 2389 |  | 
 | 2390 | <!-- _______________________________________________________________________ --> | 
 | 2391 | <div class="doc_subsubsection"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2392 |   <a name="m_Instruction">Important Public Members of the <tt>Instruction</tt> | 
 | 2393 |   class</a> | 
 | 2394 | </div> | 
 | 2395 |  | 
 | 2396 | <div class="doc_text"> | 
 | 2397 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2398 | <ul> | 
 | 2399 |   <li><tt><a href="#BasicBlock">BasicBlock</a> *getParent()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2400 |     <p>Returns the <a href="#BasicBlock"><tt>BasicBlock</tt></a> that | 
 | 2401 | this  <tt>Instruction</tt> is embedded into.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2402 |   <li><tt>bool mayWriteToMemory()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2403 |     <p>Returns true if the instruction writes to memory, i.e. it is a | 
 | 2404 |       <tt>call</tt>,<tt>free</tt>,<tt>invoke</tt>, or <tt>store</tt>.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2405 |   <li><tt>unsigned getOpcode()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2406 |     <p>Returns the opcode for the <tt>Instruction</tt>.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2407 |   <li><tt><a href="#Instruction">Instruction</a> *clone() const</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2408 |     <p>Returns another instance of the specified instruction, identical | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2409 | in all ways to the original except that the instruction has no parent | 
 | 2410 | (ie it's not embedded into a <a href="#BasicBlock"><tt>BasicBlock</tt></a>), | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2411 | and it has no name</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2412 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2413 |  | 
 | 2414 | </div> | 
 | 2415 |  | 
 | 2416 | <!-- ======================================================================= --> | 
 | 2417 | <div class="doc_subsection"> | 
 | 2418 |   <a name="BasicBlock">The <tt>BasicBlock</tt> class</a> | 
 | 2419 | </div> | 
 | 2420 |  | 
 | 2421 | <div class="doc_text"> | 
 | 2422 |  | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 2423 | <p><tt>#include "<a | 
 | 2424 | href="/doxygen/BasicBlock_8h-source.html">llvm/BasicBlock.h</a>"</tt><br> | 
 | 2425 | doxygen info: <a href="/doxygen/structllvm_1_1BasicBlock.html">BasicBlock | 
 | 2426 | Class</a><br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2427 | Superclass: <a href="#Value"><tt>Value</tt></a></p> | 
 | 2428 |  | 
 | 2429 | <p>This class represents a single entry multiple exit section of the code, | 
 | 2430 | commonly known as a basic block by the compiler community.  The | 
 | 2431 | <tt>BasicBlock</tt> class maintains a list of <a | 
 | 2432 | href="#Instruction"><tt>Instruction</tt></a>s, which form the body of the block. | 
 | 2433 | Matching the language definition, the last element of this list of instructions | 
 | 2434 | is always a terminator instruction (a subclass of the <a | 
 | 2435 | href="#TerminatorInst"><tt>TerminatorInst</tt></a> class).</p> | 
 | 2436 |  | 
 | 2437 | <p>In addition to tracking the list of instructions that make up the block, the | 
 | 2438 | <tt>BasicBlock</tt> class also keeps track of the <a | 
 | 2439 | href="#Function"><tt>Function</tt></a> that it is embedded into.</p> | 
 | 2440 |  | 
 | 2441 | <p>Note that <tt>BasicBlock</tt>s themselves are <a | 
 | 2442 | href="#Value"><tt>Value</tt></a>s, because they are referenced by instructions | 
 | 2443 | like branches and can go in the switch tables. <tt>BasicBlock</tt>s have type | 
 | 2444 | <tt>label</tt>.</p> | 
 | 2445 |  | 
 | 2446 | </div> | 
 | 2447 |  | 
 | 2448 | <!-- _______________________________________________________________________ --> | 
 | 2449 | <div class="doc_subsubsection"> | 
 | 2450 |   <a name="m_BasicBlock">Important Public Members of the <tt>BasicBlock</tt> | 
 | 2451 |   class</a> | 
 | 2452 | </div> | 
 | 2453 |  | 
 | 2454 | <div class="doc_text"> | 
 | 2455 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2456 | <ul> | 
| Misha Brukman | b0e7e45 | 2004-10-29 04:33:19 +0000 | [diff] [blame] | 2457 |  | 
 | 2458 | <li><tt>BasicBlock(const std::string &Name = "", </tt><tt><a | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2459 |  href="#Function">Function</a> *Parent = 0)</tt> | 
| Misha Brukman | b0e7e45 | 2004-10-29 04:33:19 +0000 | [diff] [blame] | 2460 |  | 
 | 2461 | <p>The <tt>BasicBlock</tt> constructor is used to create new basic blocks for | 
 | 2462 | insertion into a function.  The constructor optionally takes a name for the new | 
 | 2463 | block, and a <a href="#Function"><tt>Function</tt></a> to insert it into.  If | 
 | 2464 | the <tt>Parent</tt> parameter is specified, the new <tt>BasicBlock</tt> is | 
 | 2465 | automatically inserted at the end of the specified <a | 
 | 2466 | href="#Function"><tt>Function</tt></a>, if not specified, the BasicBlock must be | 
 | 2467 | manually inserted into the <a href="#Function"><tt>Function</tt></a>.</p></li> | 
 | 2468 |  | 
 | 2469 | <li><tt>BasicBlock::iterator</tt> - Typedef for instruction list iterator<br> | 
 | 2470 | <tt>BasicBlock::const_iterator</tt> - Typedef for const_iterator.<br> | 
 | 2471 | <tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>, | 
| Chris Lattner | 77d6924 | 2005-03-15 05:19:20 +0000 | [diff] [blame] | 2472 | <tt>size()</tt>, <tt>empty()</tt> | 
| Misha Brukman | b0e7e45 | 2004-10-29 04:33:19 +0000 | [diff] [blame] | 2473 | STL-style functions for accessing the instruction list. | 
 | 2474 |  | 
 | 2475 | <p>These methods and typedefs are forwarding functions that have the same | 
 | 2476 | semantics as the standard library methods of the same names.  These methods | 
 | 2477 | expose the underlying instruction list of a basic block in a way that is easy to | 
 | 2478 | manipulate.  To get the full complement of container operations (including | 
 | 2479 | operations to update the list), you must use the <tt>getInstList()</tt> | 
 | 2480 | method.</p></li> | 
 | 2481 |  | 
 | 2482 | <li><tt>BasicBlock::InstListType &getInstList()</tt> | 
 | 2483 |  | 
 | 2484 | <p>This method is used to get access to the underlying container that actually | 
 | 2485 | holds the Instructions.  This method must be used when there isn't a forwarding | 
 | 2486 | function in the <tt>BasicBlock</tt> class for the operation that you would like | 
 | 2487 | to perform.  Because there are no forwarding functions for "updating" | 
 | 2488 | operations, you need to use this if you want to update the contents of a | 
 | 2489 | <tt>BasicBlock</tt>.</p></li> | 
 | 2490 |  | 
 | 2491 | <li><tt><a href="#Function">Function</a> *getParent()</tt> | 
 | 2492 |  | 
 | 2493 | <p> Returns a pointer to <a href="#Function"><tt>Function</tt></a> the block is | 
 | 2494 | embedded into, or a null pointer if it is homeless.</p></li> | 
 | 2495 |  | 
 | 2496 | <li><tt><a href="#TerminatorInst">TerminatorInst</a> *getTerminator()</tt> | 
 | 2497 |  | 
 | 2498 | <p> Returns a pointer to the terminator instruction that appears at the end of | 
 | 2499 | the <tt>BasicBlock</tt>.  If there is no terminator instruction, or if the last | 
 | 2500 | instruction in the block is not a terminator, then a null pointer is | 
 | 2501 | returned.</p></li> | 
 | 2502 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2503 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2504 |  | 
 | 2505 | </div> | 
 | 2506 |  | 
 | 2507 | <!-- ======================================================================= --> | 
 | 2508 | <div class="doc_subsection"> | 
 | 2509 |   <a name="GlobalValue">The <tt>GlobalValue</tt> class</a> | 
 | 2510 | </div> | 
 | 2511 |  | 
 | 2512 | <div class="doc_text"> | 
 | 2513 |  | 
 | 2514 | <p><tt>#include "<a | 
 | 2515 | href="/doxygen/GlobalValue_8h-source.html">llvm/GlobalValue.h</a>"</tt><br> | 
| Misha Brukman | 384047f | 2004-06-03 23:29:12 +0000 | [diff] [blame] | 2516 | doxygen info: <a href="/doxygen/classllvm_1_1GlobalValue.html">GlobalValue | 
 | 2517 | Class</a><br> | 
| Reid Spencer | be5e85e | 2006-04-14 14:11:48 +0000 | [diff] [blame] | 2518 | Superclasses: <a href="#Constant"><tt>Constant</tt></a>,  | 
 | 2519 | <a href="#User"><tt>User</tt></a>, <a href="#Value"><tt>Value</tt></a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2520 |  | 
 | 2521 | <p>Global values (<a href="#GlobalVariable"><tt>GlobalVariable</tt></a>s or <a | 
 | 2522 | href="#Function"><tt>Function</tt></a>s) are the only LLVM values that are | 
 | 2523 | visible in the bodies of all <a href="#Function"><tt>Function</tt></a>s. | 
 | 2524 | Because they are visible at global scope, they are also subject to linking with | 
 | 2525 | other globals defined in different translation units.  To control the linking | 
 | 2526 | process, <tt>GlobalValue</tt>s know their linkage rules. Specifically, | 
 | 2527 | <tt>GlobalValue</tt>s know whether they have internal or external linkage, as | 
| Reid Spencer | 8b2da7a | 2004-07-18 13:10:31 +0000 | [diff] [blame] | 2528 | defined by the <tt>LinkageTypes</tt> enumeration.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2529 |  | 
 | 2530 | <p>If a <tt>GlobalValue</tt> has internal linkage (equivalent to being | 
 | 2531 | <tt>static</tt> in C), it is not visible to code outside the current translation | 
 | 2532 | unit, and does not participate in linking.  If it has external linkage, it is | 
 | 2533 | visible to external code, and does participate in linking.  In addition to | 
 | 2534 | linkage information, <tt>GlobalValue</tt>s keep track of which <a | 
 | 2535 | href="#Module"><tt>Module</tt></a> they are currently part of.</p> | 
 | 2536 |  | 
 | 2537 | <p>Because <tt>GlobalValue</tt>s are memory objects, they are always referred to | 
 | 2538 | by their <b>address</b>. As such, the <a href="#Type"><tt>Type</tt></a> of a | 
 | 2539 | global is always a pointer to its contents. It is important to remember this | 
 | 2540 | when using the <tt>GetElementPtrInst</tt> instruction because this pointer must | 
 | 2541 | be dereferenced first. For example, if you have a <tt>GlobalVariable</tt> (a | 
 | 2542 | subclass of <tt>GlobalValue)</tt> that is an array of 24 ints, type <tt>[24 x | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 2543 | i32]</tt>, then the <tt>GlobalVariable</tt> is a pointer to that array. Although | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2544 | the address of the first element of this array and the value of the | 
 | 2545 | <tt>GlobalVariable</tt> are the same, they have different types. The | 
| Reid Spencer | 06565dc | 2007-01-12 17:11:23 +0000 | [diff] [blame] | 2546 | <tt>GlobalVariable</tt>'s type is <tt>[24 x i32]</tt>. The first element's type | 
 | 2547 | is <tt>i32.</tt> Because of this, accessing a global value requires you to | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2548 | dereference the pointer with <tt>GetElementPtrInst</tt> first, then its elements | 
 | 2549 | can be accessed. This is explained in the <a href="LangRef.html#globalvars">LLVM | 
 | 2550 | Language Reference Manual</a>.</p> | 
 | 2551 |  | 
 | 2552 | </div> | 
 | 2553 |  | 
 | 2554 | <!-- _______________________________________________________________________ --> | 
 | 2555 | <div class="doc_subsubsection"> | 
 | 2556 |   <a name="m_GlobalValue">Important Public Members of the <tt>GlobalValue</tt> | 
 | 2557 |   class</a> | 
 | 2558 | </div> | 
 | 2559 |  | 
 | 2560 | <div class="doc_text"> | 
 | 2561 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2562 | <ul> | 
 | 2563 |   <li><tt>bool hasInternalLinkage() const</tt><br> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 2564 |     <tt>bool hasExternalLinkage() const</tt><br> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2565 |     <tt>void setInternalLinkage(bool HasInternalLinkage)</tt> | 
 | 2566 |     <p> These methods manipulate the linkage characteristics of the <tt>GlobalValue</tt>.</p> | 
 | 2567 |     <p> </p> | 
 | 2568 |   </li> | 
 | 2569 |   <li><tt><a href="#Module">Module</a> *getParent()</tt> | 
 | 2570 |     <p> This returns the <a href="#Module"><tt>Module</tt></a> that the | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2571 | GlobalValue is currently embedded into.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2572 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2573 |  | 
 | 2574 | </div> | 
 | 2575 |  | 
 | 2576 | <!-- ======================================================================= --> | 
 | 2577 | <div class="doc_subsection"> | 
 | 2578 |   <a name="Function">The <tt>Function</tt> class</a> | 
 | 2579 | </div> | 
 | 2580 |  | 
 | 2581 | <div class="doc_text"> | 
 | 2582 |  | 
 | 2583 | <p><tt>#include "<a | 
 | 2584 | href="/doxygen/Function_8h-source.html">llvm/Function.h</a>"</tt><br> doxygen | 
| Misha Brukman | 31ca1de | 2004-06-03 23:35:54 +0000 | [diff] [blame] | 2585 | info: <a href="/doxygen/classllvm_1_1Function.html">Function Class</a><br> | 
| Reid Spencer | be5e85e | 2006-04-14 14:11:48 +0000 | [diff] [blame] | 2586 | Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,  | 
 | 2587 | <a href="#Constant"><tt>Constant</tt></a>,  | 
 | 2588 | <a href="#User"><tt>User</tt></a>,  | 
 | 2589 | <a href="#Value"><tt>Value</tt></a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2590 |  | 
 | 2591 | <p>The <tt>Function</tt> class represents a single procedure in LLVM.  It is | 
 | 2592 | actually one of the more complex classes in the LLVM heirarchy because it must | 
 | 2593 | keep track of a large amount of data.  The <tt>Function</tt> class keeps track | 
| Reid Spencer | be5e85e | 2006-04-14 14:11:48 +0000 | [diff] [blame] | 2594 | of a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, a list of formal  | 
 | 2595 | <a href="#Argument"><tt>Argument</tt></a>s, and a  | 
 | 2596 | <a href="#SymbolTable"><tt>SymbolTable</tt></a>.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2597 |  | 
 | 2598 | <p>The list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s is the most | 
 | 2599 | commonly used part of <tt>Function</tt> objects.  The list imposes an implicit | 
 | 2600 | ordering of the blocks in the function, which indicate how the code will be | 
 | 2601 | layed out by the backend.  Additionally, the first <a | 
 | 2602 | href="#BasicBlock"><tt>BasicBlock</tt></a> is the implicit entry node for the | 
 | 2603 | <tt>Function</tt>.  It is not legal in LLVM to explicitly branch to this initial | 
 | 2604 | block.  There are no implicit exit nodes, and in fact there may be multiple exit | 
 | 2605 | nodes from a single <tt>Function</tt>.  If the <a | 
 | 2606 | href="#BasicBlock"><tt>BasicBlock</tt></a> list is empty, this indicates that | 
 | 2607 | the <tt>Function</tt> is actually a function declaration: the actual body of the | 
 | 2608 | function hasn't been linked in yet.</p> | 
 | 2609 |  | 
 | 2610 | <p>In addition to a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, the | 
 | 2611 | <tt>Function</tt> class also keeps track of the list of formal <a | 
 | 2612 | href="#Argument"><tt>Argument</tt></a>s that the function receives.  This | 
 | 2613 | container manages the lifetime of the <a href="#Argument"><tt>Argument</tt></a> | 
 | 2614 | nodes, just like the <a href="#BasicBlock"><tt>BasicBlock</tt></a> list does for | 
 | 2615 | the <a href="#BasicBlock"><tt>BasicBlock</tt></a>s.</p> | 
 | 2616 |  | 
 | 2617 | <p>The <a href="#SymbolTable"><tt>SymbolTable</tt></a> is a very rarely used | 
 | 2618 | LLVM feature that is only used when you have to look up a value by name.  Aside | 
 | 2619 | from that, the <a href="#SymbolTable"><tt>SymbolTable</tt></a> is used | 
 | 2620 | internally to make sure that there are not conflicts between the names of <a | 
 | 2621 | href="#Instruction"><tt>Instruction</tt></a>s, <a | 
 | 2622 | href="#BasicBlock"><tt>BasicBlock</tt></a>s, or <a | 
 | 2623 | href="#Argument"><tt>Argument</tt></a>s in the function body.</p> | 
 | 2624 |  | 
| Reid Spencer | 8b2da7a | 2004-07-18 13:10:31 +0000 | [diff] [blame] | 2625 | <p>Note that <tt>Function</tt> is a <a href="#GlobalValue">GlobalValue</a> | 
 | 2626 | and therefore also a <a href="#Constant">Constant</a>. The value of the function | 
 | 2627 | is its address (after linking) which is guaranteed to be constant.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2628 | </div> | 
 | 2629 |  | 
 | 2630 | <!-- _______________________________________________________________________ --> | 
 | 2631 | <div class="doc_subsubsection"> | 
 | 2632 |   <a name="m_Function">Important Public Members of the <tt>Function</tt> | 
 | 2633 |   class</a> | 
 | 2634 | </div> | 
 | 2635 |  | 
 | 2636 | <div class="doc_text"> | 
 | 2637 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2638 | <ul> | 
 | 2639 |   <li><tt>Function(const </tt><tt><a href="#FunctionType">FunctionType</a> | 
| Chris Lattner | ac479e5 | 2004-08-04 05:10:48 +0000 | [diff] [blame] | 2640 |   *Ty, LinkageTypes Linkage, const std::string &N = "", Module* Parent = 0)</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2641 |  | 
 | 2642 |     <p>Constructor used when you need to create new <tt>Function</tt>s to add | 
 | 2643 |     the the program.  The constructor must specify the type of the function to | 
| Chris Lattner | ac479e5 | 2004-08-04 05:10:48 +0000 | [diff] [blame] | 2644 |     create and what type of linkage the function should have. The <a  | 
 | 2645 |     href="#FunctionType"><tt>FunctionType</tt></a> argument | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2646 |     specifies the formal arguments and return value for the function. The same | 
 | 2647 |     <a href="#FunctionTypel"><tt>FunctionType</tt></a> value can be used to | 
 | 2648 |     create multiple functions. The <tt>Parent</tt> argument specifies the Module | 
 | 2649 |     in which the function is defined. If this argument is provided, the function | 
 | 2650 |     will automatically be inserted into that module's list of | 
 | 2651 |     functions.</p></li> | 
 | 2652 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2653 |   <li><tt>bool isExternal()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2654 |  | 
 | 2655 |     <p>Return whether or not the <tt>Function</tt> has a body defined.  If the | 
 | 2656 |     function is "external", it does not have a body, and thus must be resolved | 
 | 2657 |     by linking with a function defined in a different translation unit.</p></li> | 
 | 2658 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2659 |   <li><tt>Function::iterator</tt> - Typedef for basic block list iterator<br> | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 2660 |     <tt>Function::const_iterator</tt> - Typedef for const_iterator.<br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2661 |  | 
| Chris Lattner | 77d6924 | 2005-03-15 05:19:20 +0000 | [diff] [blame] | 2662 |     <tt>begin()</tt>, <tt>end()</tt> | 
 | 2663 |     <tt>size()</tt>, <tt>empty()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2664 |  | 
 | 2665 |     <p>These are forwarding methods that make it easy to access the contents of | 
 | 2666 |     a <tt>Function</tt> object's <a href="#BasicBlock"><tt>BasicBlock</tt></a> | 
 | 2667 |     list.</p></li> | 
 | 2668 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2669 |   <li><tt>Function::BasicBlockListType &getBasicBlockList()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2670 |  | 
 | 2671 |     <p>Returns the list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s.  This | 
 | 2672 |     is necessary to use when you need to update the list or perform a complex | 
 | 2673 |     action that doesn't have a forwarding method.</p></li> | 
 | 2674 |  | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2675 |   <li><tt>Function::arg_iterator</tt> - Typedef for the argument list | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2676 | iterator<br> | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2677 |     <tt>Function::const_arg_iterator</tt> - Typedef for const_iterator.<br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2678 |  | 
| Chris Lattner | 77d6924 | 2005-03-15 05:19:20 +0000 | [diff] [blame] | 2679 |     <tt>arg_begin()</tt>, <tt>arg_end()</tt> | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2680 |     <tt>arg_size()</tt>, <tt>arg_empty()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2681 |  | 
 | 2682 |     <p>These are forwarding methods that make it easy to access the contents of | 
 | 2683 |     a <tt>Function</tt> object's <a href="#Argument"><tt>Argument</tt></a> | 
 | 2684 |     list.</p></li> | 
 | 2685 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2686 |   <li><tt>Function::ArgumentListType &getArgumentList()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2687 |  | 
 | 2688 |     <p>Returns the list of <a href="#Argument"><tt>Argument</tt></a>s.  This is | 
 | 2689 |     necessary to use when you need to update the list or perform a complex | 
 | 2690 |     action that doesn't have a forwarding method.</p></li> | 
 | 2691 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2692 |   <li><tt><a href="#BasicBlock">BasicBlock</a> &getEntryBlock()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2693 |  | 
 | 2694 |     <p>Returns the entry <a href="#BasicBlock"><tt>BasicBlock</tt></a> for the | 
 | 2695 |     function.  Because the entry block for the function is always the first | 
 | 2696 |     block, this returns the first block of the <tt>Function</tt>.</p></li> | 
 | 2697 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2698 |   <li><tt><a href="#Type">Type</a> *getReturnType()</tt><br> | 
 | 2699 |     <tt><a href="#FunctionType">FunctionType</a> *getFunctionType()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2700 |  | 
 | 2701 |     <p>This traverses the <a href="#Type"><tt>Type</tt></a> of the | 
 | 2702 |     <tt>Function</tt> and returns the return type of the function, or the <a | 
 | 2703 |     href="#FunctionType"><tt>FunctionType</tt></a> of the actual | 
 | 2704 |     function.</p></li> | 
 | 2705 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2706 |   <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2707 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2708 |     <p> Return a pointer to the <a href="#SymbolTable"><tt>SymbolTable</tt></a> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2709 |     for this <tt>Function</tt>.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2710 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2711 |  | 
 | 2712 | </div> | 
 | 2713 |  | 
 | 2714 | <!-- ======================================================================= --> | 
 | 2715 | <div class="doc_subsection"> | 
 | 2716 |   <a name="GlobalVariable">The <tt>GlobalVariable</tt> class</a> | 
 | 2717 | </div> | 
 | 2718 |  | 
 | 2719 | <div class="doc_text"> | 
 | 2720 |  | 
 | 2721 | <p><tt>#include "<a | 
 | 2722 | href="/doxygen/GlobalVariable_8h-source.html">llvm/GlobalVariable.h</a>"</tt> | 
 | 2723 | <br> | 
| Tanya Lattner | a3da777 | 2004-06-22 08:02:25 +0000 | [diff] [blame] | 2724 | doxygen info: <a href="/doxygen/classllvm_1_1GlobalVariable.html">GlobalVariable | 
| Reid Spencer | be5e85e | 2006-04-14 14:11:48 +0000 | [diff] [blame] | 2725 |  Class</a><br> | 
 | 2726 | Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,  | 
 | 2727 | <a href="#Constant"><tt>Constant</tt></a>, | 
 | 2728 | <a href="#User"><tt>User</tt></a>, | 
 | 2729 | <a href="#Value"><tt>Value</tt></a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2730 |  | 
 | 2731 | <p>Global variables are represented with the (suprise suprise) | 
 | 2732 | <tt>GlobalVariable</tt> class. Like functions, <tt>GlobalVariable</tt>s are also | 
 | 2733 | subclasses of <a href="#GlobalValue"><tt>GlobalValue</tt></a>, and as such are | 
 | 2734 | always referenced by their address (global values must live in memory, so their | 
| Reid Spencer | be5e85e | 2006-04-14 14:11:48 +0000 | [diff] [blame] | 2735 | "name" refers to their constant address). See  | 
 | 2736 | <a href="#GlobalValue"><tt>GlobalValue</tt></a> for more on this.  Global  | 
 | 2737 | variables may have an initial value (which must be a  | 
 | 2738 | <a href="#Constant"><tt>Constant</tt></a>), and if they have an initializer,  | 
 | 2739 | they may be marked as "constant" themselves (indicating that their contents  | 
 | 2740 | never change at runtime).</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2741 | </div> | 
 | 2742 |  | 
 | 2743 | <!-- _______________________________________________________________________ --> | 
 | 2744 | <div class="doc_subsubsection"> | 
 | 2745 |   <a name="m_GlobalVariable">Important Public Members of the | 
 | 2746 |   <tt>GlobalVariable</tt> class</a> | 
 | 2747 | </div> | 
 | 2748 |  | 
 | 2749 | <div class="doc_text"> | 
 | 2750 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2751 | <ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2752 |   <li><tt>GlobalVariable(const </tt><tt><a href="#Type">Type</a> *Ty, bool | 
 | 2753 |   isConstant, LinkageTypes& Linkage, <a href="#Constant">Constant</a> | 
 | 2754 |   *Initializer = 0, const std::string &Name = "", Module* Parent = 0)</tt> | 
 | 2755 |  | 
 | 2756 |     <p>Create a new global variable of the specified type. If | 
 | 2757 |     <tt>isConstant</tt> is true then the global variable will be marked as | 
 | 2758 |     unchanging for the program. The Linkage parameter specifies the type of | 
 | 2759 |     linkage (internal, external, weak, linkonce, appending) for the variable. If | 
 | 2760 |     the linkage is InternalLinkage, WeakLinkage, or LinkOnceLinkage,  then | 
 | 2761 |     the resultant global variable will have internal linkage.  AppendingLinkage | 
 | 2762 |     concatenates together all instances (in different translation units) of the | 
 | 2763 |     variable into a single variable but is only applicable to arrays.   See | 
 | 2764 |     the <a href="LangRef.html#modulestructure">LLVM Language Reference</a> for | 
 | 2765 |     further details on linkage types. Optionally an initializer, a name, and the | 
 | 2766 |     module to put the variable into may be specified for the global variable as | 
 | 2767 |     well.</p></li> | 
 | 2768 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2769 |   <li><tt>bool isConstant() const</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2770 |  | 
 | 2771 |     <p>Returns true if this is a global variable that is known not to | 
 | 2772 |     be modified at runtime.</p></li> | 
 | 2773 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2774 |   <li><tt>bool hasInitializer()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2775 |  | 
 | 2776 |     <p>Returns true if this <tt>GlobalVariable</tt> has an intializer.</p></li> | 
 | 2777 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2778 |   <li><tt><a href="#Constant">Constant</a> *getInitializer()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2779 |  | 
 | 2780 |     <p>Returns the intial value for a <tt>GlobalVariable</tt>.  It is not legal | 
 | 2781 |     to call this method if there is no initializer.</p></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2782 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2783 |  | 
 | 2784 | </div> | 
 | 2785 |  | 
 | 2786 | <!-- ======================================================================= --> | 
 | 2787 | <div class="doc_subsection"> | 
 | 2788 |   <a name="Module">The <tt>Module</tt> class</a> | 
 | 2789 | </div> | 
 | 2790 |  | 
 | 2791 | <div class="doc_text"> | 
 | 2792 |  | 
 | 2793 | <p><tt>#include "<a | 
 | 2794 | href="/doxygen/Module_8h-source.html">llvm/Module.h</a>"</tt><br> doxygen info: | 
| Tanya Lattner | a3da777 | 2004-06-22 08:02:25 +0000 | [diff] [blame] | 2795 | <a href="/doxygen/classllvm_1_1Module.html">Module Class</a></p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2796 |  | 
 | 2797 | <p>The <tt>Module</tt> class represents the top level structure present in LLVM | 
 | 2798 | programs.  An LLVM module is effectively either a translation unit of the | 
 | 2799 | original program or a combination of several translation units merged by the | 
 | 2800 | linker.  The <tt>Module</tt> class keeps track of a list of <a | 
 | 2801 | href="#Function"><tt>Function</tt></a>s, a list of <a | 
 | 2802 | href="#GlobalVariable"><tt>GlobalVariable</tt></a>s, and a <a | 
 | 2803 | href="#SymbolTable"><tt>SymbolTable</tt></a>.  Additionally, it contains a few | 
 | 2804 | helpful member functions that try to make common operations easy.</p> | 
 | 2805 |  | 
 | 2806 | </div> | 
 | 2807 |  | 
 | 2808 | <!-- _______________________________________________________________________ --> | 
 | 2809 | <div class="doc_subsubsection"> | 
 | 2810 |   <a name="m_Module">Important Public Members of the <tt>Module</tt> class</a> | 
 | 2811 | </div> | 
 | 2812 |  | 
 | 2813 | <div class="doc_text"> | 
 | 2814 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2815 | <ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2816 |   <li><tt>Module::Module(std::string name = "")</tt></li> | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2817 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2818 |  | 
 | 2819 | <p>Constructing a <a href="#Module">Module</a> is easy. You can optionally | 
 | 2820 | provide a name for it (probably based on the name of the translation unit).</p> | 
 | 2821 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2822 | <ul> | 
 | 2823 |   <li><tt>Module::iterator</tt> - Typedef for function list iterator<br> | 
| Chris Lattner | 0377de4 | 2002-09-06 14:50:55 +0000 | [diff] [blame] | 2824 |     <tt>Module::const_iterator</tt> - Typedef for const_iterator.<br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2825 |  | 
| Chris Lattner | 77d6924 | 2005-03-15 05:19:20 +0000 | [diff] [blame] | 2826 |     <tt>begin()</tt>, <tt>end()</tt> | 
 | 2827 |     <tt>size()</tt>, <tt>empty()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2828 |  | 
 | 2829 |     <p>These are forwarding methods that make it easy to access the contents of | 
 | 2830 |     a <tt>Module</tt> object's <a href="#Function"><tt>Function</tt></a> | 
 | 2831 |     list.</p></li> | 
 | 2832 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2833 |   <li><tt>Module::FunctionListType &getFunctionList()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2834 |  | 
 | 2835 |     <p> Returns the list of <a href="#Function"><tt>Function</tt></a>s.  This is | 
 | 2836 |     necessary to use when you need to update the list or perform a complex | 
 | 2837 |     action that doesn't have a forwarding method.</p> | 
 | 2838 |  | 
 | 2839 |     <p><!--  Global Variable --></p></li>  | 
| Chris Lattner | c75ff9a | 2002-10-01 23:17:09 +0000 | [diff] [blame] | 2840 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2841 |  | 
 | 2842 | <hr> | 
 | 2843 |  | 
| Chris Lattner | c75ff9a | 2002-10-01 23:17:09 +0000 | [diff] [blame] | 2844 | <ul> | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2845 |   <li><tt>Module::global_iterator</tt> - Typedef for global variable list iterator<br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2846 |  | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2847 |     <tt>Module::const_global_iterator</tt> - Typedef for const_iterator.<br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2848 |  | 
| Chris Lattner | 77d6924 | 2005-03-15 05:19:20 +0000 | [diff] [blame] | 2849 |     <tt>global_begin()</tt>, <tt>global_end()</tt> | 
| Chris Lattner | 89cc265 | 2005-03-15 04:48:32 +0000 | [diff] [blame] | 2850 |     <tt>global_size()</tt>, <tt>global_empty()</tt> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2851 |  | 
 | 2852 |     <p> These are forwarding methods that make it easy to access the contents of | 
 | 2853 |     a <tt>Module</tt> object's <a | 
 | 2854 |     href="#GlobalVariable"><tt>GlobalVariable</tt></a> list.</p></li> | 
 | 2855 |  | 
 | 2856 |   <li><tt>Module::GlobalListType &getGlobalList()</tt> | 
 | 2857 |  | 
 | 2858 |     <p>Returns the list of <a | 
 | 2859 |     href="#GlobalVariable"><tt>GlobalVariable</tt></a>s.  This is necessary to | 
 | 2860 |     use when you need to update the list or perform a complex action that | 
 | 2861 |     doesn't have a forwarding method.</p> | 
 | 2862 |  | 
 | 2863 |     <p><!--  Symbol table stuff --> </p></li> | 
| Chris Lattner | c75ff9a | 2002-10-01 23:17:09 +0000 | [diff] [blame] | 2864 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2865 |  | 
 | 2866 | <hr> | 
 | 2867 |  | 
 | 2868 | <ul> | 
 | 2869 |   <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt> | 
 | 2870 |  | 
 | 2871 |     <p>Return a reference to the <a href="#SymbolTable"><tt>SymbolTable</tt></a> | 
 | 2872 |     for this <tt>Module</tt>.</p> | 
 | 2873 |  | 
 | 2874 |     <p><!--  Convenience methods --></p></li> | 
 | 2875 | </ul> | 
 | 2876 |  | 
 | 2877 | <hr> | 
 | 2878 |  | 
 | 2879 | <ul> | 
 | 2880 |   <li><tt><a href="#Function">Function</a> *getFunction(const std::string | 
 | 2881 |   &Name, const <a href="#FunctionType">FunctionType</a> *Ty)</tt> | 
 | 2882 |  | 
 | 2883 |     <p>Look up the specified function in the <tt>Module</tt> <a | 
 | 2884 |     href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, return | 
 | 2885 |     <tt>null</tt>.</p></li> | 
 | 2886 |  | 
 | 2887 |   <li><tt><a href="#Function">Function</a> *getOrInsertFunction(const | 
 | 2888 |   std::string &Name, const <a href="#FunctionType">FunctionType</a> *T)</tt> | 
 | 2889 |  | 
 | 2890 |     <p>Look up the specified function in the <tt>Module</tt> <a | 
 | 2891 |     href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, add an | 
 | 2892 |     external declaration for the function and return it.</p></li> | 
 | 2893 |  | 
 | 2894 |   <li><tt>std::string getTypeName(const <a href="#Type">Type</a> *Ty)</tt> | 
 | 2895 |  | 
 | 2896 |     <p>If there is at least one entry in the <a | 
 | 2897 |     href="#SymbolTable"><tt>SymbolTable</tt></a> for the specified <a | 
 | 2898 |     href="#Type"><tt>Type</tt></a>, return it.  Otherwise return the empty | 
 | 2899 |     string.</p></li> | 
 | 2900 |  | 
 | 2901 |   <li><tt>bool addTypeName(const std::string &Name, const <a | 
 | 2902 |   href="#Type">Type</a> *Ty)</tt> | 
 | 2903 |  | 
 | 2904 |     <p>Insert an entry in the <a href="#SymbolTable"><tt>SymbolTable</tt></a> | 
 | 2905 |     mapping <tt>Name</tt> to <tt>Ty</tt>. If there is already an entry for this | 
 | 2906 |     name, true is returned and the <a | 
 | 2907 |     href="#SymbolTable"><tt>SymbolTable</tt></a> is not modified.</p></li> | 
 | 2908 | </ul> | 
 | 2909 |  | 
 | 2910 | </div> | 
 | 2911 |  | 
 | 2912 | <!-- ======================================================================= --> | 
 | 2913 | <div class="doc_subsection"> | 
 | 2914 |   <a name="Constant">The <tt>Constant</tt> class and subclasses</a> | 
 | 2915 | </div> | 
 | 2916 |  | 
 | 2917 | <div class="doc_text"> | 
 | 2918 |  | 
 | 2919 | <p>Constant represents a base class for different types of constants. It | 
| Reid Spencer | 53bfebc | 2007-01-12 03:36:33 +0000 | [diff] [blame] | 2920 | is subclassed by  ConstantInt, ConstantArray, etc. for representing  | 
| Reid Spencer | b83eb64 | 2006-10-20 07:07:24 +0000 | [diff] [blame] | 2921 | the various types of Constants.</p> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2922 |  | 
 | 2923 | </div> | 
 | 2924 |  | 
 | 2925 | <!-- _______________________________________________________________________ --> | 
 | 2926 | <div class="doc_subsubsection"> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2927 |   <a name="m_Constant">Important Public Methods</a> | 
 | 2928 | </div> | 
 | 2929 | <div class="doc_text"> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2930 | </div> | 
 | 2931 |  | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2932 | <!-- _______________________________________________________________________ --> | 
 | 2933 | <div class="doc_subsubsection">Important Subclasses of Constant </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2934 | <div class="doc_text"> | 
| Chris Lattner | c75ff9a | 2002-10-01 23:17:09 +0000 | [diff] [blame] | 2935 | <ul> | 
| Reid Spencer | 53bfebc | 2007-01-12 03:36:33 +0000 | [diff] [blame] | 2936 |   <li>ConstantInt : This subclass of Constant represents an integer constant of | 
 | 2937 |   any width, including boolean (1 bit integer). | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2938 |     <ul> | 
| Reid Spencer | b83eb64 | 2006-10-20 07:07:24 +0000 | [diff] [blame] | 2939 |       <li><tt>int64_t getSExtValue() const</tt>: Returns the underlying value of | 
 | 2940 |       this constant as a sign extended signed integer value.</li> | 
 | 2941 |       <li><tt>uint64_t getZExtValue() const</tt>: Returns the underlying value  | 
 | 2942 |       of this constant as a zero extended unsigned integer value.</li> | 
| Reid Spencer | 53bfebc | 2007-01-12 03:36:33 +0000 | [diff] [blame] | 2943 |       <li><tt>static ConstantInt* get(const Type *Ty, uint64_t Val)</tt>:  | 
 | 2944 |       Returns the ConstantInt object that represents the value provided by  | 
 | 2945 |       <tt>Val</tt> for integer type <tt>Ty</tt>.</li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2946 |     </ul> | 
 | 2947 |   </li> | 
 | 2948 |   <li>ConstantFP : This class represents a floating point constant. | 
 | 2949 |     <ul> | 
 | 2950 |       <li><tt>double getValue() const</tt>: Returns the underlying value of  | 
 | 2951 |       this constant. </li> | 
 | 2952 |     </ul> | 
 | 2953 |   </li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2954 |   <li>ConstantArray : This represents a constant array. | 
 | 2955 |     <ul> | 
 | 2956 |       <li><tt>const std::vector<Use> &getValues() const</tt>: Returns  | 
| Chris Lattner | 5836082 | 2005-01-17 00:12:04 +0000 | [diff] [blame] | 2957 |       a vector of component constants that makeup this array. </li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2958 |     </ul> | 
 | 2959 |   </li> | 
 | 2960 |   <li>ConstantStruct : This represents a constant struct. | 
 | 2961 |     <ul> | 
 | 2962 |       <li><tt>const std::vector<Use> &getValues() const</tt>: Returns  | 
| Chris Lattner | 5836082 | 2005-01-17 00:12:04 +0000 | [diff] [blame] | 2963 |       a vector of component constants that makeup this array. </li> | 
| Reid Spencer | fe8f4ff | 2004-11-01 09:02:53 +0000 | [diff] [blame] | 2964 |     </ul> | 
 | 2965 |   </li> | 
 | 2966 |   <li>GlobalValue : This represents either a global variable or a function. In  | 
 | 2967 |   either case, the value is a constant fixed address (after linking).  | 
 | 2968 |   </li> | 
| Chris Lattner | c75ff9a | 2002-10-01 23:17:09 +0000 | [diff] [blame] | 2969 | </ul> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2970 | </div> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2971 | <!-- ======================================================================= --> | 
 | 2972 | <div class="doc_subsection"> | 
 | 2973 |   <a name="Argument">The <tt>Argument</tt> class</a> | 
 | 2974 | </div> | 
 | 2975 |  | 
 | 2976 | <div class="doc_text"> | 
 | 2977 |  | 
 | 2978 | <p>This subclass of Value defines the interface for incoming formal | 
| Chris Lattner | 5836082 | 2005-01-17 00:12:04 +0000 | [diff] [blame] | 2979 | arguments to a function. A Function maintains a list of its formal | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2980 | arguments. An argument has a pointer to the parent Function.</p> | 
 | 2981 |  | 
 | 2982 | </div> | 
 | 2983 |  | 
| Chris Lattner | 9355b47 | 2002-09-06 02:50:58 +0000 | [diff] [blame] | 2984 | <!-- *********************************************************************** --> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2985 | <hr> | 
 | 2986 | <address> | 
 | 2987 |   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img | 
 | 2988 |   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a> | 
 | 2989 |   <a href="http://validator.w3.org/check/referer"><img | 
 | 2990 |   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a> | 
 | 2991 |  | 
 | 2992 |   <a href="mailto:dhurjati@cs.uiuc.edu">Dinakar Dhurjati</a> and | 
 | 2993 |   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> | 
| Reid Spencer | 05fe4b0 | 2006-03-14 05:39:39 +0000 | [diff] [blame] | 2994 |   <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br> | 
| Misha Brukman | 13fd15c | 2004-01-15 00:14:41 +0000 | [diff] [blame] | 2995 |   Last modified: $Date$ | 
 | 2996 | </address> | 
 | 2997 |  | 
| Chris Lattner | 261efe9 | 2003-11-25 01:02:51 +0000 | [diff] [blame] | 2998 | </body> | 
 | 2999 | </html> |