llvm.org GIT mirror llvm / dfecbe9
Add an "advanced" GetElementPtr FAQ document, with answers to questions left unanswered by the first GetElementPtr FAQ. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96526 91177308-0d34-0410-b5e6-96231b3b80d8 Dan Gohman 9 years ago
2 changed file(s) with 359 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
0
1 "http://www.w3.org/TR/html4/strict.dtd">
2
3
4
5 The Revenge Of The Often Misunderstood GEP Instruction
6
7
10
11
12
13
14 The Revenge Of The Often Misunderstood GEP Instruction
15
16
17
18
19
20
21

GEP was mysterious and wily at first, but it turned out that the basic

22 workings were fairly comprehensible. However the dragon was merely subdued;
23 now it's back, and it has more fundamental complexity to confront. This
24 document seeks to uncover misunderstandings of the GEP operator that tend
25 to persist past initial confusion about the funky "extra 0" thing. Here we
26 show that the GEP instruction is really not quite as simple as it seems,
27 even after the initial confusion is overcome.

28
29
30
31
32 How is GEP different from ptrtoint, arithmetic,
33 and inttoptr?
34
35
36

It's very similar; there are only subtle differences.

37
38

With ptrtoint, you have to pick an integer type. One approach is to pick i64;

39 this is safe on everything LLVM supports (LLVM internally assumes pointers
40 are never wider than 64 bits in many places), and the optimizer will actually
41 narrow the i64 arithmetic down to the actual pointer size on targets which
42 don't support 64-bit arithmetic in most cases. However, there are some cases
43 where it doesn't do this. With GEP you can avoid this problem.
44
45

Also, GEP carries additional pointer aliasing rules. It's invalid to take a

46 GEP from one object and address into a different separately allocated
47 object. IR producers (front-ends) must follow this rule, and consumers
48 (optimizers, specifically alias analysis) benefit from being able to rely
49 on it.

50
51

And, GEP is more concise in common cases.

52
53

However, for of the underlying integer computation implied, there

54 is no difference.

55
56
57
58
59
60 I'm writing a backend for a target which needs custom
61 lowering for GEP. How do I do this?
62
63
64

You don't. The integer computation implied by a GEP is target-independent.

65 Typically what you'll need to do is make your backend pattern-match
66 expressions trees involving ADD, MUL, etc., which are what GEP is lowered
67 into. This has the advantage of letting your code work correctly in more
68 cases.

69
70

GEP does use target-dependent parameters for the size and layout of data

71 types, which targets can customize.

72
73

If you require support for addressing units which are not 8 bits, you'll

74 need to fix a lot of code in the backend, with GEP lowering being only a
75 small piece of the overall picture.

76
77
78
79
80
81 Why do struct member indices always use i32?
82
83
84

The specific type i32 is probably just a historical artifact, however it's

85 wide enough for all practical purposes, so there's been no need to change it.
86 It doesn't necessarily imply i32 address arithmetic; it's just an identifier
87 which identifies a field in a struct. Requiring that all struct indices be
88 the same reduces the range of possibilities for cases where two GEPs are
89 effectively the same but have distinct operand types.

90
91
92
93
94
95 How does VLA addressing work with GEPs?
96
97
98

GEPs don't natively support VLAs. LLVM's type system is entirely static,

99 and GEP address computations are guided by an LLVM type.

100
101

VLA indices can be implemented as linearized indices. For example, an

102 expression like X[a][b][c], must be effectively lowered into a form
103 like X[a*m+b*n+c], so that it appears to the GEP as a single-dimensional
104 array reference.

105
106

This means if you want to write an analysis which understands array

107 indices and you want to support VLAs, your code will have to be
108 prepared to reverse-engineer the linearization. One way to solve this
109 problem is to use the ScalarEvolution library, which always presents
110 VLA and non-VLA indexing in the same manner.

111
112
113
114
115
116 What happens if an array index is out of bounds?
117
118
119

There are two senses in which an array index can be out of bounds.

120
121

First, there's the array type which comes from the (static) type of

122 the first operand to the GEP. Indices greater than the number of elements
123 in the corresponding static array type are valid. There is no problem with
124 out of bounds indices in this sense. Indexing into an array only depends
125 on the size of the array element, not the number of elements.

126
127

A common example of how this is used is arrays where the size is not known.

128 It's common to use array types with zero length to represent these. The
129 fact that the static type says there are zero elements is irrelevant; it's
130 perfectly valid to compute arbitrary element indices, as the computation
131 only depends on the size of the array element, not the number of
132 elements. Note that zero-sized arrays are not a special case here.

133
134

This sense is unconnected with inbounds keyword. The

135 inbounds keyword is designed to describe low-level pointer
136 arithmetic overflow conditions, rather than high-level array
137 indexing rules.
138
139

Analysis passes which wish to understand array indexing should not

140 assume that the static array type bounds are respected.

141
142

The second sense of being out of bounds is computing an address that's

143 beyond of the actual underlying allocated object.

144
145

With the inbounds keyword, the result value of the GEP is

146 undefined if the address is outside the actual underlying allocated
147 object and not the address one-past-the-end.

148
149

Without the inbounds keyword, there are no restrictions

150 on computing out-of-bounds addresses. Obviously, performing a load or
151 a store requires an address of allocated and sufficiently aligned
152 memory. But the GEP itself is only concerned with computing addresses.

