From: Chris Lattner <sabre@nondot.org>
Date: Fri, 11 Feb 2011 21:50:52 +0000 (+0000)
Subject: attempt to capture recent discussion about overflow and inbounds geps.
X-Git-Tag: android-x86-6.0-r1~1002^2~546
X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=776b7df0e7a91ab86a8aef59f3c896721cd597d9;p=android-x86%2Fexternal-llvm.git

attempt to capture recent discussion about overflow and inbounds geps.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125412 91177308-0d34-0410-b5e6-96231b3b80d8
---

diff --git a/docs/GetElementPtr.html b/docs/GetElementPtr.html
index 890d2761ef4..41c45cab12d 100644
--- a/docs/GetElementPtr.html
+++ b/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>