Skip to content

Commit 16a97eb

Browse files
committed
Update LangRef for getelementptr explicit type changes
Here's a rough/first draft - it at least hits the actual textual IR examples and some of the phrasing. It's probably worth a full pass over, but I'm not sure how much these docs should reflect the strange intermediate state we're in anyway. Totally open to lots of review/feedback/suggestions. llvm-svn: 231294
1 parent 27f4571 commit 16a97eb

File tree

2 files changed

+40
-39
lines changed

2 files changed

+40
-39
lines changed

llvm/docs/GetElementPtr.rst

+17-17
Original file line numberDiff line numberDiff line change
@@ -89,12 +89,12 @@ looks like:
8989
9090
void %munge(%struct.munger_struct* %P) {
9191
entry:
92-
%tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
92+
%tmp = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 1, i32 0
9393
%tmp = load i32* %tmp
94-
%tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
94+
%tmp6 = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 2, i32 1
9595
%tmp7 = load i32* %tmp6
9696
%tmp8 = add i32 %tmp7, %tmp
97-
%tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
97+
%tmp9 = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 0, i32 0
9898
store i32 %tmp8, i32* %tmp9
9999
ret void
100100
}
@@ -109,9 +109,9 @@ To make this clear, let's consider a more obtuse example:
109109
110110
%MyVar = uninitialized global i32
111111
...
112-
%idx1 = getelementptr i32* %MyVar, i64 0
113-
%idx2 = getelementptr i32* %MyVar, i64 1
114-
%idx3 = getelementptr i32* %MyVar, i64 2
112+
%idx1 = getelementptr i32, i32* %MyVar, i64 0
113+
%idx2 = getelementptr i32, i32* %MyVar, i64 1
114+
%idx3 = getelementptr i32, i32* %MyVar, i64 2
115115
116116
These GEP instructions are simply making address computations from the base
117117
address of ``MyVar``. They compute, as follows (using C syntax):
@@ -146,7 +146,7 @@ variable which is always a pointer type. For example, consider this:
146146
147147
%MyStruct = uninitialized global { float*, i32 }
148148
...
149-
%idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1
149+
%idx = getelementptr { float*, i32 }, { float*, i32 }* %MyStruct, i64 0, i32 1
150150
151151
The GEP above yields an ``i32*`` by indexing the ``i32`` typed field of the
152152
structure ``%MyStruct``. When people first look at it, they wonder why the ``i64
@@ -182,7 +182,7 @@ only involved in the computation of addresses. For example, consider this:
182182
183183
%MyVar = uninitialized global { [40 x i32 ]* }
184184
...
185-
%idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17
185+
%idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17
186186
187187
In this example, we have a global variable, ``%MyVar`` that is a pointer to a
188188
structure containing a pointer to an array of 40 ints. The GEP instruction seems
@@ -197,9 +197,9 @@ following:
197197

198198
.. code-block:: llvm
199199
200-
%idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
200+
%idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0
201201
%arr = load [40 x i32]** %idx
202-
%idx = getelementptr [40 x i32]* %arr, i64 0, i64 17
202+
%idx = getelementptr [40 x i32], [40 x i32]* %arr, i64 0, i64 17
203203
204204
In this case, we have to load the pointer in the structure with a load
205205
instruction before we can index into the array. If the example was changed to:
@@ -208,7 +208,7 @@ instruction before we can index into the array. If the example was changed to:
208208
209209
%MyVar = uninitialized global { [40 x i32 ] }
210210
...
211-
%idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17
211+
%idx = getelementptr { [40 x i32] }, { [40 x i32] }*, i64 0, i32 0, i64 17
212212
213213
then everything works fine. In this case, the structure does not contain a
214214
pointer and the GEP instruction can index through the global variable, into the
@@ -225,9 +225,9 @@ index. Consider this example:
225225