153
154
155
156
157
158 Can array indices be negative?
159
160
161

Yes. This is basically a special case of array indices being out

162 of bounds.

163
164
165
166
167
168 Can I compare two values computed with GEPs?
169
170
171

Yes. If both addresses are within the same allocated object, or

172 one-past-the-end, you'll get the comparison result you expect. If either
173 is outside of it, integer arithmetic wrapping may occur, so the
174 comparison may not be meaningful.

175
176
177
178
179
180 Can I do GEP with a different pointer type than the type of
181 the underlying object?
182
183
184

Yes. There are no restrictions on bitcasting a pointer value to an arbitrary

185 pointer type. The types in a GEP serve only to define the parameters for the
186 underlying integer computation. They need not correspond with the actual
187 type of the underlying object.

188
189

Furthermore, loads and stores don't have to use the same types as the type

190 of the underlying object. Types in this context serve only to specify
191 memory size and alignment. Beyond that there are merely a hint to the
192 optimizer indicating how the value will likely be used.

193
194
195
196
197
198 Can I cast an object's address to integer and add it
199 to null?
200
201
202

You can compute an address that way, but you can't use that pointer to

203 actually access the object if you do, unless the object is managed
204 outside of LLVM.

205
206

The underlying integer computation is sufficiently defined; null has a

207 defined value -- zero -- and you can add whatever value you want to it.

208
209

However, it's invalid to access (load from or store to) an LLVM-aware

210 object with such a pointer. This includes GlobalVariables, Allocas, and
211 objects pointed to by noalias pointers.

212
213
214
215
216
217 Can I compute the distance between two objects, and add
218 that value to one address to compute the other address?
219
220
221

As with arithmetic on null, You can compute an address that way, but

222 you can't use that pointer to actually access the object if you do,
223 unless the object is managed outside of LLVM.

224
225
226
227
228
229 Can I do type-based alias analysis on LLVM IR?
230
231
232

You can't do type-based alias analysis using LLVM's built-in type system,

233 because LLVM has no restrictions on mixing types in addressing, loads or
234 stores.

235
236

It would be possible to add special annotations to the IR, probably using

237 metadata, to describe a different type system (such as the C type system),
238 and do type-based aliasing on top of that. This is a much bigger
239 undertaking though.

240
241
242
243
244
245
246 What's an uglygep?
247
248
249

Some LLVM optimizers operate on GEPs by internally lowering them into

250 more primitive integer expressions, which allows them to be combined
251 with other integer expressions and/or split into multiple separate
252 integer expressions. If they've made non-trivial changes, translating
253 back into LLVM IR can involve reverse-engineering the structure of
254 the addressing in order to fit it into the static type of the original
255 first operand. It isn't always possibly to fully reconstruct this
256 structure; sometimes the underlying addressing doesn't correspond with
257 the static type at all. In such cases the optimizer instead will emit
258 a GEP with the base pointer casted to a simple address-unit pointer,
259 using the name "uglygep". This isn't pretty, but it's just as
260 valid, and it's sufficient to preserve the pointer aliasing guarantees
261 that GEP provides.

262
263
264
265
266
267
268 Can GEP index into vector elements?
269
270
271

Sort of. This hasn't always been forcefully disallowed, though it's

272 not recommended. It leads to awkward special cases in the optimizers.
273 In the future, it may be outright disallowed.

274
275

Instead, you should cast your pointer types and use arrays instead of

276 vectors for addressing. Arrays have the same in-memory representation
277 as vectors, so the addressing is interchangeable.

278
279
280
281
282
283
284 Can GEP index into unions?
285
286
287

Unknown.

288
289
290
291
292
293
294 What happens if a GEP computation overflows?
295
296
297

If the GEP has the inbounds keyword, the result value is

298 undefined.

299
300

Otherwise, the result value is the result from evaluating the implied

301 two's complement integer computation. However, since there's no
302 guarantee of where an object will be allocated in the address space,
303 such values have limited meaning.

304
305
306
307
308
309
310 What effect do address spaces have on GEPs?
311
312
313

None, except that the address space qualifier on the first operand pointer

314 type always matches the address space qualifier on the result type.

315
316
317
318
319
320
321 Why is GEP designed this way?
322
323
324

The design of GEP has the following goals, in rough unofficial

325 order of priority:

326

327
328
  • Support C, C-like languages, and languages which can be
  • 329 conceptually lowered into C (this covers a lot).
    330
  • Support optimizations such as those that are common in
  • 331 C compilers.
    332
  • Provide a consistent method for computing addresses so that
  • 333 address computations don't need to be a part of load and
    334 store instructions in the IR.
    335
  • Support non-C-like languages, to the extent that it doesn't
  • 336 interfere with other goals.
    337
  • Minimize target-specific information in the IR.
  • 338
    339

    340
    341
    342
    343
    344
    345
    346
    347 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
    348
    349 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
    350 The LLVM Compiler Infrastructure
    351 Last modified: $Date$
    352
    353
    354
    355
    5353 Multi-Stage Optimization - More details (quite old now).
    5454
  • GetElementPtr FAQ - Answers to some very
  • 5555 frequent questions about LLVM's most frequently misunderstood instruction.
    56
  • Advanced GetElementPtr FAQ - Answers
  • 57 to questions about the GetElementPtr operator for those who have made it through
    58 the first FAQ.
    5659
    5760
    5861