[llvm-commits] [llvm] r107495 - in /llvm/trunk/docs: AliasAnalysis.html LangRef.html

[Dan Gohman]

Author: djg
Date: Fri Jul  2 13:41:32 2010
New Revision: 107495

URL: http://llvm.org/viewvc/llvm-project?rev=107495&view=rev
Log:
Reword the definition of the noalias attribute. The intention is for
the noalias argument on function attributes be usable to model the
C99 restrict keyword on arguments, and to allow AliasAnalysis to
consider a noalias-attributed argument to be an "identified object".

To support this, refactor a new "based on" concept out of the current
pointer aliasing "associated" concept. This "based on" concept is very
similar to (though it is not identical with) the "based on" concept
in C99.

Also, reword the definition of NoAlias to more closely describe the
concept that the optimizer uses.

Modified:
    llvm/trunk/docs/AliasAnalysis.html
    llvm/trunk/docs/LangRef.html

Modified: llvm/trunk/docs/AliasAnalysis.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/AliasAnalysis.html?rev=107495&r1=107494&r2=107495&view=diff
==============================================================================
--- llvm/trunk/docs/AliasAnalysis.html (original)
+++ llvm/trunk/docs/AliasAnalysis.html Fri Jul  2 13:41:32 2010
@@ -192,12 +192,14 @@
 </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>The NoAlias response may be used when there is never an immediate dependence
+between any memory reference <i>based</i> on one pointer and any memory
+reference <i>based</i> the other. The most obvious example is when the two
+pointers point to non-overlapping memory ranges. Another is when the two
+pointers are only ever used for reading memory. Another is when the memory is
+freed and reallocated between accesses through one pointer and accesses through
+the other -- in this case, there is a dependence, but it's mediated by the free
+and reallocation.</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

Modified: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=107495&r1=107494&r2=107495&view=diff
==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html Fri Jul  2 13:41:32 2010
@@ -1051,14 +1051,13 @@
       for return values. </dd>
 
   <dt><tt><b>noalias</b></tt></dt>
-  <dd>This indicates that the pointer does not alias any global or any other
-      parameter.  The caller is responsible for ensuring that this is the
-      case. On a function return value, <tt>noalias</tt> additionally indicates
-      that the pointer does not alias any other pointers visible to the
-      caller. For further details, please see the discussion of the NoAlias
-      response in
-      <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
-      analysis</a>.</dd>
+  <dd>This indicates that pointer values
+      <a href="#pointeraliasing"><i>based</i></a> on the argument or return
+      value do not alias pointer values which are not <i>based</i> on it.
+      The caller shares the responsibility with the callee for ensuring that
+      these requirements are met.
+      For further details, please see the discussion of the NoAlias response in
+      <a href="AliasAnalysis.html#MustMayNo">alias analysis</a>.</dd>
 
   <dt><tt><b>nocapture</b></tt></dt>
   <dd>This indicates that the callee does not make any copies of the pointer
@@ -1367,29 +1366,41 @@
 according to the following rules:</p>
 
 <ul>
-  <li>A pointer value formed from a
-      <tt><a href="#i_getelementptr">getelementptr</a></tt> instruction
-      is associated with the addresses associated with the first operand
-      of the <tt>getelementptr</tt>.</li>
+  <li>A pointer value is associated with the addresses associated with
+      any value it is <i>based</i> on.
   <li>An address of a global variable is associated with the address
       range of the variable's storage.</li>
   <li>The result value of an allocation instruction is associated with
       the address range of the allocated storage.</li>
   <li>A null pointer in the default address-space is associated with
       no address.</li>
-  <li>A pointer value formed by an
-      <tt><a href="#i_inttoptr">inttoptr</a></tt> is associated with all
-      address ranges of all pointer values that contribute (directly or
-      indirectly) to the computation of the pointer's value.</li>
-  <li>The result value of a
-      <tt><a href="#i_bitcast">bitcast</a></tt> is associated with all
-      addresses associated with the operand of the <tt>bitcast</tt>.</li>
   <li>An integer constant other than zero or a pointer value returned
       from a function not defined within LLVM may be associated with address
       ranges allocated through mechanisms other than those provided by
       LLVM. Such ranges shall not overlap with any ranges of addresses
       allocated by mechanisms provided by LLVM.</li>
-  </ul>
+</ul>
+
+<p>A pointer value is <i>based</i> on another pointer value according
+   to the following rules:</p>
+
+<ul>
+  <li>A pointer value formed from a
+      <tt><a href="#i_getelementptr">getelementptr</a></tt> operation
+      is <i>based</i> on the first operand of the <tt>getelementptr</tt>.</li>
+  <li>The result value of a
+      <tt><a href="#i_bitcast">bitcast</a></tt> is <i>based</i> on the operand
+      of the <tt>bitcast</tt>.</li>
+  <li>A pointer value formed by an
+      <tt><a href="#i_inttoptr">inttoptr</a></tt> is <i>based</i> on all
+      pointer values that contribute (directly or indirectly) to the
+      computation of the pointer's value.</li>
+  <li>The "<i>based</i> on" relationship is transitive.</li>
+</ul>
+
+<p>Note that this definition of <i>"based"</i> is intentionally
+   similar to the definition of <i>"based"</i> in C99, though it is
+   slightly weaker.</p>
 
 <p>LLVM IR does not associate types with memory. The result type of a
 <tt><a href="#i_load">load</a></tt> merely indicates the size and