6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-07-20 10:30:03 +00:00
Code Issues Projects Releases Wiki Activity

Fix the getelementptr description so it is extremely clear that array indices passed to getelementptr are signed.

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137538 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Eli Friedman 2011-08-12 23:37:55 +00:00
parent f03bb260c9
commit 266246c0ed
1 changed files with 13 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/LangRef.html
View File

@ -4954,7 +4954,7 @@ specified by the <var>operation</var> argument:</p>
When indexing into a (optionally packed) structure, only <tt>i32</tt> When indexing into a (optionally packed) structure, only <tt>i32</tt>
integer <b>constants</b> are allowed. When indexing into an array, pointer integer <b>constants</b> are allowed. When indexing into an array, pointer
or vector, integers of any width are allowed, and they are not required to be or vector, integers of any width are allowed, and they are not required to be
constant.</p> constant. These integers are treated as signed values where relevant.</p>
<p>For example, let's consider a C code fragment and how it gets compiled to <p>For example, let's consider a C code fragment and how it gets compiled to
LLVM:</p> LLVM:</p>
@ -5020,18 +5020,20 @@ entry:
base pointer is not an <i>in bounds</i> address of an allocated object, base pointer is not an <i>in bounds</i> address of an allocated object,
or if any of the addresses that would be formed by successive addition of or if any of the addresses that would be formed by successive addition of
the offsets implied by the indices to the base address with infinitely the offsets implied by the indices to the base address with infinitely
precise arithmetic are not an <i>in bounds</i> address of that allocated precise signed arithmetic are not an <i>in bounds</i> address of that
object. The <i>in bounds</i> addresses for an allocated object are all allocated object. The <i>in bounds</i> addresses for an allocated object
the addresses that point into the object, plus the address one byte past are all the addresses that point into the object, plus the address one
the end.</p> byte past the end.</p>
<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to <p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to
the base address with silently-wrapping two's complement arithmetic, and the base address with silently-wrapping two's complement arithmetic. If the
the result value of the <tt>getelementptr</tt> may be outside the object offsets have a different width from the pointer, they are sign-extended or
pointed to by the base pointer. The result value may not necessarily be truncated to the width of the pointer. The result value of the
used to access memory though, even if it happens to point into allocated <tt>getelementptr</tt> may be outside the object pointed to by the base
storage. See the <a href="#pointeraliasing">Pointer Aliasing Rules</a> pointer. The result value may not necessarily be used to access memory
section for more information.</p> though, even if it happens to point into allocated storage. See the
<a href="#pointeraliasing">Pointer Aliasing Rules</a> section for more
information.</p>
<p>The getelementptr instruction is often confusing. For some more insight into <p>The getelementptr instruction is often confusing. For some more insight into
how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p> how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p>