implementations</a></li>
</ul>
</li>
+ <li><a href="#memdep">Memory Dependence Analysis</a></li>
</ol>
<div class="doc_author">
different ways of classifying them: flow-sensitive vs flow-insensitive,
context-sensitive vs context-insensitive, field-sensitive vs field-insensitive,
unification-based vs subset-based, etc. Traditionally, alias analyses respond
-to a query with a <a href="#MustNoMay">Must, May, or No</a> alias response,
+to a query with a <a href="#MustMayNo">Must, May, or No</a> alias response,
indicating that two pointers always point to the same object, might point to the
same object, or are known to never point to the same object.</p>
</div>
<div class="doc_text">
+<p>The NoAlias response is used when the two pointers refer to distinct objects,
+regardless of whether the pointers compare equal. For example, freed pointers
+don't alias any pointers that were allocated afterwards. As a degenerate case,
+pointers returned by malloc(0) have no bytes for an object, and are considered
+NoAlias even when malloc returns the same pointer. The same rule applies to
+NULL pointers.</p>
-<p>An Alias Analysis implementation can return one of three responses:
-MustAlias, MayAlias, and NoAlias. The No and May alias results are obvious: if
-the two pointers can never equal each other, return NoAlias, if they might,
-return MayAlias.</p>
+<p>The MayAlias response is used whenever the two pointers might refer to the
+same object. If the two memory objects overlap, but do not start at the same
+location, return MayAlias.</p>
-<p>The MustAlias response is trickier though. In LLVM, the Must Alias response
-may only be returned if the two memory objects are guaranteed to always start at
-exactly the same location. If two memory objects overlap, but do not start at
-the same location, return MayAlias.</p>
+<p>The MustAlias response may only be returned if the two memory objects are
+guaranteed to always start at exactly the same location. A MustAlias response
+implies that the pointers compare equal.</p>
</div>
Structure Analysis framework. This gives it substantially more precision than
the standard algorithm while maintaining excellent analysis scalability.</p>
+<p>Note that <tt>-steens-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
</div>
<!-- _______________________________________________________________________ -->
only major facility not implemented so far is support for must-alias
information.</p>
+<p>Note that <tt>-ds-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
</div>
</div>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="memdep">Memory Dependence Analysis</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>If you're just looking to be a client of alias analysis information, consider
+using the Memory Dependence Analysis interface instead. MemDep is a lazy,
+caching layer on top of alias analysis that is able to answer the question of
+what preceding memory operations a given instruction depends on, either at an
+intra- or inter-block level. Because of its laziness and caching
+policy, using MemDep can be a significant performance win over accessing alias
+analysis directly.</p>
+
+</div>
+
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
<a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
projects / oota-llvm.git / blobdiff