RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-12-03 09:21:02 +00:00
Code Issues Actions Packages 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>
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
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
LLVM:</p>
@ -5020,18 +5020,20 @@ entry:
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
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
object. The <i>in bounds</i> addresses for an allocated object are all
the addresses that point into the object, plus the address one byte past
the end.</p>
precise signed arithmetic are not an <i>in bounds</i> address of that
allocated object. The <i>in bounds</i> addresses for an allocated object
are all the addresses that point into the object, plus the address one
byte past the end.</p>
<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 result value of the <tt>getelementptr</tt> may be outside the object
pointed to by the base pointer. The result value may not necessarily be
used to access memory though, even if it happens to point into allocated
storage. See the <a href="#pointeraliasing">Pointer Aliasing Rules</a>
section for more information.</p>
the base address with silently-wrapping two's complement arithmetic. If the
offsets have a different width from the pointer, they are sign-extended or
truncated to the width of the pointer. The result value of the
<tt>getelementptr</tt> may be outside the object pointed to by the base
pointer. The result value may not necessarily be used to access memory
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
how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p>