Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | "http://www.w3.org/TR/html4/strict.dtd"> |
| 3 | <html> |
| 4 | <head> |
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| 6 | <title>The Often Misunderstood GEP Instruction</title> |
| 7 | <link rel="stylesheet" href="llvm.css" type="text/css"> |
Reid Spencer | f19ccf8 | 2006-08-10 21:01:14 +0000 | [diff] [blame] | 8 | <style type="text/css"> |
| 9 | TABLE { text-align: left; border: 1px solid black; border-collapse: collapse; margin: 0 0 0 0; } |
| 10 | </style> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 11 | </head> |
| 12 | <body> |
| 13 | |
| 14 | <div class="doc_title"> |
| 15 | The Often Misunderstood GEP Instruction |
| 16 | </div> |
| 17 | |
| 18 | <ol> |
| 19 | <li><a href="#intro">Introduction</a></li> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 20 | <li><a href="#addresses">Address Computation</a> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 21 | <ol> |
| 22 | <li><a href="#extra_index">Why is the extra 0 index required?</a></li> |
| 23 | <li><a href="#deref">What is dereferenced by GEP?</a></li> |
| 24 | <li><a href="#firstptr">Why can you index through the first pointer but not |
| 25 | subsequent ones?</a></li> |
| 26 | <li><a href="#lead0">Why don't GEP x,0,0,1 and GEP x,1 alias? </a></li> |
| 27 | <li><a href="#trail0">Why do GEP x,1,0,0 and GEP x,1 alias? </a></li> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 28 | <li><a href="#vectors">Can GEP index into vector elements?</a> |
| 29 | <li><a href="#unions">Can GEP index into unions?</a> |
| 30 | <li><a href="#addrspace">What effect do address spaces have on GEPs?</a> |
| 31 | <li><a href="#int">How is GEP different from ptrtoint, arithmetic, and inttoptr?</a></li> |
| 32 | <li><a href="#be">I'm writing a backend for a target which needs custom lowering for GEP. How do I do this?</a> |
| 33 | <li><a href="#vla">How does VLA addressing work with GEPs?</a> |
| 34 | </ol></li> |
| 35 | <li><a href="#rules">Rules</a> |
| 36 | <ol> |
| 37 | <li><a href="#bounds">What happens if an array index is out of bounds?</a> |
| 38 | <li><a href="#negative">Can array indices be negative?</a> |
| 39 | <li><a href="#compare">Can I compare two values computed with GEPs?</a> |
| 40 | <li><a href="#types">Can I do GEP with a different pointer type than the type of the underlying object?</a> |
| 41 | <li><a href="#null">Can I cast an object's address to integer and add it to null?</a> |
| 42 | <li><a href="#ptrdiff">Can I compute the distance between two objects, and add that value to one address to compute the other address?</a> |
| 43 | <li><a href="#tbaa">Can I do type-based alias analysis on LLVM IR?</a> |
| 44 | <li><a href="#overflow">What happens if a GEP computation overflows?</a> |
| 45 | <li><a href="#check">How can I tell if my front-end is following the rules?</a> |
| 46 | </ol></li> |
| 47 | <li><a href="#rationale">Rationale</a> |
| 48 | <ol> |
| 49 | <li><a href="#goals">Why is GEP designed this way?</a></li> |
| 50 | <li><a href="#i32">Why do struct member indices always use i32?</a></li> |
| 51 | <li><a href="#uglygep">What's an uglygep?</a> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 52 | </ol></li> |
| 53 | <li><a href="#summary">Summary</a></li> |
| 54 | </ol> |
| 55 | |
| 56 | <div class="doc_author"> |
| 57 | <p>Written by: <a href="mailto:rspencer@reidspencer.com">Reid Spencer</a>.</p> |
| 58 | </div> |
| 59 | |
| 60 | |
| 61 | <!-- *********************************************************************** --> |
| 62 | <div class="doc_section"><a name="intro"><b>Introduction</b></a></div> |
| 63 | <!-- *********************************************************************** --> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 64 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 65 | <div class="doc_text"> |
| 66 | <p>This document seeks to dispel the mystery and confusion surrounding LLVM's |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 67 | GetElementPtr (GEP) instruction. Questions about the wily GEP instruction are |
Benjamin Kramer | 8040cd3 | 2009-10-12 14:46:08 +0000 | [diff] [blame] | 68 | probably the most frequently occurring questions once a developer gets down to |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 69 | coding with LLVM. Here we lay out the sources of confusion and show that the |
| 70 | GEP instruction is really quite simple. |
| 71 | </p> |
| 72 | </div> |
| 73 | |
| 74 | <!-- *********************************************************************** --> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 75 | <div class="doc_section"><a name="addresses"><b>Address Computation</b></a></div> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 76 | <!-- *********************************************************************** --> |
| 77 | <div class="doc_text"> |
| 78 | <p>When people are first confronted with the GEP instruction, they tend to |
| 79 | relate it to known concepts from other programming paradigms, most notably C |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 80 | array indexing and field selection. GEP closely resembles C array indexing |
| 81 | and field selection, however it's is a little different and this leads to |
| 82 | the following questions.</p> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 83 | </div> |
| 84 | |
| 85 | <!-- *********************************************************************** --> |
| 86 | <div class="doc_subsection"> |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 87 | <a name="firstptr"><b>What is the first index of the GEP instruction?</b></a> |
| 88 | </div> |
| 89 | <div class="doc_text"> |
Reid Spencer | 80a4d05 | 2006-08-15 03:43:31 +0000 | [diff] [blame] | 90 | <p>Quick answer: The index stepping through the first operand.</p> |
| 91 | <p>The confusion with the first index usually arises from thinking about |
| 92 | the GetElementPtr instruction as if it was a C index operator. They aren't the |
| 93 | same. For example, when we write, in "C":</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 94 | |
| 95 | <div class="doc_code"> |
| 96 | <pre> |
| 97 | AType *Foo; |
| 98 | ... |
| 99 | X = &Foo->F; |
| 100 | </pre> |
| 101 | </div> |
| 102 | |
Reid Spencer | eda573d | 2006-08-15 04:00:29 +0000 | [diff] [blame] | 103 | <p>it is natural to think that there is only one index, the selection of the |
| 104 | field <tt>F</tt>. However, in this example, <tt>Foo</tt> is a pointer. That |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 105 | pointer must be indexed explicitly in LLVM. C, on the other hand, indices |
Jim Laskey | e3c312f | 2006-08-15 08:14:19 +0000 | [diff] [blame] | 106 | through it transparently. To arrive at the same address location as the C |
Reid Spencer | eda573d | 2006-08-15 04:00:29 +0000 | [diff] [blame] | 107 | code, you would provide the GEP instruction with two index operands. The |
| 108 | first operand indexes through the pointer; the second operand indexes the |
| 109 | field <tt>F</tt> of the structure, just as if you wrote:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 110 | |
| 111 | <div class="doc_code"> |
| 112 | <pre> |
| 113 | X = &Foo[0].F; |
| 114 | </pre> |
| 115 | </div> |
| 116 | |
Reid Spencer | 80a4d05 | 2006-08-15 03:43:31 +0000 | [diff] [blame] | 117 | <p>Sometimes this question gets rephrased as:</p> |
Chris Lattner | 4a5dfee | 2006-08-17 03:26:50 +0000 | [diff] [blame] | 118 | <blockquote><p><i>Why is it okay to index through the first pointer, but |
| 119 | subsequent pointers won't be dereferenced?</i></p></blockquote> |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 120 | <p>The answer is simply because memory does not have to be accessed to |
| 121 | perform the computation. The first operand to the GEP instruction must be a |
| 122 | value of a pointer type. The value of the pointer is provided directly to |
Reid Spencer | 1c6f87d | 2006-08-15 03:57:05 +0000 | [diff] [blame] | 123 | the GEP instruction as an operand without any need for accessing memory. It |
| 124 | must, therefore be indexed and requires an index operand. Consider this |
| 125 | example:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 126 | |
| 127 | <div class="doc_code"> |
| 128 | <pre> |
| 129 | struct munger_struct { |
| 130 | int f1; |
| 131 | int f2; |
| 132 | }; |
| 133 | void munge(struct munger_struct *P) { |
| 134 | P[0].f1 = P[1].f1 + P[2].f2; |
| 135 | } |
| 136 | ... |
| 137 | munger_struct Array[3]; |
| 138 | ... |
| 139 | munge(Array); |
| 140 | </pre> |
| 141 | </div> |
| 142 | |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 143 | <p>In this "C" example, the front end compiler (llvm-gcc) will generate three |
| 144 | GEP instructions for the three indices through "P" in the assignment |
| 145 | statement. The function argument <tt>P</tt> will be the first operand of each |
Reid Spencer | 1014647 | 2006-08-16 05:53:32 +0000 | [diff] [blame] | 146 | of these GEP instructions. The second operand indexes through that pointer. |
| 147 | The third operand will be the field offset into the |
| 148 | <tt>struct munger_struct</tt> type, for either the <tt>f1</tt> or |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 149 | <tt>f2</tt> field. So, in LLVM assembly the <tt>munge</tt> function looks |
| 150 | like:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 151 | |
| 152 | <div class="doc_code"> |
| 153 | <pre> |
| 154 | void %munge(%struct.munger_struct* %P) { |
| 155 | entry: |
| 156 | %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0 |
| 157 | %tmp = load i32* %tmp |
| 158 | %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1 |
| 159 | %tmp7 = load i32* %tmp6 |
| 160 | %tmp8 = add i32 %tmp7, %tmp |
| 161 | %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0 |
| 162 | store i32 %tmp8, i32* %tmp9 |
| 163 | ret void |
| 164 | } |
| 165 | </pre> |
| 166 | </div> |
| 167 | |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 168 | <p>In each case the first operand is the pointer through which the GEP |
| 169 | instruction starts. The same is true whether the first operand is an |
| 170 | argument, allocated memory, or a global variable. </p> |
| 171 | <p>To make this clear, let's consider a more obtuse example:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 172 | |
| 173 | <div class="doc_code"> |
| 174 | <pre> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 175 | %MyVar = uninitialized global i32 |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 176 | ... |
| 177 | %idx1 = getelementptr i32* %MyVar, i64 0 |
| 178 | %idx2 = getelementptr i32* %MyVar, i64 1 |
| 179 | %idx3 = getelementptr i32* %MyVar, i64 2 |
| 180 | </pre> |
| 181 | </div> |
| 182 | |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 183 | <p>These GEP instructions are simply making address computations from the |
| 184 | base address of <tt>MyVar</tt>. They compute, as follows (using C syntax): |
| 185 | </p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 186 | |
| 187 | <div class="doc_code"> |
| 188 | <pre> |
| 189 | idx1 = (char*) &MyVar + 0 |
| 190 | idx2 = (char*) &MyVar + 4 |
| 191 | idx3 = (char*) &MyVar + 8 |
| 192 | </pre> |
| 193 | </div> |
| 194 | |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 195 | <p>Since the type <tt>i32</tt> is known to be four bytes long, the indices |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 196 | 0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No |
| 197 | memory is accessed to make these computations because the address of |
| 198 | <tt>%MyVar</tt> is passed directly to the GEP instructions.</p> |
| 199 | <p>The obtuse part of this example is in the cases of <tt>%idx2</tt> and |
| 200 | <tt>%idx3</tt>. They result in the computation of addresses that point to |
| 201 | memory past the end of the <tt>%MyVar</tt> global, which is only one |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 202 | <tt>i32</tt> long, not three <tt>i32</tt>s long. While this is legal in LLVM, |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 203 | it is inadvisable because any load or store with the pointer that results |
| 204 | from these GEP instructions would produce undefined results.</p> |
| 205 | </div> |
| 206 | |
| 207 | <!-- *********************************************************************** --> |
| 208 | <div class="doc_subsection"> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 209 | <a name="extra_index"><b>Why is the extra 0 index required?</b></a> |
| 210 | </div> |
| 211 | <!-- *********************************************************************** --> |
| 212 | <div class="doc_text"> |
| 213 | <p>Quick answer: there are no superfluous indices.</p> |
| 214 | <p>This question arises most often when the GEP instruction is applied to a |
| 215 | global variable which is always a pointer type. For example, consider |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 216 | this:</p> |
| 217 | |
| 218 | <div class="doc_code"> |
| 219 | <pre> |
| 220 | %MyStruct = uninitialized global { float*, i32 } |
| 221 | ... |
| 222 | %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1 |
| 223 | </pre> |
| 224 | </div> |
| 225 | |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 226 | <p>The GEP above yields an <tt>i32*</tt> by indexing the <tt>i32</tt> typed |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 227 | field of the structure <tt>%MyStruct</tt>. When people first look at it, they |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 228 | wonder why the <tt>i64 0</tt> index is needed. However, a closer inspection |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 229 | of how globals and GEPs work reveals the need. Becoming aware of the following |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 230 | facts will dispel the confusion:</p> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 231 | <ol> |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 232 | <li>The type of <tt>%MyStruct</tt> is <i>not</i> <tt>{ float*, i32 }</tt> |
| 233 | but rather <tt>{ float*, i32 }*</tt>. That is, <tt>%MyStruct</tt> is a |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 234 | pointer to a structure containing a pointer to a <tt>float</tt> and an |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 235 | <tt>i32</tt>.</li> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 236 | <li>Point #1 is evidenced by noticing the type of the first operand of |
| 237 | the GEP instruction (<tt>%MyStruct</tt>) which is |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 238 | <tt>{ float*, i32 }*</tt>.</li> |
| 239 | <li>The first index, <tt>i64 0</tt> is required to step over the global |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 240 | variable <tt>%MyStruct</tt>. Since the first argument to the GEP |
| 241 | instruction must always be a value of pointer type, the first index |
| 242 | steps through that pointer. A value of 0 means 0 elements offset from that |
| 243 | pointer.</li> |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 244 | <li>The second index, <tt>i32 1</tt> selects the second field of the |
| 245 | structure (the <tt>i32</tt>). </li> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 246 | </ol> |
| 247 | </div> |
| 248 | |
| 249 | <!-- *********************************************************************** --> |
| 250 | <div class="doc_subsection"> |
| 251 | <a name="deref"><b>What is dereferenced by GEP?</b></a> |
| 252 | </div> |
| 253 | <div class="doc_text"> |
| 254 | <p>Quick answer: nothing.</p> |
| 255 | <p>The GetElementPtr instruction dereferences nothing. That is, it doesn't |
Reid Spencer | 919d371 | 2006-08-15 03:32:10 +0000 | [diff] [blame] | 256 | access memory in any way. That's what the Load and Store instructions are for. |
| 257 | GEP is only involved in the computation of addresses. For example, consider |
| 258 | this:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 259 | |
| 260 | <div class="doc_code"> |
| 261 | <pre> |
| 262 | %MyVar = uninitialized global { [40 x i32 ]* } |
| 263 | ... |
| 264 | %idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17 |
| 265 | </pre> |
| 266 | </div> |
| 267 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 268 | <p>In this example, we have a global variable, <tt>%MyVar</tt> that is a |
| 269 | pointer to a structure containing a pointer to an array of 40 ints. The |
Reid Spencer | 80a4d05 | 2006-08-15 03:43:31 +0000 | [diff] [blame] | 270 | GEP instruction seems to be accessing the 18th integer of the structure's |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 271 | array of ints. However, this is actually an illegal GEP instruction. It |
| 272 | won't compile. The reason is that the pointer in the structure <i>must</i> |
| 273 | be dereferenced in order to index into the array of 40 ints. Since the |
| 274 | GEP instruction never accesses memory, it is illegal.</p> |
| 275 | <p>In order to access the 18th integer in the array, you would need to do the |
| 276 | following:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 277 | |
| 278 | <div class="doc_code"> |
| 279 | <pre> |
| 280 | %idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0 |
| 281 | %arr = load [40 x i32]** %idx |
| 282 | %idx = getelementptr [40 x i32]* %arr, i64 0, i64 17 |
| 283 | </pre> |
| 284 | </div> |
| 285 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 286 | <p>In this case, we have to load the pointer in the structure with a load |
| 287 | instruction before we can index into the array. If the example was changed |
| 288 | to:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 289 | |
| 290 | <div class="doc_code"> |
| 291 | <pre> |
| 292 | %MyVar = uninitialized global { [40 x i32 ] } |
| 293 | ... |
| 294 | %idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17 |
| 295 | </pre> |
| 296 | </div> |
| 297 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 298 | <p>then everything works fine. In this case, the structure does not contain a |
Reid Spencer | 80a4d05 | 2006-08-15 03:43:31 +0000 | [diff] [blame] | 299 | pointer and the GEP instruction can index through the global variable, |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 300 | into the first field of the structure and access the 18th <tt>i32</tt> in the |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 301 | array there.</p> |
| 302 | </div> |
| 303 | |
| 304 | <!-- *********************************************************************** --> |
| 305 | <div class="doc_subsection"> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 306 | <a name="lead0"><b>Why don't GEP x,0,0,1 and GEP x,1 alias?</b></a> |
| 307 | </div> |
| 308 | <div class="doc_text"> |
| 309 | <p>Quick Answer: They compute different address locations.</p> |
| 310 | <p>If you look at the first indices in these GEP |
| 311 | instructions you find that they are different (0 and 1), therefore the address |
| 312 | computation diverges with that index. Consider this example:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 313 | |
| 314 | <div class="doc_code"> |
| 315 | <pre> |
| 316 | %MyVar = global { [10 x i32 ] } |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 317 | %idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1 |
| 318 | %idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1 |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 319 | </pre> |
| 320 | </div> |
| 321 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 322 | <p>In this example, <tt>idx1</tt> computes the address of the second integer |
Misha Brukman | fc13d1c | 2009-08-18 19:18:40 +0000 | [diff] [blame] | 323 | in the array that is in the structure in <tt>%MyVar</tt>, that is |
| 324 | <tt>MyVar+4</tt>. The type of <tt>idx1</tt> is <tt>i32*</tt>. However, |
| 325 | <tt>idx2</tt> computes the address of <i>the next</i> structure after |
| 326 | <tt>%MyVar</tt>. The type of <tt>idx2</tt> is <tt>{ [10 x i32] }*</tt> and its |
| 327 | value is equivalent to <tt>MyVar + 40</tt> because it indexes past the ten |
| 328 | 4-byte integers in <tt>MyVar</tt>. Obviously, in such a situation, the |
| 329 | pointers don't alias.</p> |
| 330 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 331 | </div> |
| 332 | |
| 333 | <!-- *********************************************************************** --> |
| 334 | <div class="doc_subsection"> |
Jim Laskey | 19af0e1 | 2006-08-15 12:15:08 +0000 | [diff] [blame] | 335 | <a name="trail0"><b>Why do GEP x,1,0,0 and GEP x,1 alias?</b></a> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 336 | </div> |
| 337 | <div class="doc_text"> |
| 338 | <p>Quick Answer: They compute the same address location.</p> |
| 339 | <p>These two GEP instructions will compute the same address because indexing |
| 340 | through the 0th element does not change the address. However, it does change |
| 341 | the type. Consider this example:</p> |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 342 | |
| 343 | <div class="doc_code"> |
| 344 | <pre> |
| 345 | %MyVar = global { [10 x i32 ] } |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 346 | %idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0 |
| 347 | %idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1 |
Bill Wendling | 3275908 | 2008-01-04 12:04:32 +0000 | [diff] [blame] | 348 | </pre> |
| 349 | </div> |
| 350 | |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 351 | <p>In this example, the value of <tt>%idx1</tt> is <tt>%MyVar+40</tt> and |
Reid Spencer | b913a51 | 2007-02-09 17:56:02 +0000 | [diff] [blame] | 352 | its type is <tt>i32*</tt>. The value of <tt>%idx2</tt> is also |
| 353 | <tt>MyVar+40</tt> but its type is <tt>{ [10 x i32] }*</tt>.</p> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 354 | </div> |
| 355 | |
| 356 | <!-- *********************************************************************** --> |
Dan Gohman | b02c08c | 2010-02-25 18:16:03 +0000 | [diff] [blame] | 357 | |
| 358 | <div class="doc_subsection"> |
| 359 | <a name="vectors"><b>Can GEP index into vector elements?</b></a> |
| 360 | </div> |
| 361 | <div class="doc_text"> |
| 362 | <p>This hasn't always been forcefully disallowed, though it's not recommended. |
| 363 | It leads to awkward special cases in the optimizers, and fundamental |
| 364 | inconsistency in the IR. In the future, it will probably be outright |
| 365 | disallowed.</p> |
| 366 | |
| 367 | </div> |
| 368 | |
| 369 | <!-- *********************************************************************** --> |
| 370 | |
| 371 | <div class="doc_subsection"> |
| 372 | <a name="unions"><b>Can GEP index into unions?</b></a> |
| 373 | </div> |
| 374 | <div class="doc_text"> |
| 375 | <p>Unknown.</p> |
| 376 | |
| 377 | </div> |
| 378 | |
| 379 | <!-- *********************************************************************** --> |
| 380 | |
| 381 | <div class="doc_subsection"> |
| 382 | <a name="addrspace"><b>What effect do address spaces have on GEPs?</b></a> |
| 383 | </div> |
| 384 | <div class="doc_text"> |
| 385 | <p>None, except that the address space qualifier on the first operand pointer |
| 386 | type always matches the address space qualifier on the result type.</p> |
| 387 | |
| 388 | </div> |
| 389 | |
| 390 | <!-- *********************************************************************** --> |
| 391 | |
| 392 | <div class="doc_subsection"> |
| 393 | <a name="int"><b>How is GEP different from ptrtoint, arithmetic, |
| 394 | and inttoptr?</b></a> |
| 395 | </div> |
| 396 | <div class="doc_text"> |
| 397 | <p>It's very similar; there are only subtle differences.</p> |
| 398 | |
| 399 | <p>With ptrtoint, you have to pick an integer type. One approach is to pick i64; |
| 400 | this is safe on everything LLVM supports (LLVM internally assumes pointers |
| 401 | are never wider than 64 bits in many places), and the optimizer will actually |
| 402 | narrow the i64 arithmetic down to the actual pointer size on targets which |
| 403 | don't support 64-bit arithmetic in most cases. However, there are some cases |
| 404 | where it doesn't do this. With GEP you can avoid this problem. |
| 405 | |
| 406 | <p>Also, GEP carries additional pointer aliasing rules. It's invalid to take a |
| 407 | GEP from one object, address into a different separately allocated |
| 408 | object, and dereference it. IR producers (front-ends) must follow this rule, |
| 409 | and consumers (optimizers, specifically alias analysis) benefit from being |
| 410 | able to rely on it. See the <a href="#rules">Rules</a> section for more |
| 411 | information.</p> |
| 412 | |
| 413 | <p>And, GEP is more concise in common cases.</p> |
| 414 | |
| 415 | <p>However, for the underlying integer computation implied, there |
| 416 | is no difference.</p> |
| 417 | |
| 418 | </div> |
| 419 | |
| 420 | <!-- *********************************************************************** --> |
| 421 | |
| 422 | <div class="doc_subsection"> |
| 423 | <a name="be"><b>I'm writing a backend for a target which needs custom |
| 424 | lowering for GEP. How do I do this?</b></a> |
| 425 | </div> |
| 426 | <div class="doc_text"> |
| 427 | <p>You don't. The integer computation implied by a GEP is target-independent. |
| 428 | Typically what you'll need to do is make your backend pattern-match |
| 429 | expressions trees involving ADD, MUL, etc., which are what GEP is lowered |
| 430 | into. This has the advantage of letting your code work correctly in more |
| 431 | cases.</p> |
| 432 | |
| 433 | <p>GEP does use target-dependent parameters for the size and layout of data |
| 434 | types, which targets can customize.</p> |
| 435 | |
| 436 | <p>If you require support for addressing units which are not 8 bits, you'll |
| 437 | need to fix a lot of code in the backend, with GEP lowering being only a |
| 438 | small piece of the overall picture.</p> |
| 439 | |
| 440 | </div> |
| 441 | |
| 442 | <!-- *********************************************************************** --> |
| 443 | |
| 444 | <div class="doc_subsection"> |
| 445 | <a name="vla"><b>How does VLA addressing work with GEPs?</b></a> |
| 446 | </div> |
| 447 | <div class="doc_text"> |
| 448 | <p>GEPs don't natively support VLAs. LLVM's type system is entirely static, |
| 449 | and GEP address computations are guided by an LLVM type.</p> |
| 450 | |
| 451 | <p>VLA indices can be implemented as linearized indices. For example, an |
| 452 | expression like X[a][b][c], must be effectively lowered into a form |
| 453 | like X[a*m+b*n+c], so that it appears to the GEP as a single-dimensional |
| 454 | array reference.</p> |
| 455 | |
| 456 | <p>This means if you want to write an analysis which understands array |
| 457 | indices and you want to support VLAs, your code will have to be |
| 458 | prepared to reverse-engineer the linearization. One way to solve this |
| 459 | problem is to use the ScalarEvolution library, which always presents |
| 460 | VLA and non-VLA indexing in the same manner.</p> |
| 461 | </div> |
| 462 | |
| 463 | <!-- *********************************************************************** --> |
| 464 | <div class="doc_section"><a name="rules"><b>Rules</b></a></div> |
| 465 | <!-- *********************************************************************** --> |
| 466 | |
| 467 | <!-- *********************************************************************** --> |
| 468 | |
| 469 | <div class="doc_subsection"> |
| 470 | <a name="bounds"><b>What happens if an array index is out of bounds?</b></a> |
| 471 | </div> |
| 472 | <div class="doc_text"> |
| 473 | <p>There are two senses in which an array index can be out of bounds.</p> |
| 474 | |
| 475 | <p>First, there's the array type which comes from the (static) type of |
| 476 | the first operand to the GEP. Indices greater than the number of elements |
| 477 | in the corresponding static array type are valid. There is no problem with |
| 478 | out of bounds indices in this sense. Indexing into an array only depends |
| 479 | on the size of the array element, not the number of elements.</p> |
| 480 | |
| 481 | <p>A common example of how this is used is arrays where the size is not known. |
| 482 | It's common to use array types with zero length to represent these. The |
| 483 | fact that the static type says there are zero elements is irrelevant; it's |
| 484 | perfectly valid to compute arbitrary element indices, as the computation |
| 485 | only depends on the size of the array element, not the number of |
| 486 | elements. Note that zero-sized arrays are not a special case here.</p> |
| 487 | |
| 488 | <p>This sense is unconnected with <tt>inbounds</tt> keyword. The |
| 489 | <tt>inbounds</tt> keyword is designed to describe low-level pointer |
| 490 | arithmetic overflow conditions, rather than high-level array |
| 491 | indexing rules. |
| 492 | |
| 493 | <p>Analysis passes which wish to understand array indexing should not |
| 494 | assume that the static array type bounds are respected.</p> |
| 495 | |
| 496 | <p>The second sense of being out of bounds is computing an address that's |
| 497 | beyond the actual underlying allocated object.</p> |
| 498 | |
| 499 | <p>With the <tt>inbounds</tt> keyword, the result value of the GEP is |
| 500 | undefined if the address is outside the actual underlying allocated |
| 501 | object and not the address one-past-the-end.</p> |
| 502 | |
| 503 | <p>Without the <tt>inbounds</tt> keyword, there are no restrictions |
| 504 | on computing out-of-bounds addresses. Obviously, performing a load or |
| 505 | a store requires an address of allocated and sufficiently aligned |
| 506 | memory. But the GEP itself is only concerned with computing addresses.</p> |
| 507 | |
| 508 | </div> |
| 509 | |
| 510 | <!-- *********************************************************************** --> |
| 511 | <div class="doc_subsection"> |
| 512 | <a name="negative"><b>Can array indices be negative?</b></a> |
| 513 | </div> |
| 514 | <div class="doc_text"> |
| 515 | <p>Yes. This is basically a special case of array indices being out |
| 516 | of bounds.</p> |
| 517 | |
| 518 | </div> |
| 519 | |
| 520 | <!-- *********************************************************************** --> |
| 521 | <div class="doc_subsection"> |
| 522 | <a name="compare"><b>Can I compare two values computed with GEPs?</b></a> |
| 523 | </div> |
| 524 | <div class="doc_text"> |
| 525 | <p>Yes. If both addresses are within the same allocated object, or |
| 526 | one-past-the-end, you'll get the comparison result you expect. If either |
| 527 | is outside of it, integer arithmetic wrapping may occur, so the |
| 528 | comparison may not be meaningful.</p> |
| 529 | |
| 530 | </div> |
| 531 | |
| 532 | <!-- *********************************************************************** --> |
| 533 | <div class="doc_subsection"> |
| 534 | <a name="types"><b>Can I do GEP with a different pointer type than the type of |
| 535 | the underlying object?</b></a> |
| 536 | </div> |
| 537 | <div class="doc_text"> |
| 538 | <p>Yes. There are no restrictions on bitcasting a pointer value to an arbitrary |
| 539 | pointer type. The types in a GEP serve only to define the parameters for the |
| 540 | underlying integer computation. They need not correspond with the actual |
| 541 | type of the underlying object.</p> |
| 542 | |
| 543 | <p>Furthermore, loads and stores don't have to use the same types as the type |
| 544 | of the underlying object. Types in this context serve only to specify |
| 545 | memory size and alignment. Beyond that there are merely a hint to the |
| 546 | optimizer indicating how the value will likely be used.</p> |
| 547 | |
| 548 | </div> |
| 549 | |
| 550 | <!-- *********************************************************************** --> |
| 551 | <div class="doc_subsection"> |
| 552 | <a name="null"><b>Can I cast an object's address to integer and add it |
| 553 | to null?</b></a> |
| 554 | </div> |
| 555 | <div class="doc_text"> |
| 556 | <p>You can compute an address that way, but if you use GEP to do the add, |
| 557 | you can't use that pointer to actually access the object, unless the |
| 558 | object is managed outside of LLVM.</p> |
| 559 | |
| 560 | <p>The underlying integer computation is sufficiently defined; null has a |
| 561 | defined value -- zero -- and you can add whatever value you want to it.</p> |
| 562 | |
| 563 | <p>However, it's invalid to access (load from or store to) an LLVM-aware |
| 564 | object with such a pointer. This includes GlobalVariables, Allocas, and |
| 565 | objects pointed to by noalias pointers.</p> |
| 566 | |
| 567 | <p>If you really need this functionality, you can do the arithmetic with |
| 568 | explicit integer instructions, and use inttoptr to convert the result to |
| 569 | an address. Most of GEP's special aliasing rules do not apply to pointers |
| 570 | computed from ptrtoint, arithmetic, and inttoptr sequences.</p> |
| 571 | |
| 572 | </div> |
| 573 | |
| 574 | <!-- *********************************************************************** --> |
| 575 | <div class="doc_subsection"> |
| 576 | <a name="ptrdiff"><b>Can I compute the distance between two objects, and add |
| 577 | that value to one address to compute the other address?</b></a> |
| 578 | </div> |
| 579 | <div class="doc_text"> |
| 580 | <p>As with arithmetic on null, You can use GEP to compute an address that |
| 581 | way, but you can't use that pointer to actually access the object if you |
| 582 | do, unless the object is managed outside of LLVM.</p> |
| 583 | |
| 584 | <p>Also as above, ptrtoint and inttoptr provide an alternative way to do this |
| 585 | which do not have this restriction.</p> |
| 586 | |
| 587 | </div> |
| 588 | |
| 589 | <!-- *********************************************************************** --> |
| 590 | <div class="doc_subsection"> |
| 591 | <a name="tbaa"><b>Can I do type-based alias analysis on LLVM IR?</b></a> |
| 592 | </div> |
| 593 | <div class="doc_text"> |
| 594 | <p>You can't do type-based alias analysis using LLVM's built-in type system, |
| 595 | because LLVM has no restrictions on mixing types in addressing, loads or |
| 596 | stores.</p> |
| 597 | |
| 598 | <p>It would be possible to add special annotations to the IR, probably using |
| 599 | metadata, to describe a different type system (such as the C type system), |
| 600 | and do type-based aliasing on top of that. This is a much bigger |
| 601 | undertaking though.</p> |
| 602 | |
| 603 | </div> |
| 604 | |
| 605 | <!-- *********************************************************************** --> |
| 606 | |
| 607 | <div class="doc_subsection"> |
| 608 | <a name="overflow"><b>What happens if a GEP computation overflows?</b></a> |
| 609 | </div> |
| 610 | <div class="doc_text"> |
| 611 | <p>If the GEP has the <tt>inbounds</tt> keyword, the result value is |
| 612 | undefined.</p> |
| 613 | |
| 614 | <p>Otherwise, the result value is the result from evaluating the implied |
| 615 | two's complement integer computation. However, since there's no |
| 616 | guarantee of where an object will be allocated in the address space, |
| 617 | such values have limited meaning.</p> |
| 618 | |
| 619 | </div> |
| 620 | |
| 621 | <!-- *********************************************************************** --> |
| 622 | |
| 623 | <div class="doc_subsection"> |
| 624 | <a name="check"><b>How can I tell if my front-end is following the |
| 625 | rules?</b></a> |
| 626 | </div> |
| 627 | <div class="doc_text"> |
| 628 | <p>There is currently no checker for the getelementptr rules. Currently, |
| 629 | the only way to do this is to manually check each place in your front-end |
| 630 | where GetElementPtr operators are created.</p> |
| 631 | |
| 632 | <p>It's not possible to write a checker which could find all rule |
| 633 | violations statically. It would be possible to write a checker which |
| 634 | works by instrumenting the code with dynamic checks though. Alternatively, |
| 635 | it would be possible to write a static checker which catches a subset of |
| 636 | possible problems. However, no such checker exists today.</p> |
| 637 | |
| 638 | </div> |
| 639 | |
| 640 | <!-- *********************************************************************** --> |
| 641 | <div class="doc_section"><a name="rationale"><b>Rationale</b></a></div> |
| 642 | <!-- *********************************************************************** --> |
| 643 | |
| 644 | <!-- *********************************************************************** --> |
| 645 | |
| 646 | <div class="doc_subsection"> |
| 647 | <a name="goals"><b>Why is GEP designed this way?</b></a> |
| 648 | </div> |
| 649 | <div class="doc_text"> |
| 650 | <p>The design of GEP has the following goals, in rough unofficial |
| 651 | order of priority:</p> |
| 652 | <ul> |
| 653 | <li>Support C, C-like languages, and languages which can be |
| 654 | conceptually lowered into C (this covers a lot).</li> |
| 655 | <li>Support optimizations such as those that are common in |
| 656 | C compilers.</li> |
| 657 | <li>Provide a consistent method for computing addresses so that |
| 658 | address computations don't need to be a part of load and |
| 659 | store instructions in the IR.</li> |
| 660 | <li>Support non-C-like languages, to the extent that it doesn't |
| 661 | interfere with other goals.</li> |
| 662 | <li>Minimize target-specific information in the IR.</li> |
| 663 | </ul> |
| 664 | </div> |
| 665 | |
| 666 | <!-- *********************************************************************** --> |
| 667 | <div class="doc_subsection"> |
| 668 | <a name="i32"><b>Why do struct member indices always use i32?</b></a> |
| 669 | </div> |
| 670 | <div class="doc_text"> |
| 671 | <p>The specific type i32 is probably just a historical artifact, however it's |
| 672 | wide enough for all practical purposes, so there's been no need to change it. |
| 673 | It doesn't necessarily imply i32 address arithmetic; it's just an identifier |
| 674 | which identifies a field in a struct. Requiring that all struct indices be |
| 675 | the same reduces the range of possibilities for cases where two GEPs are |
| 676 | effectively the same but have distinct operand types.</p> |
| 677 | |
| 678 | </div> |
| 679 | |
| 680 | <!-- *********************************************************************** --> |
| 681 | |
| 682 | <div class="doc_subsection"> |
| 683 | <a name="uglygep"><b>What's an uglygep?</b></a> |
| 684 | </div> |
| 685 | <div class="doc_text"> |
| 686 | <p>Some LLVM optimizers operate on GEPs by internally lowering them into |
| 687 | more primitive integer expressions, which allows them to be combined |
| 688 | with other integer expressions and/or split into multiple separate |
| 689 | integer expressions. If they've made non-trivial changes, translating |
| 690 | back into LLVM IR can involve reverse-engineering the structure of |
| 691 | the addressing in order to fit it into the static type of the original |
| 692 | first operand. It isn't always possibly to fully reconstruct this |
| 693 | structure; sometimes the underlying addressing doesn't correspond with |
| 694 | the static type at all. In such cases the optimizer instead will emit |
| 695 | a GEP with the base pointer casted to a simple address-unit pointer, |
| 696 | using the name "uglygep". This isn't pretty, but it's just as |
| 697 | valid, and it's sufficient to preserve the pointer aliasing guarantees |
| 698 | that GEP provides.</p> |
| 699 | |
| 700 | </div> |
| 701 | |
| 702 | <!-- *********************************************************************** --> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 703 | <div class="doc_section"><a name="summary"><b>Summary</b></a></div> |
| 704 | <!-- *********************************************************************** --> |
| 705 | |
| 706 | <div class="doc_text"> |
| 707 | <p>In summary, here's some things to always remember about the GetElementPtr |
| 708 | instruction:</p> |
| 709 | <ol> |
| 710 | <li>The GEP instruction never accesses memory, it only provides pointer |
| 711 | computations.</li> |
| 712 | <li>The first operand to the GEP instruction is always a pointer and it must |
| 713 | be indexed.</li> |
| 714 | <li>There are no superfluous indices for the GEP instruction.</li> |
| 715 | <li>Trailing zero indices are superfluous for pointer aliasing, but not for |
| 716 | the types of the pointers.</li> |
| 717 | <li>Leading zero indices are not superfluous for pointer aliasing nor the |
| 718 | types of the pointers.</li> |
| 719 | </ol> |
| 720 | </div> |
| 721 | |
| 722 | <!-- *********************************************************************** --> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 723 | |
| 724 | <hr> |
| 725 | <address> |
| 726 | <a href="http://jigsaw.w3.org/css-validator/check/referer"><img |
Misha Brukman | 4440870 | 2008-12-11 17:34:48 +0000 | [diff] [blame] | 727 | src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 728 | <a href="http://validator.w3.org/check/referer"><img |
Misha Brukman | f00ddb0 | 2008-12-11 18:23:24 +0000 | [diff] [blame] | 729 | src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> |
Reid Spencer | e00906f | 2006-08-10 20:15:58 +0000 | [diff] [blame] | 730 | <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br/> |
| 731 | Last modified: $Date$ |
| 732 | </address> |
| 733 | </body> |
| 734 | </html> |