Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | "http://www.w3.org/TR/html4/strict.dtd"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 3 | <html> |
| 4 | <head> |
Misha Brukman | a97e6cb | 2004-07-01 15:33:24 +0000 | [diff] [blame] | 5 | <title>LLVM Alias Analysis Infrastructure</title> |
Misha Brukman | 6e4afd0 | 2004-01-15 19:04:12 +0000 | [diff] [blame] | 6 | <link rel="stylesheet" href="llvm.css" type="text/css"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 7 | </head> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 8 | <body> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 9 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 10 | <div class="doc_title"> |
Misha Brukman | a97e6cb | 2004-07-01 15:33:24 +0000 | [diff] [blame] | 11 | LLVM Alias Analysis Infrastructure |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 12 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 13 | |
| 14 | <ol> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 15 | <li><a href="#introduction">Introduction</a></li> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 16 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 17 | <li><a href="#overview"><tt>AliasAnalysis</tt> Class Overview</a> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 18 | <ul> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 19 | <li><a href="#pointers">Representation of Pointers</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 20 | <li><a href="#alias">The <tt>alias</tt> method</a></li> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 21 | <li><a href="#ModRefInfo">The <tt>getModRefInfo</tt> methods</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 22 | <li><a href="#OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a></li> |
| 23 | </ul> |
| 24 | </li> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 25 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 26 | <li><a href="#writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 27 | <ul> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 28 | <li><a href="#passsubclasses">Different Pass styles</a></li> |
| 29 | <li><a href="#requiredcalls">Required initialization calls</a></li> |
| 30 | <li><a href="#interfaces">Interfaces which may be specified</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 31 | <li><a href="#chaining"><tt>AliasAnalysis</tt> chaining behavior</a></li> |
| 32 | <li><a href="#updating">Updating analysis results for transformations</a></li> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 33 | <li><a href="#implefficiency">Efficiency Issues</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 34 | </ul> |
| 35 | </li> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 36 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 37 | <li><a href="#using">Using alias analysis results</a> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 38 | <ul> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 39 | <li><a href="#loadvn">Using the <tt>-load-vn</tt> Pass</a></li> |
| 40 | <li><a href="#ast">Using the <tt>AliasSetTracker</tt> class</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 41 | <li><a href="#direct">Using the <tt>AliasAnalysis</tt> interface directly</a></li> |
| 42 | </ul> |
| 43 | </li> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 44 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 45 | <li><a href="#exist">Existing alias analysis implementations and clients</a> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 46 | <ul> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 47 | <li><a href="#impls">Available <tt>AliasAnalysis</tt> implementations</a></li> |
| 48 | <li><a href="#aliasanalysis-xforms">Alias analysis driven transformations</a></li> |
Misha Brukman | a97e6cb | 2004-07-01 15:33:24 +0000 | [diff] [blame] | 49 | <li><a href="#aliasanalysis-debug">Clients for debugging and evaluation of |
| 50 | implementations</a></li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 51 | </ul> |
| 52 | </li> |
Owen Anderson | d8b4728 | 2007-10-02 00:44:20 +0000 | [diff] [blame] | 53 | <li><a href="#memdep">Memory Dependence Analysis</a></li> |
Misha Brukman | b215425 | 2003-10-23 02:29:42 +0000 | [diff] [blame] | 54 | </ol> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 55 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 56 | <div class="doc_author"> |
| 57 | <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 58 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 59 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 60 | <!-- *********************************************************************** --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 61 | <div class="doc_section"> |
| 62 | <a name="introduction">Introduction</a> |
| 63 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 64 | <!-- *********************************************************************** --> |
| 65 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 66 | <div class="doc_text"> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 67 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 68 | <p>Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt |
| 69 | to determine whether or not two pointers ever can point to the same object in |
| 70 | memory. There are many different algorithms for alias analysis and many |
| 71 | different ways of classifying them: flow-sensitive vs flow-insensitive, |
| 72 | context-sensitive vs context-insensitive, field-sensitive vs field-insensitive, |
| 73 | unification-based vs subset-based, etc. Traditionally, alias analyses respond |
Duncan Sands | 8036ca4 | 2007-03-30 12:22:09 +0000 | [diff] [blame] | 74 | to a query with a <a href="#MustMayNo">Must, May, or No</a> alias response, |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 75 | indicating that two pointers always point to the same object, might point to the |
| 76 | same object, or are known to never point to the same object.</p> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 77 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 78 | <p>The LLVM <a |
Reid Spencer | 05fe4b0 | 2006-03-14 05:39:39 +0000 | [diff] [blame] | 79 | href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 80 | class is the primary interface used by clients and implementations of alias |
| 81 | analyses in the LLVM system. This class is the common interface between clients |
| 82 | of alias analysis information and the implementations providing it, and is |
| 83 | designed to support a wide range of implementations and clients (but currently |
| 84 | all clients are assumed to be flow-insensitive). In addition to simple alias |
| 85 | analysis information, this class exposes Mod/Ref information from those |
| 86 | implementations which can provide it, allowing for powerful analyses and |
| 87 | transformations to work well together.</p> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 88 | |
| 89 | <p>This document contains information necessary to successfully implement this |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 90 | interface, use it, and to test both sides. It also explains some of the finer |
| 91 | points about what exactly results mean. If you feel that something is unclear |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 92 | or should be added, please <a href="mailto:sabre@nondot.org">let me |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 93 | know</a>.</p> |
| 94 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 95 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 96 | |
| 97 | <!-- *********************************************************************** --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 98 | <div class="doc_section"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 99 | <a name="overview"><tt>AliasAnalysis</tt> Class Overview</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 100 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 101 | <!-- *********************************************************************** --> |
| 102 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 103 | <div class="doc_text"> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 104 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 105 | <p>The <a |
Reid Spencer | 05fe4b0 | 2006-03-14 05:39:39 +0000 | [diff] [blame] | 106 | href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 107 | class defines the interface that the various alias analysis implementations |
| 108 | should support. This class exports two important enums: <tt>AliasResult</tt> |
| 109 | and <tt>ModRefResult</tt> which represent the result of an alias query or a |
| 110 | mod/ref query, respectively.</p> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 111 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 112 | <p>The <tt>AliasAnalysis</tt> interface exposes information about memory, |
| 113 | represented in several different ways. In particular, memory objects are |
| 114 | represented as a starting address and size, and function calls are represented |
| 115 | as the actual <tt>call</tt> or <tt>invoke</tt> instructions that performs the |
| 116 | call. The <tt>AliasAnalysis</tt> interface also exposes some helper methods |
| 117 | which allow you to get mod/ref information for arbitrary instructions.</p> |
Misha Brukman | 1f254d5 | 2003-11-21 22:30:25 +0000 | [diff] [blame] | 118 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 119 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 120 | |
| 121 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 122 | <div class="doc_subsection"> |
| 123 | <a name="pointers">Representation of Pointers</a> |
| 124 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 125 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 126 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 127 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 128 | <p>Most importantly, the <tt>AliasAnalysis</tt> class provides several methods |
| 129 | which are used to query whether or not two memory objects alias, whether |
| 130 | function calls can modify or read a memory object, etc. For all of these |
| 131 | queries, memory objects are represented as a pair of their starting address (a |
| 132 | symbolic LLVM <tt>Value*</tt>) and a static size.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 133 | |
| 134 | <p>Representing memory objects as a starting address and a size is critically |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 135 | important for correct Alias Analyses. For example, consider this (silly, but |
| 136 | possible) C code:</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 137 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 138 | <div class="doc_code"> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 139 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 140 | int i; |
| 141 | char C[2]; |
| 142 | char A[10]; |
| 143 | /* ... */ |
| 144 | for (i = 0; i != 10; ++i) { |
| 145 | C[0] = A[i]; /* One byte store */ |
| 146 | C[1] = A[9-i]; /* One byte store */ |
| 147 | } |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 148 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 149 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 150 | |
| 151 | <p>In this case, the <tt>basicaa</tt> pass will disambiguate the stores to |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 152 | <tt>C[0]</tt> and <tt>C[1]</tt> because they are accesses to two distinct |
| 153 | locations one byte apart, and the accesses are each one byte. In this case, the |
| 154 | LICM pass can use store motion to remove the stores from the loop. In |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 155 | constrast, the following code:</p> |
| 156 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 157 | <div class="doc_code"> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 158 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 159 | int i; |
| 160 | char C[2]; |
| 161 | char A[10]; |
| 162 | /* ... */ |
| 163 | for (i = 0; i != 10; ++i) { |
| 164 | ((short*)C)[0] = A[i]; /* Two byte store! */ |
| 165 | C[1] = A[9-i]; /* One byte store */ |
| 166 | } |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 167 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 168 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 169 | |
| 170 | <p>In this case, the two stores to C do alias each other, because the access to |
| 171 | the <tt>&C[0]</tt> element is a two byte access. If size information wasn't |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 172 | available in the query, even the first case would have to conservatively assume |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 173 | that the accesses alias.</p> |
| 174 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 175 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 176 | |
| 177 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 178 | <div class="doc_subsection"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 179 | <a name="alias">The <tt>alias</tt> method</a> |
| 180 | </div> |
| 181 | |
| 182 | <div class="doc_text"> |
| 183 | The <tt>alias</tt> method is the primary interface used to determine whether or |
| 184 | not two memory objects alias each other. It takes two memory objects as input |
| 185 | and returns MustAlias, MayAlias, or NoAlias as appropriate. |
| 186 | </div> |
| 187 | |
| 188 | <!-- _______________________________________________________________________ --> |
| 189 | <div class="doc_subsubsection"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 190 | <a name="MustMayNo">Must, May, and No Alias Responses</a> |
| 191 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 192 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 193 | <div class="doc_text"> |
Nick Lewycky | 01557ce | 2008-12-14 21:08:48 +0000 | [diff] [blame] | 194 | <p>The NoAlias response is used when the two pointers refer to distinct objects, |
Nick Lewycky | 78eb804 | 2008-12-18 02:15:05 +0000 | [diff] [blame^] | 195 | regardless of whether the pointers compare equal. For example, freed pointers |
| 196 | don't alias any pointers that were allocated afterwards. As a degenerate case, |
| 197 | pointers returned by malloc(0) have no bytes for an object, and are considered |
| 198 | NoAlias even when malloc returns the same pointer. The same rule applies to |
| 199 | NULL pointers.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 200 | |
Nick Lewycky | 01557ce | 2008-12-14 21:08:48 +0000 | [diff] [blame] | 201 | <p>The MayAlias response is used whenever the two pointers might refer to the |
| 202 | same object. If the two memory objects overlap, but do not start at the same |
| 203 | location, return MayAlias.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 204 | |
Nick Lewycky | 01557ce | 2008-12-14 21:08:48 +0000 | [diff] [blame] | 205 | <p>The MustAlias response may only be returned if the two memory objects are |
| 206 | guaranteed to always start at exactly the same location. A MustAlias response |
| 207 | implies that the pointers compare equal.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 208 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 209 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 210 | |
| 211 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 212 | <div class="doc_subsection"> |
| 213 | <a name="ModRefInfo">The <tt>getModRefInfo</tt> methods</a> |
| 214 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 215 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 216 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 217 | |
| 218 | <p>The <tt>getModRefInfo</tt> methods return information about whether the |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 219 | execution of an instruction can read or modify a memory location. Mod/Ref |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 220 | information is always conservative: if an instruction <b>might</b> read or write |
| 221 | a location, ModRef is returned.</p> |
| 222 | |
| 223 | <p>The <tt>AliasAnalysis</tt> class also provides a <tt>getModRefInfo</tt> |
| 224 | method for testing dependencies between function calls. This method takes two |
| 225 | call sites (CS1 & CS2), returns NoModRef if the two calls refer to disjoint |
| 226 | memory locations, Ref if CS1 reads memory written by CS2, Mod if CS1 writes to |
| 227 | memory read or written by CS2, or ModRef if CS1 might read or write memory |
| 228 | accessed by CS2. Note that this relation is not commutative. Clients that use |
| 229 | this method should be predicated on the <tt>hasNoModRefInfoForCalls()</tt> |
| 230 | method, which indicates whether or not an analysis can provide mod/ref |
| 231 | information for function call pairs (most can not). If this predicate is false, |
| 232 | the client shouldn't waste analysis time querying the <tt>getModRefInfo</tt> |
| 233 | method many times.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 234 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 235 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 236 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 237 | |
| 238 | <!-- ======================================================================= --> |
| 239 | <div class="doc_subsection"> |
| 240 | <a name="OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a> |
| 241 | </div> |
| 242 | |
| 243 | <div class="doc_text"> |
| 244 | |
| 245 | <p> |
| 246 | Several other tidbits of information are often collected by various alias |
| 247 | analysis implementations and can be put to good use by various clients. |
| 248 | </p> |
| 249 | |
| 250 | </div> |
| 251 | |
| 252 | <!-- _______________________________________________________________________ --> |
| 253 | <div class="doc_subsubsection"> |
| 254 | The <tt>getMustAliases</tt> method |
| 255 | </div> |
| 256 | |
| 257 | <div class="doc_text"> |
| 258 | |
| 259 | <p>The <tt>getMustAliases</tt> method returns all values that are known to |
| 260 | always must alias a pointer. This information can be provided in some cases for |
| 261 | important objects like the null pointer and global values. Knowing that a |
| 262 | pointer always points to a particular function allows indirect calls to be |
| 263 | turned into direct calls, for example.</p> |
| 264 | |
| 265 | </div> |
| 266 | |
| 267 | <!-- _______________________________________________________________________ --> |
| 268 | <div class="doc_subsubsection"> |
| 269 | The <tt>pointsToConstantMemory</tt> method |
| 270 | </div> |
| 271 | |
| 272 | <div class="doc_text"> |
| 273 | |
| 274 | <p>The <tt>pointsToConstantMemory</tt> method returns true if and only if the |
| 275 | analysis can prove that the pointer only points to unchanging memory locations |
| 276 | (functions, constant global variables, and the null pointer). This information |
| 277 | can be used to refine mod/ref information: it is impossible for an unchanging |
| 278 | memory location to be modified.</p> |
| 279 | |
| 280 | </div> |
| 281 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 282 | <!-- _______________________________________________________________________ --> |
| 283 | <div class="doc_subsubsection"> |
| 284 | <a name="simplemodref">The <tt>doesNotAccessMemory</tt> and |
| 285 | <tt>onlyReadsMemory</tt> methods</a> |
| 286 | </div> |
| 287 | |
| 288 | <div class="doc_text"> |
| 289 | |
| 290 | <p>These methods are used to provide very simple mod/ref information for |
| 291 | function calls. The <tt>doesNotAccessMemory</tt> method returns true for a |
| 292 | function if the analysis can prove that the function never reads or writes to |
| 293 | memory, or if the function only reads from constant memory. Functions with this |
| 294 | property are side-effect free and only depend on their input arguments, allowing |
| 295 | them to be eliminated if they form common subexpressions or be hoisted out of |
| 296 | loops. Many common functions behave this way (e.g., <tt>sin</tt> and |
| 297 | <tt>cos</tt>) but many others do not (e.g., <tt>acos</tt>, which modifies the |
| 298 | <tt>errno</tt> variable).</p> |
| 299 | |
| 300 | <p>The <tt>onlyReadsMemory</tt> method returns true for a function if analysis |
| 301 | can prove that (at most) the function only reads from non-volatile memory. |
| 302 | Functions with this property are side-effect free, only depending on their input |
| 303 | arguments and the state of memory when they are called. This property allows |
| 304 | calls to these functions to be eliminated and moved around, as long as there is |
| 305 | no store instruction that changes the contents of memory. Note that all |
| 306 | functions that satisfy the <tt>doesNotAccessMemory</tt> method also satisfies |
| 307 | <tt>onlyReadsMemory</tt>.</p> |
| 308 | |
| 309 | </div> |
| 310 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 311 | <!-- *********************************************************************** --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 312 | <div class="doc_section"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 313 | <a name="writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 314 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 315 | <!-- *********************************************************************** --> |
| 316 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 317 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 318 | |
| 319 | <p>Writing a new alias analysis implementation for LLVM is quite |
| 320 | straight-forward. There are already several implementations that you can use |
| 321 | for examples, and the following information should help fill in any details. |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 322 | For a examples, take a look at the <a href="#impls">various alias analysis |
| 323 | implementations</a> included with LLVM.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 324 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 325 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 326 | |
| 327 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 328 | <div class="doc_subsection"> |
| 329 | <a name="passsubclasses">Different Pass styles</a> |
| 330 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 331 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 332 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 333 | |
| 334 | <p>The first step to determining what type of <a |
| 335 | href="WritingAnLLVMPass.html">LLVM pass</a> you need to use for your Alias |
| 336 | Analysis. As is the case with most other analyses and transformations, the |
| 337 | answer should be fairly obvious from what type of problem you are trying to |
| 338 | solve:</p> |
| 339 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 340 | <ol> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 341 | <li>If you require interprocedural analysis, it should be a |
| 342 | <tt>Pass</tt>.</li> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 343 | <li>If you are a function-local analysis, subclass <tt>FunctionPass</tt>.</li> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 344 | <li>If you don't need to look at the program at all, subclass |
| 345 | <tt>ImmutablePass</tt>.</li> |
| 346 | </ol> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 347 | |
| 348 | <p>In addition to the pass that you subclass, you should also inherit from the |
Misha Brukman | 700fd49 | 2003-05-07 21:47:16 +0000 | [diff] [blame] | 349 | <tt>AliasAnalysis</tt> interface, of course, and use the |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 350 | <tt>RegisterAnalysisGroup</tt> template to register as an implementation of |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 351 | <tt>AliasAnalysis</tt>.</p> |
| 352 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 353 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 354 | |
| 355 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 356 | <div class="doc_subsection"> |
| 357 | <a name="requiredcalls">Required initialization calls</a> |
| 358 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 359 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 360 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 361 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 362 | <p>Your subclass of <tt>AliasAnalysis</tt> is required to invoke two methods on |
| 363 | the <tt>AliasAnalysis</tt> base class: <tt>getAnalysisUsage</tt> and |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 364 | <tt>InitializeAliasAnalysis</tt>. In particular, your implementation of |
| 365 | <tt>getAnalysisUsage</tt> should explicitly call into the |
| 366 | <tt>AliasAnalysis::getAnalysisUsage</tt> method in addition to doing any |
| 367 | declaring any pass dependencies your pass has. Thus you should have something |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 368 | like this:</p> |
| 369 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 370 | <div class="doc_code"> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 371 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 372 | void getAnalysisUsage(AnalysisUsage &AU) const { |
| 373 | AliasAnalysis::getAnalysisUsage(AU); |
| 374 | <i>// declare your dependencies here.</i> |
| 375 | } |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 376 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 377 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 378 | |
| 379 | <p>Additionally, your must invoke the <tt>InitializeAliasAnalysis</tt> method |
| 380 | from your analysis run method (<tt>run</tt> for a <tt>Pass</tt>, |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 381 | <tt>runOnFunction</tt> for a <tt>FunctionPass</tt>, or <tt>InitializePass</tt> |
| 382 | for an <tt>ImmutablePass</tt>). For example (as part of a <tt>Pass</tt>):</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 383 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 384 | <div class="doc_code"> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 385 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 386 | bool run(Module &M) { |
| 387 | InitializeAliasAnalysis(this); |
| 388 | <i>// Perform analysis here...</i> |
| 389 | return false; |
| 390 | } |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 391 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 392 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 393 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 394 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 395 | |
| 396 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 397 | <div class="doc_subsection"> |
| 398 | <a name="interfaces">Interfaces which may be specified</a> |
| 399 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 400 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 401 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 402 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 403 | <p>All of the <a |
| 404 | href="/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a> |
| 405 | virtual methods default to providing <a href="#chaining">chaining</a> to another |
| 406 | alias analysis implementation, which ends up returning conservatively correct |
| 407 | information (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 408 | respectively). Depending on the capabilities of the analysis you are |
| 409 | implementing, you just override the interfaces you can improve.</p> |
| 410 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 411 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 412 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 413 | |
| 414 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 415 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 416 | <div class="doc_subsection"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 417 | <a name="chaining"><tt>AliasAnalysis</tt> chaining behavior</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 418 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 419 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 420 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 421 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 422 | <p>With only two special exceptions (the <tt><a |
| 423 | href="#basic-aa">basicaa</a></tt> and <a href="#no-aa"><tt>no-aa</tt></a> |
| 424 | passes) every alias analysis pass chains to another alias analysis |
| 425 | implementation (for example, the user can specify "<tt>-basicaa -ds-aa |
| 426 | -anders-aa -licm</tt>" to get the maximum benefit from the three alias |
| 427 | analyses). The alias analysis class automatically takes care of most of this |
| 428 | for methods that you don't override. For methods that you do override, in code |
| 429 | paths that return a conservative MayAlias or Mod/Ref result, simply return |
| 430 | whatever the superclass computes. For example:</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 431 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 432 | <div class="doc_code"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 433 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 434 | AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size, |
| 435 | const Value *V2, unsigned V2Size) { |
| 436 | if (...) |
| 437 | return NoAlias; |
| 438 | ... |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 439 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 440 | <i>// Couldn't determine a must or no-alias result.</i> |
| 441 | return AliasAnalysis::alias(V1, V1Size, V2, V2Size); |
| 442 | } |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 443 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 444 | </div> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 445 | |
| 446 | <p>In addition to analysis queries, you must make sure to unconditionally pass |
| 447 | LLVM <a href="#updating">update notification</a> methods to the superclass as |
| 448 | well if you override them, which allows all alias analyses in a change to be |
| 449 | updated.</p> |
| 450 | |
| 451 | </div> |
| 452 | |
| 453 | |
| 454 | <!-- ======================================================================= --> |
| 455 | <div class="doc_subsection"> |
| 456 | <a name="updating">Updating analysis results for transformations</a> |
| 457 | </div> |
| 458 | |
| 459 | <div class="doc_text"> |
| 460 | <p> |
| 461 | Alias analysis information is initially computed for a static snapshot of the |
| 462 | program, but clients will use this information to make transformations to the |
| 463 | code. All but the most trivial forms of alias analysis will need to have their |
| 464 | analysis results updated to reflect the changes made by these transformations. |
| 465 | </p> |
| 466 | |
| 467 | <p> |
| 468 | The <tt>AliasAnalysis</tt> interface exposes two methods which are used to |
| 469 | communicate program changes from the clients to the analysis implementations. |
| 470 | Various alias analysis implementations should use these methods to ensure that |
| 471 | their internal data structures are kept up-to-date as the program changes (for |
| 472 | example, when an instruction is deleted), and clients of alias analysis must be |
| 473 | sure to call these interfaces appropriately. |
| 474 | </p> |
| 475 | </div> |
| 476 | |
| 477 | <!-- _______________________________________________________________________ --> |
| 478 | <div class="doc_subsubsection">The <tt>deleteValue</tt> method</div> |
| 479 | |
| 480 | <div class="doc_text"> |
| 481 | The <tt>deleteValue</tt> method is called by transformations when they remove an |
| 482 | instruction or any other value from the program (including values that do not |
| 483 | use pointers). Typically alias analyses keep data structures that have entries |
| 484 | for each value in the program. When this method is called, they should remove |
| 485 | any entries for the specified value, if they exist. |
| 486 | </div> |
| 487 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 488 | <!-- _______________________________________________________________________ --> |
| 489 | <div class="doc_subsubsection">The <tt>copyValue</tt> method</div> |
| 490 | |
| 491 | <div class="doc_text"> |
| 492 | The <tt>copyValue</tt> method is used when a new value is introduced into the |
| 493 | program. There is no way to introduce a value into the program that did not |
| 494 | exist before (this doesn't make sense for a safe compiler transformation), so |
| 495 | this is the only way to introduce a new value. This method indicates that the |
| 496 | new value has exactly the same properties as the value being copied. |
| 497 | </div> |
| 498 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 499 | <!-- _______________________________________________________________________ --> |
| 500 | <div class="doc_subsubsection">The <tt>replaceWithNewValue</tt> method</div> |
| 501 | |
| 502 | <div class="doc_text"> |
| 503 | This method is a simple helper method that is provided to make clients easier to |
| 504 | use. It is implemented by copying the old analysis information to the new |
| 505 | value, then deleting the old value. This method cannot be overridden by alias |
| 506 | analysis implementations. |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 507 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 508 | |
| 509 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 510 | <div class="doc_subsection"> |
| 511 | <a name="implefficiency">Efficiency Issues</a> |
| 512 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 513 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 514 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 515 | |
| 516 | <p>From the LLVM perspective, the only thing you need to do to provide an |
| 517 | efficient alias analysis is to make sure that alias analysis <b>queries</b> are |
| 518 | serviced quickly. The actual calculation of the alias analysis results (the |
| 519 | "run" method) is only performed once, but many (perhaps duplicate) queries may |
| 520 | be performed. Because of this, try to move as much computation to the run |
| 521 | method as possible (within reason).</p> |
| 522 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 523 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 524 | |
| 525 | <!-- *********************************************************************** --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 526 | <div class="doc_section"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 527 | <a name="using">Using alias analysis results</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 528 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 529 | <!-- *********************************************************************** --> |
| 530 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 531 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 532 | |
| 533 | <p>There are several different ways to use alias analysis results. In order of |
| 534 | preference, these are...</p> |
| 535 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 536 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 537 | |
| 538 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 539 | <div class="doc_subsection"> |
| 540 | <a name="loadvn">Using the <tt>-load-vn</tt> Pass</a> |
| 541 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 542 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 543 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 544 | |
| 545 | <p>The <tt>load-vn</tt> pass uses alias analysis to provide value numbering |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 546 | information for <tt>load</tt> instructions and pointer values. If your analysis |
| 547 | or transformation can be modeled in a form that uses value numbering |
| 548 | information, you don't have to do anything special to handle load instructions: |
| 549 | just use the <tt>load-vn</tt> pass, which uses alias analysis.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 550 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 551 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 552 | |
| 553 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 554 | <div class="doc_subsection"> |
| 555 | <a name="ast">Using the <tt>AliasSetTracker</tt> class</a> |
| 556 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 557 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 558 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 559 | |
| 560 | <p>Many transformations need information about alias <b>sets</b> that are active |
| 561 | in some scope, rather than information about pairwise aliasing. The <tt><a |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 562 | href="/doxygen/classllvm_1_1AliasSetTracker.html">AliasSetTracker</a></tt> class |
| 563 | is used to efficiently build these Alias Sets from the pairwise alias analysis |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 564 | information provided by the <tt>AliasAnalysis</tt> interface.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 565 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 566 | <p>First you initialize the AliasSetTracker by using the "<tt>add</tt>" methods |
| 567 | to add information about various potentially aliasing instructions in the scope |
| 568 | you are interested in. Once all of the alias sets are completed, your pass |
| 569 | should simply iterate through the constructed alias sets, using the |
| 570 | <tt>AliasSetTracker</tt> <tt>begin()</tt>/<tt>end()</tt> methods.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 571 | |
| 572 | <p>The <tt>AliasSet</tt>s formed by the <tt>AliasSetTracker</tt> are guaranteed |
Chris Lattner | 539ca70 | 2003-12-19 08:43:07 +0000 | [diff] [blame] | 573 | to be disjoint, calculate mod/ref information and volatility for the set, and |
| 574 | keep track of whether or not all of the pointers in the set are Must aliases. |
| 575 | The AliasSetTracker also makes sure that sets are properly folded due to call |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 576 | instructions, and can provide a list of pointers in each set.</p> |
| 577 | |
| 578 | <p>As an example user of this, the <a href="/doxygen/structLICM.html">Loop |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 579 | Invariant Code Motion</a> pass uses <tt>AliasSetTracker</tt>s to calculate alias |
| 580 | sets for each loop nest. If an <tt>AliasSet</tt> in a loop is not modified, |
| 581 | then all load instructions from that set may be hoisted out of the loop. If any |
| 582 | alias sets are stored to <b>and</b> are must alias sets, then the stores may be |
| 583 | sunk to outside of the loop, promoting the memory location to a register for the |
| 584 | duration of the loop nest. Both of these transformations only apply if the |
| 585 | pointer argument is loop-invariant.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 586 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 587 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 588 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 589 | <!-- _______________________________________________________________________ --> |
Chris Lattner | 539ca70 | 2003-12-19 08:43:07 +0000 | [diff] [blame] | 590 | <div class="doc_subsubsection"> |
| 591 | The AliasSetTracker implementation |
| 592 | </div> |
| 593 | |
| 594 | <div class="doc_text"> |
| 595 | |
| 596 | <p>The AliasSetTracker class is implemented to be as efficient as possible. It |
| 597 | uses the union-find algorithm to efficiently merge AliasSets when a pointer is |
| 598 | inserted into the AliasSetTracker that aliases multiple sets. The primary data |
| 599 | structure is a hash table mapping pointers to the AliasSet they are in.</p> |
| 600 | |
| 601 | <p>The AliasSetTracker class must maintain a list of all of the LLVM Value*'s |
| 602 | that are in each AliasSet. Since the hash table already has entries for each |
| 603 | LLVM Value* of interest, the AliasesSets thread the linked list through these |
| 604 | hash-table nodes to avoid having to allocate memory unnecessarily, and to make |
| 605 | merging alias sets extremely efficient (the linked list merge is constant time). |
| 606 | </p> |
| 607 | |
| 608 | <p>You shouldn't need to understand these details if you are just a client of |
| 609 | the AliasSetTracker, but if you look at the code, hopefully this brief |
| 610 | description will help make sense of why things are designed the way they |
| 611 | are.</p> |
| 612 | |
| 613 | </div> |
| 614 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 615 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 616 | <div class="doc_subsection"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 617 | <a name="direct">Using the <tt>AliasAnalysis</tt> interface directly</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 618 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 619 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 620 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 621 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 622 | <p>If neither of these utility class are what your pass needs, you should use |
| 623 | the interfaces exposed by the <tt>AliasAnalysis</tt> class directly. Try to use |
| 624 | the higher-level methods when possible (e.g., use mod/ref information instead of |
| 625 | the <a href="#alias"><tt>alias</tt></a> method directly if possible) to get the |
| 626 | best precision and efficiency.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 627 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 628 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 629 | |
| 630 | <!-- *********************************************************************** --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 631 | <div class="doc_section"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 632 | <a name="exist">Existing alias analysis implementations and clients</a> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 633 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 634 | <!-- *********************************************************************** --> |
| 635 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 636 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 637 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 638 | <p>If you're going to be working with the LLVM alias analysis infrastructure, |
| 639 | you should know what clients and implementations of alias analysis are |
| 640 | available. In particular, if you are implementing an alias analysis, you should |
| 641 | be aware of the <a href="#aliasanalysis-debug">the clients</a> that are useful |
| 642 | for monitoring and evaluating different implementations.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 643 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 644 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 645 | |
| 646 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 647 | <div class="doc_subsection"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 648 | <a name="impls">Available <tt>AliasAnalysis</tt> implementations</a> |
| 649 | </div> |
| 650 | |
| 651 | <div class="doc_text"> |
| 652 | |
| 653 | <p>This section lists the various implementations of the <tt>AliasAnalysis</tt> |
| 654 | interface. With the exception of the <a href="#no-aa"><tt>-no-aa</tt></a> and |
| 655 | <a href="#basic-aa"><tt>-basicaa</tt></a> implementations, all of these <a |
Chris Lattner | fcd3725 | 2004-06-21 22:52:48 +0000 | [diff] [blame] | 656 | href="#chaining">chain</a> to other alias analysis implementations.</p> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 657 | |
| 658 | </div> |
| 659 | |
| 660 | <!-- _______________________________________________________________________ --> |
| 661 | <div class="doc_subsubsection"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 662 | <a name="no-aa">The <tt>-no-aa</tt> pass</a> |
| 663 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 664 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 665 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 666 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 667 | <p>The <tt>-no-aa</tt> pass is just like what it sounds: an alias analysis that |
| 668 | never returns any useful information. This pass can be useful if you think that |
| 669 | alias analysis is doing something wrong and are trying to narrow down a |
| 670 | problem.</p> |
| 671 | |
| 672 | </div> |
| 673 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 674 | <!-- _______________________________________________________________________ --> |
| 675 | <div class="doc_subsubsection"> |
| 676 | <a name="basic-aa">The <tt>-basicaa</tt> pass</a> |
| 677 | </div> |
| 678 | |
| 679 | <div class="doc_text"> |
| 680 | |
| 681 | <p>The <tt>-basicaa</tt> pass is the default LLVM alias analysis. It is an |
| 682 | aggressive local analysis that "knows" many important facts:</p> |
| 683 | |
| 684 | <ul> |
| 685 | <li>Distinct globals, stack allocations, and heap allocations can never |
| 686 | alias.</li> |
| 687 | <li>Globals, stack allocations, and heap allocations never alias the null |
| 688 | pointer.</li> |
| 689 | <li>Different fields of a structure do not alias.</li> |
| 690 | <li>Indexes into arrays with statically differing subscripts cannot alias.</li> |
| 691 | <li>Many common standard C library functions <a |
| 692 | href="#simplemodref">never access memory or only read memory</a>.</li> |
| 693 | <li>Pointers that obviously point to constant globals |
| 694 | "<tt>pointToConstantMemory</tt>".</li> |
| 695 | <li>Function calls can not modify or references stack allocations if they never |
| 696 | escape from the function that allocates them (a common case for automatic |
| 697 | arrays).</li> |
| 698 | </ul> |
| 699 | |
| 700 | </div> |
| 701 | |
Chris Lattner | 100a4f8 | 2004-06-28 19:19:47 +0000 | [diff] [blame] | 702 | <!-- _______________________________________________________________________ --> |
| 703 | <div class="doc_subsubsection"> |
| 704 | <a name="globalsmodref">The <tt>-globalsmodref-aa</tt> pass</a> |
| 705 | </div> |
| 706 | |
| 707 | <div class="doc_text"> |
| 708 | |
| 709 | <p>This pass implements a simple context-sensitive mod/ref and alias analysis |
Chris Lattner | ccb354b | 2004-07-27 07:50:07 +0000 | [diff] [blame] | 710 | for internal global variables that don't "have their address taken". If a |
| 711 | global does not have its address taken, the pass knows that no pointers alias |
| 712 | the global. This pass also keeps track of functions that it knows never access |
| 713 | memory or never read memory. This allows certain optimizations (e.g. GCSE) to |
| 714 | eliminate call instructions entirely. |
Chris Lattner | 100a4f8 | 2004-06-28 19:19:47 +0000 | [diff] [blame] | 715 | </p> |
| 716 | |
| 717 | <p>The real power of this pass is that it provides context-sensitive mod/ref |
| 718 | information for call instructions. This allows the optimizer to know that |
| 719 | calls to a function do not clobber or read the value of the global, allowing |
| 720 | loads and stores to be eliminated.</p> |
| 721 | |
| 722 | <p>Note that this pass is somewhat limited in its scope (only support |
| 723 | non-address taken globals), but is very quick analysis.</p> |
| 724 | </div> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 725 | |
| 726 | <!-- _______________________________________________________________________ --> |
| 727 | <div class="doc_subsubsection"> |
| 728 | <a name="anders-aa">The <tt>-anders-aa</tt> pass</a> |
| 729 | </div> |
| 730 | |
| 731 | <div class="doc_text"> |
| 732 | |
| 733 | <p>The <tt>-anders-aa</tt> pass implements the well-known "Andersen's algorithm" |
| 734 | for interprocedural alias analysis. This algorithm is a subset-based, |
| 735 | flow-insensitive, context-insensitive, and field-insensitive alias analysis that |
| 736 | is widely believed to be fairly precise. Unfortunately, this algorithm is also |
| 737 | O(N<sup>3</sup>). The LLVM implementation currently does not implement any of |
| 738 | the refinements (such as "online cycle elimination" or "offline variable |
| 739 | substitution") to improve its efficiency, so it can be quite slow in common |
| 740 | cases. |
| 741 | </p> |
| 742 | |
| 743 | </div> |
| 744 | |
| 745 | <!-- _______________________________________________________________________ --> |
| 746 | <div class="doc_subsubsection"> |
| 747 | <a name="steens-aa">The <tt>-steens-aa</tt> pass</a> |
| 748 | </div> |
| 749 | |
| 750 | <div class="doc_text"> |
| 751 | |
| 752 | <p>The <tt>-steens-aa</tt> pass implements a variation on the well-known |
| 753 | "Steensgaard's algorithm" for interprocedural alias analysis. Steensgaard's |
| 754 | algorithm is a unification-based, flow-insensitive, context-insensitive, and |
| 755 | field-insensitive alias analysis that is also very scalable (effectively linear |
| 756 | time).</p> |
| 757 | |
| 758 | <p>The LLVM <tt>-steens-aa</tt> pass implements a "speculatively |
| 759 | field-<b>sensitive</b>" version of Steensgaard's algorithm using the Data |
| 760 | Structure Analysis framework. This gives it substantially more precision than |
| 761 | the standard algorithm while maintaining excellent analysis scalability.</p> |
| 762 | |
Chris Lattner | d6e0dd1 | 2007-07-03 04:41:50 +0000 | [diff] [blame] | 763 | <p>Note that <tt>-steens-aa</tt> is available in the optional "poolalloc" |
| 764 | module, it is not part of the LLVM core.</p> |
| 765 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 766 | </div> |
| 767 | |
| 768 | <!-- _______________________________________________________________________ --> |
| 769 | <div class="doc_subsubsection"> |
| 770 | <a name="ds-aa">The <tt>-ds-aa</tt> pass</a> |
| 771 | </div> |
| 772 | |
| 773 | <div class="doc_text"> |
| 774 | |
| 775 | <p>The <tt>-ds-aa</tt> pass implements the full Data Structure Analysis |
| 776 | algorithm. Data Structure Analysis is a modular unification-based, |
| 777 | flow-insensitive, context-<b>sensitive</b>, and speculatively |
| 778 | field-<b>sensitive</b> alias analysis that is also quite scalable, usually at |
| 779 | O(n*log(n)).</p> |
| 780 | |
| 781 | <p>This algorithm is capable of responding to a full variety of alias analysis |
| 782 | queries, and can provide context-sensitive mod/ref information as well. The |
| 783 | only major facility not implemented so far is support for must-alias |
| 784 | information.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 785 | |
Chris Lattner | d6e0dd1 | 2007-07-03 04:41:50 +0000 | [diff] [blame] | 786 | <p>Note that <tt>-ds-aa</tt> is available in the optional "poolalloc" |
| 787 | module, it is not part of the LLVM core.</p> |
| 788 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 789 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 790 | |
| 791 | |
| 792 | <!-- ======================================================================= --> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 793 | <div class="doc_subsection"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 794 | <a name="aliasanalysis-xforms">Alias analysis driven transformations</a> |
| 795 | </div> |
| 796 | |
| 797 | <div class="doc_text"> |
| 798 | LLVM includes several alias-analysis driven transformations which can be used |
| 799 | with any of the implementations above. |
| 800 | </div> |
| 801 | |
| 802 | <!-- _______________________________________________________________________ --> |
| 803 | <div class="doc_subsubsection"> |
| 804 | <a name="adce">The <tt>-adce</tt> pass</a> |
| 805 | </div> |
| 806 | |
| 807 | <div class="doc_text"> |
| 808 | |
| 809 | <p>The <tt>-adce</tt> pass, which implements Aggressive Dead Code Elimination |
| 810 | uses the <tt>AliasAnalysis</tt> interface to delete calls to functions that do |
| 811 | not have side-effects and are not used.</p> |
| 812 | |
| 813 | </div> |
| 814 | |
| 815 | |
| 816 | <!-- _______________________________________________________________________ --> |
| 817 | <div class="doc_subsubsection"> |
| 818 | <a name="licm">The <tt>-licm</tt> pass</a> |
| 819 | </div> |
| 820 | |
| 821 | <div class="doc_text"> |
| 822 | |
| 823 | <p>The <tt>-licm</tt> pass implements various Loop Invariant Code Motion related |
| 824 | transformations. It uses the <tt>AliasAnalysis</tt> interface for several |
| 825 | different transformations:</p> |
| 826 | |
| 827 | <ul> |
| 828 | <li>It uses mod/ref information to hoist or sink load instructions out of loops |
| 829 | if there are no instructions in the loop that modifies the memory loaded.</li> |
| 830 | |
| 831 | <li>It uses mod/ref information to hoist function calls out of loops that do not |
| 832 | write to memory and are loop-invariant.</li> |
| 833 | |
| 834 | <li>If uses alias information to promote memory objects that are loaded and |
| 835 | stored to in loops to live in a register instead. It can do this if there are |
| 836 | no may aliases to the loaded/stored memory location.</li> |
| 837 | </ul> |
| 838 | |
| 839 | </div> |
| 840 | |
| 841 | <!-- _______________________________________________________________________ --> |
| 842 | <div class="doc_subsubsection"> |
| 843 | <a name="argpromotion">The <tt>-argpromotion</tt> pass</a> |
| 844 | </div> |
| 845 | |
| 846 | <div class="doc_text"> |
| 847 | <p> |
| 848 | The <tt>-argpromotion</tt> pass promotes by-reference arguments to be passed in |
| 849 | by-value instead. In particular, if pointer arguments are only loaded from it |
| 850 | passes in the value loaded instead of the address to the function. This pass |
| 851 | uses alias information to make sure that the value loaded from the argument |
| 852 | pointer is not modified between the entry of the function and any load of the |
| 853 | pointer.</p> |
| 854 | </div> |
| 855 | |
| 856 | <!-- _______________________________________________________________________ --> |
| 857 | <div class="doc_subsubsection"> |
| 858 | <a name="gcseloadvn">The <tt>-load-vn</tt> & <tt>-gcse</tt> passes</a> |
| 859 | </div> |
| 860 | |
| 861 | <div class="doc_text"> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 862 | |
| 863 | <p>The <tt>-load-vn</tt> pass uses alias analysis to "<a href="#loadvn">value |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 864 | number</a>" loads and pointers values, which is used by the GCSE pass to |
| 865 | eliminate instructions. The <tt>-load-vn</tt> pass relies on alias information |
| 866 | and must-alias information. This combination of passes can make the following |
| 867 | transformations:</p> |
| 868 | |
| 869 | <ul> |
| 870 | <li>Redundant load instructions are eliminated.</li> |
| 871 | <li>Load instructions that follow a store to the same location are replaced with |
| 872 | the stored value ("store forwarding").</li> |
| 873 | <li>Pointers values (e.g. formal arguments) that must-alias simpler expressions |
| 874 | (e.g. global variables or the null pointer) are replaced. Note that this |
| 875 | implements transformations like "virtual method resolution", turning indirect |
| 876 | calls into direct calls.</li> |
| 877 | </ul> |
| 878 | |
| 879 | </div> |
| 880 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 881 | <!-- ======================================================================= --> |
| 882 | <div class="doc_subsection"> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 883 | <a name="aliasanalysis-debug">Clients for debugging and evaluation of |
| 884 | implementations</a> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 885 | </div> |
| 886 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 887 | <div class="doc_text"> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 888 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 889 | <p>These passes are useful for evaluating the various alias analysis |
| 890 | implementations. You can use them with commands like '<tt>opt -anders-aa -ds-aa |
| 891 | -aa-eval foo.bc -disable-output -stats</tt>'.</p> |
| 892 | |
| 893 | </div> |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 894 | |
| 895 | <!-- _______________________________________________________________________ --> |
| 896 | <div class="doc_subsubsection"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 897 | <a name="print-alias-sets">The <tt>-print-alias-sets</tt> pass</a> |
| 898 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 899 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 900 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 901 | |
| 902 | <p>The <tt>-print-alias-sets</tt> pass is exposed as part of the |
Chris Lattner | 05d5c9d | 2006-01-03 06:04:48 +0000 | [diff] [blame] | 903 | <tt>opt</tt> tool to print out the Alias Sets formed by the <a |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 904 | href="#ast"><tt>AliasSetTracker</tt></a> class. This is useful if you're using |
Chris Lattner | 05d5c9d | 2006-01-03 06:04:48 +0000 | [diff] [blame] | 905 | the <tt>AliasSetTracker</tt> class. To use it, use something like:</p> |
| 906 | |
| 907 | <div class="doc_code"> |
| 908 | <pre> |
| 909 | % opt -ds-aa -print-alias-sets -disable-output |
| 910 | </pre> |
| 911 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 912 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 913 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 914 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 915 | |
| 916 | <!-- _______________________________________________________________________ --> |
| 917 | <div class="doc_subsubsection"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 918 | <a name="count-aa">The <tt>-count-aa</tt> pass</a> |
| 919 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 920 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 921 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 922 | |
| 923 | <p>The <tt>-count-aa</tt> pass is useful to see how many queries a particular |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 924 | pass is making and what responses are returned by the alias analysis. As an |
| 925 | example,</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 926 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 927 | <div class="doc_code"> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 928 | <pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 929 | % opt -basicaa -count-aa -ds-aa -count-aa -licm |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 930 | </pre> |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 931 | </div> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 932 | |
Misha Brukman | 294611a | 2004-07-28 22:18:33 +0000 | [diff] [blame] | 933 | <p>will print out how many queries (and what responses are returned) by the |
| 934 | <tt>-licm</tt> pass (of the <tt>-ds-aa</tt> pass) and how many queries are made |
| 935 | of the <tt>-basicaa</tt> pass by the <tt>-ds-aa</tt> pass. This can be useful |
| 936 | when debugging a transformation or an alias analysis implementation.</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 937 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 938 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 939 | |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 940 | <!-- _______________________________________________________________________ --> |
| 941 | <div class="doc_subsubsection"> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 942 | <a name="aa-eval">The <tt>-aa-eval</tt> pass</a> |
| 943 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 944 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 945 | <div class="doc_text"> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 946 | |
| 947 | <p>The <tt>-aa-eval</tt> pass simply iterates through all pairs of pointers in a |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 948 | function and asks an alias analysis whether or not the pointers alias. This |
| 949 | gives an indication of the precision of the alias analysis. Statistics are |
Chris Lattner | ccc8065 | 2004-05-23 21:04:01 +0000 | [diff] [blame] | 950 | printed indicating the percent of no/may/must aliases found (a more precise |
| 951 | algorithm will have a lower number of may aliases).</p> |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 952 | |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 953 | </div> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 954 | |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 955 | <!-- *********************************************************************** --> |
Owen Anderson | 5a726b8 | 2007-10-02 00:43:25 +0000 | [diff] [blame] | 956 | <div class="doc_section"> |
| 957 | <a name="memdep">Memory Dependence Analysis</a> |
| 958 | </div> |
| 959 | <!-- *********************************************************************** --> |
| 960 | |
| 961 | <div class="doc_text"> |
| 962 | |
| 963 | <p>If you're just looking to be a client of alias analysis information, consider |
| 964 | using the Memory Dependence Analysis interface instead. MemDep is a lazy, |
| 965 | caching layer on top of alias analysis that is able to answer the question of |
| 966 | what preceding memory operations a given instruction depends on, either at an |
| 967 | intra- or inter-block level. Because of its laziness and caching |
| 968 | policy, using MemDep can be a significant performance win over accessing alias |
| 969 | analysis directly.</p> |
| 970 | |
| 971 | </div> |
| 972 | |
| 973 | <!-- *********************************************************************** --> |
Chris Lattner | 9f64875 | 2003-03-04 19:37:49 +0000 | [diff] [blame] | 974 | |
Misha Brukman | 3896be2 | 2003-10-24 18:06:11 +0000 | [diff] [blame] | 975 | <hr> |
Misha Brukman | 915cab2 | 2003-11-22 01:26:21 +0000 | [diff] [blame] | 976 | <address> |
Misha Brukman | 38847d5 | 2003-12-21 22:53:21 +0000 | [diff] [blame] | 977 | <a href="http://jigsaw.w3.org/css-validator/check/referer"><img |
Misha Brukman | 4440870 | 2008-12-11 17:34:48 +0000 | [diff] [blame] | 978 | src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a> |
Misha Brukman | 915cab2 | 2003-11-22 01:26:21 +0000 | [diff] [blame] | 979 | <a href="http://validator.w3.org/check/referer"><img |
Misha Brukman | 4440870 | 2008-12-11 17:34:48 +0000 | [diff] [blame] | 980 | src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> |
Misha Brukman | 915cab2 | 2003-11-22 01:26:21 +0000 | [diff] [blame] | 981 | |
| 982 | <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> |
Reid Spencer | 05fe4b0 | 2006-03-14 05:39:39 +0000 | [diff] [blame] | 983 | <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br> |
Misha Brukman | 915cab2 | 2003-11-22 01:26:21 +0000 | [diff] [blame] | 984 | Last modified: $Date$ |
| 985 | </address> |
Misha Brukman | cd11e45 | 2003-10-22 23:27:16 +0000 | [diff] [blame] | 986 | |
| 987 | </body> |
| 988 | </html> |