replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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.

llvm-svn: 107495
This commit is contained in:
Dan Gohman 2010-07-02 18:41:32 +00:00
parent d2d60ce388
commit df12d08b8e
2 changed files with 39 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
llvm/docs/AliasAnalysis.html
View File

@ -192,12 +192,14 @@ and returns MustAlias, MayAlias, or NoAlias as appropriate.
</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

51
llvm/docs/LangRef.html
View File

@ -1051,14 +1051,13 @@ declare signext i8 @returns_signed_char()
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 @@ is undefined. Pointer values are associated with address ranges
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