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