]>
Commit | Line | Data |
---|---|---|
223e47cc LB |
1 | ======================================= |
2 | The Often Misunderstood GEP Instruction | |
3 | ======================================= | |
4 | ||
5 | .. contents:: | |
6 | :local: | |
7 | ||
8 | Introduction | |
9 | ============ | |
10 | ||
11 | This document seeks to dispel the mystery and confusion surrounding LLVM's | |
12 | `GetElementPtr <LangRef.html#i_getelementptr>`_ (GEP) instruction. Questions | |
13 | about the wily GEP instruction are probably the most frequently occurring | |
14 | questions once a developer gets down to coding with LLVM. Here we lay out the | |
15 | sources of confusion and show that the GEP instruction is really quite simple. | |
16 | ||
17 | Address Computation | |
18 | =================== | |
19 | ||
20 | When people are first confronted with the GEP instruction, they tend to relate | |
21 | it to known concepts from other programming paradigms, most notably C array | |
22 | indexing and field selection. GEP closely resembles C array indexing and field | |
970d7e83 | 23 | selection, however it is a little different and this leads to the following |
223e47cc LB |
24 | questions. |
25 | ||
26 | What is the first index of the GEP instruction? | |
27 | ----------------------------------------------- | |
28 | ||
29 | Quick answer: The index stepping through the first operand. | |
30 | ||
31 | The confusion with the first index usually arises from thinking about the | |
32 | GetElementPtr instruction as if it was a C index operator. They aren't the | |
33 | same. For example, when we write, in "C": | |
34 | ||
35 | .. code-block:: c++ | |
36 | ||
37 | AType *Foo; | |
38 | ... | |
39 | X = &Foo->F; | |
40 | ||
41 | it is natural to think that there is only one index, the selection of the field | |
42 | ``F``. However, in this example, ``Foo`` is a pointer. That pointer | |
43 | must be indexed explicitly in LLVM. C, on the other hand, indices through it | |
44 | transparently. To arrive at the same address location as the C code, you would | |
45 | provide the GEP instruction with two index operands. The first operand indexes | |
46 | through the pointer; the second operand indexes the field ``F`` of the | |
47 | structure, just as if you wrote: | |
48 | ||
49 | .. code-block:: c++ | |
50 | ||
51 | X = &Foo[0].F; | |
52 | ||
53 | Sometimes this question gets rephrased as: | |
54 | ||
55 | .. _GEP index through first pointer: | |
56 | ||
57 | *Why is it okay to index through the first pointer, but subsequent pointers | |
58 | won't be dereferenced?* | |
59 | ||
60 | The answer is simply because memory does not have to be accessed to perform the | |
61 | computation. The first operand to the GEP instruction must be a value of a | |
62 | pointer type. The value of the pointer is provided directly to the GEP | |
63 | instruction as an operand without any need for accessing memory. It must, | |
64 | therefore be indexed and requires an index operand. Consider this example: | |
65 | ||
66 | .. code-block:: c++ | |
67 | ||
68 | struct munger_struct { | |
69 | int f1; | |
70 | int f2; | |
71 | }; | |
72 | void munge(struct munger_struct *P) { | |
73 | P[0].f1 = P[1].f1 + P[2].f2; | |
74 | } | |
75 | ... | |
76 | munger_struct Array[3]; | |
77 | ... | |
78 | munge(Array); | |
79 | ||
80 | In this "C" example, the front end compiler (llvm-gcc) will generate three GEP | |
81 | instructions for the three indices through "P" in the assignment statement. The | |
82 | function argument ``P`` will be the first operand of each of these GEP | |
83 | instructions. The second operand indexes through that pointer. The third | |
84 | operand will be the field offset into the ``struct munger_struct`` type, for | |
85 | either the ``f1`` or ``f2`` field. So, in LLVM assembly the ``munge`` function | |
86 | looks like: | |
87 | ||
88 | .. code-block:: llvm | |
89 | ||
90 | void %munge(%struct.munger_struct* %P) { | |
91 | entry: | |
92 | %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0 | |
93 | %tmp = load i32* %tmp | |
94 | %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1 | |
95 | %tmp7 = load i32* %tmp6 | |
96 | %tmp8 = add i32 %tmp7, %tmp | |
97 | %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0 | |
98 | store i32 %tmp8, i32* %tmp9 | |
99 | ret void | |
100 | } | |
101 | ||
102 | In each case the first operand is the pointer through which the GEP instruction | |
103 | starts. The same is true whether the first operand is an argument, allocated | |
104 | memory, or a global variable. | |
105 | ||
106 | To make this clear, let's consider a more obtuse example: | |
107 | ||
108 | .. code-block:: llvm | |
109 | ||
110 | %MyVar = uninitialized global i32 | |
111 | ... | |
112 | %idx1 = getelementptr i32* %MyVar, i64 0 | |
113 | %idx2 = getelementptr i32* %MyVar, i64 1 | |
114 | %idx3 = getelementptr i32* %MyVar, i64 2 | |
115 | ||
116 | These GEP instructions are simply making address computations from the base | |
117 | address of ``MyVar``. They compute, as follows (using C syntax): | |
118 | ||
119 | .. code-block:: c++ | |
120 | ||
121 | idx1 = (char*) &MyVar + 0 | |
122 | idx2 = (char*) &MyVar + 4 | |
123 | idx3 = (char*) &MyVar + 8 | |
124 | ||
125 | Since the type ``i32`` is known to be four bytes long, the indices 0, 1 and 2 | |
126 | translate into memory offsets of 0, 4, and 8, respectively. No memory is | |
127 | accessed to make these computations because the address of ``%MyVar`` is passed | |
128 | directly to the GEP instructions. | |
129 | ||
130 | The obtuse part of this example is in the cases of ``%idx2`` and ``%idx3``. They | |
131 | result in the computation of addresses that point to memory past the end of the | |
132 | ``%MyVar`` global, which is only one ``i32`` long, not three ``i32``\s long. | |
133 | While this is legal in LLVM, it is inadvisable because any load or store with | |
134 | the pointer that results from these GEP instructions would produce undefined | |
135 | results. | |
136 | ||
137 | Why is the extra 0 index required? | |
138 | ---------------------------------- | |
139 | ||
140 | Quick answer: there are no superfluous indices. | |
141 | ||
142 | This question arises most often when the GEP instruction is applied to a global | |
143 | variable which is always a pointer type. For example, consider this: | |
144 | ||
145 | .. code-block:: llvm | |
146 | ||
147 | %MyStruct = uninitialized global { float*, i32 } | |
148 | ... | |
149 | %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1 | |
150 | ||
151 | The GEP above yields an ``i32*`` by indexing the ``i32`` typed field of the | |
152 | structure ``%MyStruct``. When people first look at it, they wonder why the ``i64 | |
153 | 0`` index is needed. However, a closer inspection of how globals and GEPs work | |
154 | reveals the need. Becoming aware of the following facts will dispel the | |
155 | confusion: | |
156 | ||
157 | #. The type of ``%MyStruct`` is *not* ``{ float*, i32 }`` but rather ``{ float*, | |
158 | i32 }*``. That is, ``%MyStruct`` is a pointer to a structure containing a | |
159 | pointer to a ``float`` and an ``i32``. | |
160 | ||
161 | #. Point #1 is evidenced by noticing the type of the first operand of the GEP | |
162 | instruction (``%MyStruct``) which is ``{ float*, i32 }*``. | |
163 | ||
164 | #. The first index, ``i64 0`` is required to step over the global variable | |
165 | ``%MyStruct``. Since the first argument to the GEP instruction must always | |
166 | be a value of pointer type, the first index steps through that pointer. A | |
167 | value of 0 means 0 elements offset from that pointer. | |
168 | ||
169 | #. The second index, ``i32 1`` selects the second field of the structure (the | |
170 | ``i32``). | |
171 | ||
172 | What is dereferenced by GEP? | |
173 | ---------------------------- | |
174 | ||
175 | Quick answer: nothing. | |
176 | ||
177 | The GetElementPtr instruction dereferences nothing. That is, it doesn't access | |
178 | memory in any way. That's what the Load and Store instructions are for. GEP is | |
179 | only involved in the computation of addresses. For example, consider this: | |
180 | ||
181 | .. code-block:: llvm | |
182 | ||
183 | %MyVar = uninitialized global { [40 x i32 ]* } | |
184 | ... | |
185 | %idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17 | |
186 | ||
187 | In this example, we have a global variable, ``%MyVar`` that is a pointer to a | |
188 | structure containing a pointer to an array of 40 ints. The GEP instruction seems | |
189 | to be accessing the 18th integer of the structure's array of ints. However, this | |
190 | is actually an illegal GEP instruction. It won't compile. The reason is that the | |
970d7e83 | 191 | pointer in the structure *must* be dereferenced in order to index into the |
223e47cc LB |
192 | array of 40 ints. Since the GEP instruction never accesses memory, it is |
193 | illegal. | |
194 | ||
195 | In order to access the 18th integer in the array, you would need to do the | |
196 | following: | |
197 | ||
198 | .. code-block:: llvm | |
199 | ||
200 | %idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0 | |
201 | %arr = load [40 x i32]** %idx | |
202 | %idx = getelementptr [40 x i32]* %arr, i64 0, i64 17 | |
203 | ||
204 | In this case, we have to load the pointer in the structure with a load | |
205 | instruction before we can index into the array. If the example was changed to: | |
206 | ||
207 | .. code-block:: llvm | |
208 | ||
209 | %MyVar = uninitialized global { [40 x i32 ] } | |
210 | ... | |
211 | %idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17 | |
212 | ||
213 | then everything works fine. In this case, the structure does not contain a | |
214 | pointer and the GEP instruction can index through the global variable, into the | |
215 | first field of the structure and access the 18th ``i32`` in the array there. | |
216 | ||
217 | Why don't GEP x,0,0,1 and GEP x,1 alias? | |
218 | ---------------------------------------- | |
219 | ||
220 | Quick Answer: They compute different address locations. | |
221 | ||
222 | If you look at the first indices in these GEP instructions you find that they | |
223 | are different (0 and 1), therefore the address computation diverges with that | |
224 | index. Consider this example: | |
225 | ||
226 | .. code-block:: llvm | |
227 | ||
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 | |
231 | ||
232 | In this example, ``idx1`` computes the address of the second integer in the | |
233 | array that is in the structure in ``%MyVar``, that is ``MyVar+4``. The type of | |
234 | ``idx1`` is ``i32*``. However, ``idx2`` computes the address of *the next* | |
235 | structure after ``%MyVar``. The type of ``idx2`` is ``{ [10 x i32] }*`` and its | |
236 | value is equivalent to ``MyVar + 40`` because it indexes past the ten 4-byte | |
237 | integers in ``MyVar``. Obviously, in such a situation, the pointers don't | |
238 | alias. | |
239 | ||
240 | Why do GEP x,1,0,0 and GEP x,1 alias? | |
241 | ------------------------------------- | |
242 | ||
243 | Quick Answer: They compute the same address location. | |
244 | ||
245 | These two GEP instructions will compute the same address because indexing | |
246 | through the 0th element does not change the address. However, it does change the | |
247 | type. Consider this example: | |
248 | ||
249 | .. code-block:: llvm | |
250 | ||
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 | |
254 | ||
255 | In this example, the value of ``%idx1`` is ``%MyVar+40`` and its type is | |
256 | ``i32*``. The value of ``%idx2`` is also ``MyVar+40`` but its type is ``{ [10 x | |
257 | i32] }*``. | |
258 | ||
259 | Can GEP index into vector elements? | |
260 | ----------------------------------- | |
261 | ||
262 | This hasn't always been forcefully disallowed, though it's not recommended. It | |
263 | leads to awkward special cases in the optimizers, and fundamental inconsistency | |
264 | in the IR. In the future, it will probably be outright disallowed. | |
265 | ||
266 | What effect do address spaces have on GEPs? | |
267 | ------------------------------------------- | |
268 | ||
269 | None, except that the address space qualifier on the first operand pointer type | |
270 | always matches the address space qualifier on the result type. | |
271 | ||
272 | How is GEP different from ``ptrtoint``, arithmetic, and ``inttoptr``? | |
273 | --------------------------------------------------------------------- | |
274 | ||
275 | It's very similar; there are only subtle differences. | |
276 | ||
277 | With ptrtoint, you have to pick an integer type. One approach is to pick i64; | |
278 | this is safe on everything LLVM supports (LLVM internally assumes pointers are | |
279 | never wider than 64 bits in many places), and the optimizer will actually narrow | |
280 | the i64 arithmetic down to the actual pointer size on targets which don't | |
281 | support 64-bit arithmetic in most cases. However, there are some cases where it | |
282 | doesn't do this. With GEP you can avoid this problem. | |
283 | ||
284 | Also, GEP carries additional pointer aliasing rules. It's invalid to take a GEP | |
285 | from one object, address into a different separately allocated object, and | |
286 | dereference it. IR producers (front-ends) must follow this rule, and consumers | |
287 | (optimizers, specifically alias analysis) benefit from being able to rely on | |
288 | it. See the `Rules`_ section for more information. | |
289 | ||
290 | And, GEP is more concise in common cases. | |
291 | ||
292 | However, for the underlying integer computation implied, there is no | |
293 | difference. | |
294 | ||
295 | ||
296 | I'm writing a backend for a target which needs custom lowering for GEP. How do I do this? | |
297 | ----------------------------------------------------------------------------------------- | |
298 | ||
299 | You don't. The integer computation implied by a GEP is target-independent. | |
300 | Typically what you'll need to do is make your backend pattern-match expressions | |
301 | trees involving ADD, MUL, etc., which are what GEP is lowered into. This has the | |
302 | advantage of letting your code work correctly in more cases. | |
303 | ||
304 | GEP does use target-dependent parameters for the size and layout of data types, | |
305 | which targets can customize. | |
306 | ||
307 | If you require support for addressing units which are not 8 bits, you'll need to | |
308 | fix a lot of code in the backend, with GEP lowering being only a small piece of | |
309 | the overall picture. | |
310 | ||
311 | How does VLA addressing work with GEPs? | |
312 | --------------------------------------- | |
313 | ||
314 | GEPs don't natively support VLAs. LLVM's type system is entirely static, and GEP | |
315 | address computations are guided by an LLVM type. | |
316 | ||
317 | VLA indices can be implemented as linearized indices. For example, an expression | |
318 | like ``X[a][b][c]``, must be effectively lowered into a form like | |
319 | ``X[a*m+b*n+c]``, so that it appears to the GEP as a single-dimensional array | |
320 | reference. | |
321 | ||
322 | This means if you want to write an analysis which understands array indices and | |
323 | you want to support VLAs, your code will have to be prepared to reverse-engineer | |
324 | the linearization. One way to solve this problem is to use the ScalarEvolution | |
325 | library, which always presents VLA and non-VLA indexing in the same manner. | |
326 | ||
327 | .. _Rules: | |
328 | ||
329 | Rules | |
330 | ===== | |
331 | ||
332 | What happens if an array index is out of bounds? | |
333 | ------------------------------------------------ | |
334 | ||
335 | There are two senses in which an array index can be out of bounds. | |
336 | ||
337 | First, there's the array type which comes from the (static) type of the first | |
338 | operand to the GEP. Indices greater than the number of elements in the | |
339 | corresponding static array type are valid. There is no problem with out of | |
340 | bounds indices in this sense. Indexing into an array only depends on the size of | |
341 | the array element, not the number of elements. | |
342 | ||
343 | A common example of how this is used is arrays where the size is not known. | |
344 | It's common to use array types with zero length to represent these. The fact | |
345 | that the static type says there are zero elements is irrelevant; it's perfectly | |
346 | valid to compute arbitrary element indices, as the computation only depends on | |
347 | the size of the array element, not the number of elements. Note that zero-sized | |
348 | arrays are not a special case here. | |
349 | ||
350 | This sense is unconnected with ``inbounds`` keyword. The ``inbounds`` keyword is | |
351 | designed to describe low-level pointer arithmetic overflow conditions, rather | |
352 | than high-level array indexing rules. | |
353 | ||
354 | Analysis passes which wish to understand array indexing should not assume that | |
355 | the static array type bounds are respected. | |
356 | ||
357 | The second sense of being out of bounds is computing an address that's beyond | |
358 | the actual underlying allocated object. | |
359 | ||
360 | With the ``inbounds`` keyword, the result value of the GEP is undefined if the | |
361 | address is outside the actual underlying allocated object and not the address | |
362 | one-past-the-end. | |
363 | ||
364 | Without the ``inbounds`` keyword, there are no restrictions on computing | |
365 | out-of-bounds addresses. Obviously, performing a load or a store requires an | |
366 | address of allocated and sufficiently aligned memory. But the GEP itself is only | |
367 | concerned with computing addresses. | |
368 | ||
369 | Can array indices be negative? | |
370 | ------------------------------ | |
371 | ||
372 | Yes. This is basically a special case of array indices being out of bounds. | |
373 | ||
374 | Can I compare two values computed with GEPs? | |
375 | -------------------------------------------- | |
376 | ||
377 | Yes. If both addresses are within the same allocated object, or | |
378 | one-past-the-end, you'll get the comparison result you expect. If either is | |
379 | outside of it, integer arithmetic wrapping may occur, so the comparison may not | |
380 | be meaningful. | |
381 | ||
382 | Can I do GEP with a different pointer type than the type of the underlying object? | |
383 | ---------------------------------------------------------------------------------- | |
384 | ||
385 | Yes. There are no restrictions on bitcasting a pointer value to an arbitrary | |
386 | pointer type. The types in a GEP serve only to define the parameters for the | |
387 | underlying integer computation. They need not correspond with the actual type of | |
388 | the underlying object. | |
389 | ||
390 | Furthermore, loads and stores don't have to use the same types as the type of | |
391 | the underlying object. Types in this context serve only to specify memory size | |
392 | and alignment. Beyond that there are merely a hint to the optimizer indicating | |
393 | how the value will likely be used. | |
394 | ||
395 | Can I cast an object's address to integer and add it to null? | |
396 | ------------------------------------------------------------- | |
397 | ||
398 | You can compute an address that way, but if you use GEP to do the add, you can't | |
399 | use that pointer to actually access the object, unless the object is managed | |
400 | outside of LLVM. | |
401 | ||
402 | The underlying integer computation is sufficiently defined; null has a defined | |
403 | value --- zero --- and you can add whatever value you want to it. | |
404 | ||
405 | However, it's invalid to access (load from or store to) an LLVM-aware object | |
406 | with such a pointer. This includes ``GlobalVariables``, ``Allocas``, and objects | |
407 | pointed to by noalias pointers. | |
408 | ||
409 | If you really need this functionality, you can do the arithmetic with explicit | |
410 | integer instructions, and use inttoptr to convert the result to an address. Most | |
411 | of GEP's special aliasing rules do not apply to pointers computed from ptrtoint, | |
412 | arithmetic, and inttoptr sequences. | |
413 | ||
414 | Can I compute the distance between two objects, and add that value to one address to compute the other address? | |
415 | --------------------------------------------------------------------------------------------------------------- | |
416 | ||
970d7e83 | 417 | As with arithmetic on null, you can use GEP to compute an address that way, but |
223e47cc LB |
418 | you can't use that pointer to actually access the object if you do, unless the |
419 | object is managed outside of LLVM. | |
420 | ||
421 | Also as above, ptrtoint and inttoptr provide an alternative way to do this which | |
422 | do not have this restriction. | |
423 | ||
424 | Can I do type-based alias analysis on LLVM IR? | |
425 | ---------------------------------------------- | |
426 | ||
427 | You can't do type-based alias analysis using LLVM's built-in type system, | |
428 | because LLVM has no restrictions on mixing types in addressing, loads or stores. | |
429 | ||
430 | LLVM's type-based alias analysis pass uses metadata to describe a different type | |
431 | system (such as the C type system), and performs type-based aliasing on top of | |
432 | that. Further details are in the `language reference <LangRef.html#tbaa>`_. | |
433 | ||
434 | What happens if a GEP computation overflows? | |
435 | -------------------------------------------- | |
436 | ||
437 | If the GEP lacks the ``inbounds`` keyword, the value is the result from | |
438 | evaluating the implied two's complement integer computation. However, since | |
439 | there's no guarantee of where an object will be allocated in the address space, | |
440 | such values have limited meaning. | |
441 | ||
442 | If the GEP has the ``inbounds`` keyword, the result value is undefined (a "trap | |
443 | value") if the GEP overflows (i.e. wraps around the end of the address space). | |
444 | ||
445 | As such, there are some ramifications of this for inbounds GEPs: scales implied | |
446 | by array/vector/pointer indices are always known to be "nsw" since they are | |
447 | signed values that are scaled by the element size. These values are also | |
448 | allowed to be negative (e.g. "``gep i32 *%P, i32 -1``") but the pointer itself | |
449 | is logically treated as an unsigned value. This means that GEPs have an | |
450 | asymmetric relation between the pointer base (which is treated as unsigned) and | |
451 | the offset applied to it (which is treated as signed). The result of the | |
452 | additions within the offset calculation cannot have signed overflow, but when | |
453 | applied to the base pointer, there can be signed overflow. | |
454 | ||
455 | How can I tell if my front-end is following the rules? | |
456 | ------------------------------------------------------ | |
457 | ||
458 | There is currently no checker for the getelementptr rules. Currently, the only | |
459 | way to do this is to manually check each place in your front-end where | |
460 | GetElementPtr operators are created. | |
461 | ||
462 | It's not possible to write a checker which could find all rule violations | |
463 | statically. It would be possible to write a checker which works by instrumenting | |
464 | the code with dynamic checks though. Alternatively, it would be possible to | |
465 | write a static checker which catches a subset of possible problems. However, no | |
466 | such checker exists today. | |
467 | ||
468 | Rationale | |
469 | ========= | |
470 | ||
471 | Why is GEP designed this way? | |
472 | ----------------------------- | |
473 | ||
474 | The design of GEP has the following goals, in rough unofficial order of | |
475 | priority: | |
476 | ||
477 | * Support C, C-like languages, and languages which can be conceptually lowered | |
478 | into C (this covers a lot). | |
479 | ||
480 | * Support optimizations such as those that are common in C compilers. In | |
481 | particular, GEP is a cornerstone of LLVM's `pointer aliasing | |
482 | model <LangRef.html#pointeraliasing>`_. | |
483 | ||
484 | * Provide a consistent method for computing addresses so that address | |
485 | computations don't need to be a part of load and store instructions in the IR. | |
486 | ||
487 | * Support non-C-like languages, to the extent that it doesn't interfere with | |
488 | other goals. | |
489 | ||
490 | * Minimize target-specific information in the IR. | |
491 | ||
492 | Why do struct member indices always use ``i32``? | |
493 | ------------------------------------------------ | |
494 | ||
495 | The specific type i32 is probably just a historical artifact, however it's wide | |
496 | enough for all practical purposes, so there's been no need to change it. It | |
497 | doesn't necessarily imply i32 address arithmetic; it's just an identifier which | |
498 | identifies a field in a struct. Requiring that all struct indices be the same | |
499 | reduces the range of possibilities for cases where two GEPs are effectively the | |
500 | same but have distinct operand types. | |
501 | ||
502 | What's an uglygep? | |
503 | ------------------ | |
504 | ||
505 | Some LLVM optimizers operate on GEPs by internally lowering them into more | |
506 | primitive integer expressions, which allows them to be combined with other | |
507 | integer expressions and/or split into multiple separate integer expressions. If | |
508 | they've made non-trivial changes, translating back into LLVM IR can involve | |
509 | reverse-engineering the structure of the addressing in order to fit it into the | |
510 | static type of the original first operand. It isn't always possibly to fully | |
511 | reconstruct this structure; sometimes the underlying addressing doesn't | |
512 | correspond with the static type at all. In such cases the optimizer instead will | |
513 | emit a GEP with the base pointer casted to a simple address-unit pointer, using | |
514 | the name "uglygep". This isn't pretty, but it's just as valid, and it's | |
515 | sufficient to preserve the pointer aliasing guarantees that GEP provides. | |
516 | ||
517 | Summary | |
518 | ======= | |
519 | ||
520 | In summary, here's some things to always remember about the GetElementPtr | |
521 | instruction: | |
522 | ||
523 | ||
524 | #. The GEP instruction never accesses memory, it only provides pointer | |
525 | computations. | |
526 | ||
527 | #. The first operand to the GEP instruction is always a pointer and it must be | |
528 | indexed. | |
529 | ||
530 | #. There are no superfluous indices for the GEP instruction. | |
531 | ||
532 | #. Trailing zero indices are superfluous for pointer aliasing, but not for the | |
533 | types of the pointers. | |
534 | ||
535 | #. Leading zero indices are not superfluous for pointer aliasing nor the types | |
536 | of the pointers. |