[LLVMdev] Reassociating expressions involving GEPs

[Stefanus Du Toit]

On 9-Mar-09, at 12:14 AM, Chris Lattner wrote:
> GEP overflow is undefined, but this sentence means that *accesses* to
> an array must be within its bounds.  It is fine to GEP outside the
> array as long as you readjust the pointer back before access.

Thanks, that was my hope. Maybe this should be spelled out in the  
langref, especially since it's inconsistent with C, where merely doing  
pointer arithmetic that yields an out-of-bounds pointer (except for  
"one element past the end") yields undefined behaviour.

Perhaps something like: (apologies for the inline patch):

Index: LangRef.html
===================================================================
--- LangRef.html	(revision 66420)
+++ LangRef.html	(working copy)
@@ -3637,11 +3637,13 @@
    }
  </pre>

-<p>Note that it is undefined to access an array out of bounds: array  
and
-pointer indexes must always be within the defined bounds of the array  
type.
-The one exception for this rule is zero length arrays.  These arrays  
are
-defined to be accessible as variable length arrays, which requires  
access
-beyond the zero'th element.</p>
+<p>Note that it is undefined to access an array out of bounds: array
+and pointer indexes must always be within the defined bounds of the
+array type when accessed with an instruction that dereferences the
+pointer (e.g. a load or store instruction).  The one exception for
+this rule is zero length arrays.  These arrays are defined to be
+accessible as variable length arrays, which requires access beyond the
+zero'th element.</p>

  <p>The getelementptr instruction is often confusing.  For some more  
insight
  into how it works, see <a href="GetElementPtr.html">the getelementptr

--
Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
   RapidMind Inc.
   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463