summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2011-02-11 21:50:52 +0000
committerChris Lattner <sabre@nondot.org>2011-02-11 21:50:52 +0000
commit39b6d87e9f686faf11d736925f0a5d882a3eec89 (patch)
treea8a58b186317e6e6a8c325627ae64a1b89db7fab
parent1800d823de1ec72d827f12ca340d5ca2d2a81510 (diff)
downloadbcm5719-llvm-39b6d87e9f686faf11d736925f0a5d882a3eec89.tar.gz
bcm5719-llvm-39b6d87e9f686faf11d736925f0a5d882a3eec89.zip
attempt to capture recent discussion about overflow and inbounds geps.
llvm-svn: 125412
-rw-r--r--llvm/docs/GetElementPtr.html28
1 files changed, 21 insertions, 7 deletions
diff --git a/llvm/docs/GetElementPtr.html b/llvm/docs/GetElementPtr.html
index 890d2761ef4..41c45cab12d 100644
--- a/llvm/docs/GetElementPtr.html
+++ b/llvm/docs/GetElementPtr.html
@@ -598,13 +598,27 @@ idx3 = (char*) &amp;MyVar + 8
<a name="overflow"><b>What happens if a GEP computation overflows?</b></a>
</div>
<div class="doc_text">
- <p>If the GEP has the <tt>inbounds</tt> keyword, the result value is
- undefined.</p>
-
- <p>Otherwise, the result value is the result from evaluating the implied
- two's complement integer computation. However, since there's no
- guarantee of where an object will be allocated in the address space,
- such values have limited meaning.</p>
+ <p>If the GEP lacks the <tt>inbounds</tt> keyword, the value is the result
+ from evaluating the implied two's complement integer computation. However,
+ since there's no guarantee of where an object will be allocated in the
+ address space, such values have limited meaning.</p>
+
+ <p>If the GEP has the <tt>inbounds</tt> keyword, the result value is
+ undefined (a "<a href="LangRef.html#trapvalues">trap value</a>") if the GEP
+ overflows (i.e. wraps around the end of the address space).</p>
+
+ <p>As such, there are some ramifications of this for inbounds GEPs: scales
+ implied by array/vector/pointer indices are always known to be "nsw" since
+ they are signed values that are scaled by the element size. These values
+ are also allowed to be negative (e.g. "gep i32 *%P, i32 -1") but the
+ pointer itself is logically treated as an unsigned value. This means that
+ GEPs have an asymmetric relation between the pointer base (which is treated
+ as unsigned) and the offset applied to it (which is treated as signed). The
+ result of the additions within the offset calculation cannot have signed
+ overflow, but when applied to the base pointer, there can be signed
+ overflow.
+ </p>
+
</div>
OpenPOWER on IntegriCloud