226226
.. code-block:: llvm
227227
228-
%MyVar = global { [10 x i32 ] }
229-
%idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
230-
%idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1
228+
%MyVar = global { [10 x i32] }
229+
%idx1 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 0, i32 0, i64 1
230+
%idx2 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1
231231
232232
In this example, ``idx1`` computes the address of the second integer in the
233233
array that is in the structure in ``%MyVar``, that is ``MyVar+4``. The type of
@@ -248,9 +248,9 @@ type. Consider this example:
248248

249249
.. code-block:: llvm
250250
251-
%MyVar = global { [10 x i32 ] }
252-
%idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
253-
%idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1
251+
%MyVar = global { [10 x i32] }
252+
%idx1 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1, i32 0, i64 0
253+
%idx2 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1
254254
255255
In this example, the value of ``%idx1`` is ``%MyVar+40`` and its type is
256256
``i32*``. The value of ``%idx2`` is also ``MyVar+40`` but its type is ``{ [10 x

llvm/docs/LangRef.rst

+23-22
Original file line numberDiff line numberDiff line change
@@ -162,7 +162,7 @@ symbol table entries. Here is an example of the "hello world" module:
162162
; Definition of main function
163163
define i32 @main() { ; i32()*
164164
; Convert [13 x i8]* to i8 *...
165-
%cast210 = getelementptr [13 x i8]* @.str, i64 0, i64 0
165+
%cast210 = getelementptr [13 x i8], [13 x i8]* @.str, i64 0, i64 0
166166
167167
; Call puts function to write out the string to stdout.
168168
call i32 @puts(i8* %cast210)
@@ -1057,8 +1057,8 @@ The prefix data can be referenced as,
10571057

10581058
.. code-block:: llvm
10591059
1060-
%0 = bitcast *void () @f to *i32
1061-
%a = getelementptr inbounds *i32 %0, i32 -1
1060+
%0 = bitcast void* () @f to i32*
1061+
%a = getelementptr inbounds i32, i32* %0, i32 -1
10621062
%b = load i32* %a
10631063
10641064
Prefix data is laid out as if it were an initializer for a global variable
@@ -1584,7 +1584,7 @@ A pointer value is *based* on another pointer value according to the
15841584
following rules:
15851585

15861586
- A pointer value formed from a ``getelementptr`` operation is *based*
1587-
on the first operand of the ``getelementptr``.
1587+
on the first value operand of the ``getelementptr``.
15881588
- The result value of a ``bitcast`` is *based* on the operand of the
15891589
``bitcast``.
15901590
- A pointer value formed by an ``inttoptr`` is *based* on all pointer
@@ -2567,7 +2567,7 @@ Here are some examples:
25672567
entry:
25682568
%poison = sub nuw i32 0, 1 ; Results in a poison value.
25692569
%still_poison = and i32 %poison, 0 ; 0, but also poison.
2570-
%poison_yet_again = getelementptr i32* @h, i32 %still_poison
2570+
%poison_yet_again = getelementptr i32, i32* @h, i32 %still_poison
25712571
store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned
25722572
25732573
store i32 %poison, i32* @g ; Poison value stored to memory.
@@ -5930,9 +5930,9 @@ Syntax:
59305930

59315931
::
59325932

5933-
<result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
5934-
<result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}*
5935-
<result> = getelementptr <ptr vector> ptrval, <vector index type> idx
5933+
<result> = getelementptr <ty>, <ty>* <ptrval>{, <ty> <idx>}*
5934+
<result> = getelementptr inbounds <ty>, <ty>* <ptrval>{, <ty> <idx>}*
5935+
<result> = getelementptr <ty>, <ptr vector> <ptrval>, <vector index type> <idx>
59365936

59375937
Overview:
59385938
"""""""""
@@ -5944,8 +5944,9 @@ address calculation only and does not access memory.
59445944
Arguments:
59455945
""""""""""
59465946

5947-
The first argument is always a pointer or a vector of pointers, and
5948-
forms the basis of the calculation. The remaining arguments are indices
5947+
The first argument is always a type used as the basis for the calculations.
5948+
The second argument is always a pointer or a vector of pointers, and is the
5949+
base address to start from. The remaining arguments are indices
59495950
that indicate which of the elements of the aggregate object are indexed.
59505951
The interpretation of each index is dependent on the type being indexed
59515952
into. The first index always indexes the pointer value given as the
@@ -5993,7 +5994,7 @@ The LLVM code generated by Clang is:
59935994
59945995
define i32* @foo(%struct.ST* %s) nounwind uwtable readnone optsize ssp {
59955996
entry:
5996-
%arrayidx = getelementptr inbounds %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13
5997+
%arrayidx = getelementptr inbounds %struct.ST, %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13
59975998
ret i32* %arrayidx
59985999
}
59996000
@@ -6018,11 +6019,11 @@ for the given testcase is equivalent to:
60186019
.. code-block:: llvm
60196020
60206021
define i32* @foo(%struct.ST* %s) {
6021-
%t1 = getelementptr %struct.ST* %s, i32 1 ; yields %struct.ST*:%t1
6022-
%t2 = getelementptr %struct.ST* %t1, i32 0, i32 2 ; yields %struct.RT*:%t2
6023-
%t3 = getelementptr %struct.RT* %t2, i32 0, i32 1 ; yields [10 x [20 x i32]]*:%t3
6024-
%t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 ; yields [20 x i32]*:%t4
6025-
%t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 ; yields i32*:%t5
6022+
%t1 = getelementptr %struct.ST, %struct.ST* %s, i32 1 ; yields %struct.ST*:%t1
6023+
%t2 = getelementptr %struct.ST, %struct.ST* %t1, i32 0, i32 2 ; yields %struct.RT*:%t2
6024+
%t3 = getelementptr %struct.RT, %struct.RT* %t2, i32 0, i32 1 ; yields [10 x [20 x i32]]*:%t3
6025+
%t4 = getelementptr [10 x [20 x i32]], [10 x [20 x i32]]* %t3, i32 0, i32 5 ; yields [20 x i32]*:%t4
6026+
%t5 = getelementptr [20 x i32], [20 x i32]* %t4, i32 0, i32 13 ; yields i32*:%t5
60266027
ret i32* %t5
60276028
}
60286029
@@ -6056,20 +6057,20 @@ Example:
60566057
.. code-block:: llvm
60576058
60586059
; yields [12 x i8]*:aptr
6059-
%aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
6060+
%aptr = getelementptr {i32, [12 x i8]}, {i32, [12 x i8]}* %saptr, i64 0, i32 1
60606061
; yields i8*:vptr
6061-
%vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
6062+
%vptr = getelementptr {i32, <2 x i8>}, {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
60626063
; yields i8*:eptr
6063-
%eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
6064+
%eptr = getelementptr [12 x i8], [12 x i8]* %aptr, i64 0, i32 1
60646065
; yields i32*:iptr
6065-
%iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
6066+
%iptr = getelementptr [10 x i32], [10 x i32]* @arr, i16 0, i16 0
60666067
60676068
In cases where the pointer argument is a vector of pointers, each index
60686069
must be a vector with the same number of elements. For example:
60696070

60706071
.. code-block:: llvm
60716072
6072-
%A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets,
6073+
%A = getelementptr i8, <4 x i8*> %ptrs, <4 x i64> %offsets,
60736074
60746075
Conversion Operations
60756076
---------------------
@@ -9546,7 +9547,7 @@ It can be created as follows:
95469547
.. code-block:: llvm
95479548
95489549
%tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
9549-
%tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
9550+
%tramp1 = getelementptr [10 x i8], [10 x i8]* %tramp, i32 0, i32 0
95509551
call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval)
95519552
%p = call i8* @llvm.adjust.trampoline(i8* %tramp1)
95529553
%fp = bitcast i8* %p to i32 (i32, i32)*

0 commit comments

Comments
 (0)