[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.14 -> 1.15
---
Log message:
int -> i32, etc.
---
Diffs of the changes: (+43 -43)
GetElementPtr.html | 86 ++---
1 files changed, 43 insertions(+), 43 deletions(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.14 llvm/docs/GetElementPtr.html:1.15
--- llvm/docs/GetElementPtr.html:1.14 Wed Aug 16 22:26:50 2006
+++ llvm/docs/GetElementPtr.htmlFri Feb 9 11:56:02 2007
@@ -120,13 +120,13 @@
void %munge(%struct.munger_struct* %P) {
entry:
-%tmp = getelementptr %struct.munger_struct* %P, int 1, uint 0
-%tmp = load int* %tmp
-%tmp6 = getelementptr %struct.munger_struct* %P, int 2, uint 1
-%tmp7 = load int* %tmp6
-%tmp8 = add int %tmp7, %tmp
-%tmp9 = getelementptr %struct.munger_struct* %P, int 0, uint 0
-store int %tmp8, int* %tmp9
+%tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
+%tmp = load i32* %tmp
+%tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
+%tmp7 = load i32* %tmp6
+%tmp8 = add i32 %tmp7, %tmp
+%tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
+store i32 %tmp8, i32* %tmp9
ret void
}
In each case the first operand is the pointer through which the GEP
@@ -134,11 +134,11 @@
argument, allocated memory, or a global variable.
To make this clear, let's consider a more obtuse example:
- %MyVar = unintialized global int
+ %MyVar = unintialized global i32
...
- %idx1 = getelementptr int* %MyVar, long 0
- %idx2 = getelementptr int* %MyVar, long 1
- %idx3 = getelementptr int* %MyVar, long 2
+ %idx1 = getelementptr i32* %MyVar, i64 0
+ %idx2 = getelementptr i32* %MyVar, i64 1
+ %idx3 = getelementptr i32* %MyVar, i64 2
These GEP instructions are simply making address computations from the
base address of MyVar. They compute, as follows (using C syntax):
@@ -147,14 +147,14 @@
idx2 = (char*) &MyVar + 4
idx3 = (char*) &MyVar + 8
- Since the type int is known to be four bytes long, the indices
+ Since the type i32 is known to be four bytes long, the indices
0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No
memory is accessed to make these computations because the address of
%MyVar is passed directly to the GEP instructions.
The obtuse part of this example is in the cases of %idx2 and
%idx3. They result in the computation of addresses that point to
memory past the end of the %MyVar global, which is only one
- int long, not three ints long. While this is legal in
LLVM,
+ i32 long, not three i32s long. While this is legal in
LLVM,
it is inadvisable because any load or store with the pointer that results
from these GEP instructions would produce undefined results.
@@ -169,29 +169,29 @@
This question arises most often when the GEP instruction is applied to a
global variable which is always a pointer type. For example, consider
this:
- %MyStruct = uninitialized global { float*, int }
+ %MyStruct = uninitialized global { float*, i32 }
...
- %idx = getelementptr { float*, int }* %MyStruct, long 0, ubyte 1
- The GEP above yields an int* by indexing the int typed
+ %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1
+ The GEP above yields an i32* by indexing the i32 typed
field of the structure %MyStruct. When people first look at it,
they
- wonder why the long 0 index is needed. However, a closer inspection
+ wonder why the i64 0 index is needed. However, a closer inspection
of how globals and GEPs work reveals the need. Becoming aware of the
following
facts will dispell the confusion:
-The type of %MyStruct is not { float*, int }
-but rather { float*, int }*. That is, %MyStruct is a
+The type of %MyStruct is not { float*, i32 }
+but rather { float*, i32 }*. That is, %MyStruct is a
pointer to a structure containing a pointer to a float and an
-int.
+i32.
Point #1 is evidenced by noticing the type of the first operand of
the GEP instruction (%MyStruct) which is
-{ float*, int }*.
-The first index, long 0 is required to step over the global
+{ float*, i32 }*.
+The first index, i64 0 is required to step over the global
variable %MyStruct. Since the first argument to the GEP
instruction must always be a value of pointer type, the first index
steps through that pointer. A value of 0 means 0 elements offset from that
pointer.
-The second index, ubyte 1 selects the second field of the
-structure (the int).
+The second index, i32 1 selects the second field of the
+structure (the i32).
@@ -206,9 +206,9 @@
GEP is only involved in the computation of addresses. For example, consider
this:
- %MyVar = uninitialized global { [40 x int ]* }
+ %MyVar = uninitialized global { [40 x i32 ]* }
.
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.13 -> 1.14 --- Log message: Fix validation problem --- Diffs of the changes: (+3 -3) GetElementPtr.html |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.13 llvm/docs/GetElementPtr.html:1.14 --- llvm/docs/GetElementPtr.html:1.13 Wed Aug 16 22:25:07 2006 +++ llvm/docs/GetElementPtr.htmlWed Aug 16 22:26:50 2006 @@ -88,8 +88,8 @@ X = &Foo[0].F; Sometimes this question gets rephrased as: - Why is it okay to index through the first pointer, but - subsequent pointers won't be dereferenced? + Why is it okay to index through the first pointer, but + subsequent pointers won't be dereferenced? The answer is simply because memory does not have to be accessed to perform the computation. The first operand to the GEP instruction must be a value of a pointer type. The value of the pointer is provided directly to @@ -305,7 +305,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/17 03:25:07 $ + Last modified: $Date: 2006/08/17 03:26:50 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.12 -> 1.13
---
Log message:
remove IRC transcript. Anything still misunderstood after the faq is read
can be added to the faq.
---
Diffs of the changes: (+1 -327)
GetElementPtr.html | 328 -
1 files changed, 1 insertion(+), 327 deletions(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.12 llvm/docs/GetElementPtr.html:1.13
--- llvm/docs/GetElementPtr.html:1.12 Wed Aug 16 00:53:32 2006
+++ llvm/docs/GetElementPtr.htmlWed Aug 16 22:25:07 2006
@@ -297,332 +297,6 @@
-Appendix:
Discussion
-
-
- The following is a real discussion from the
- #llvm IRC channel about the GEP
- instruction. You may find this instructive as it was the basis for this
- document.
-
-UserComment
-YorionIf x & y must alias, are [ getelementptr
x,0,0,1,2 ] and [ getelementptr x,1,2 ] aliased? (they obviously have different
types, but they should alias...)
-Yorionoops, for the second one I meant [ getelementptr
y,1,2 ]
-ReidI don't see how that could be, Yorion but I'm not the
authority on this
-Yorionhmm..
-Reidthe two geps, by definition, are going to produce
different pointers which are not aliased
-Yorionwould [ GEP x,1,0 ] and [ GEP y,1 ] be
aliased?
-Reidif the second gep was [gep y,0,0,1,2] then they
should be aliased as well
-Reidno, I wouldn't expect that to work either :)
-Reidyou can't just arbitrarily drop leading or trailing
indices :)
-Reid(.. leading or trailing 0 indices, I mean)
-Reidthis instruction walks through a data structure and
generates a pointer to the resulting thing
-Reidif the number of indices are different, you're ending
up at a different place and by definition they'll have different
addresses
-Yorionoh, I see, because of different types, [ GEP x,0,1 ]
-& [ GEP x,1 ] actually might refer to different fields, but might
also refer to the same ones...
-Reidor, at least, that's my crude understanding of it
:)
-Reidno, they'll definitely refer to different
fields
-nicholasGEP x,0,1 ==> &((*(x+0))+1)? vs. GEP x,1
==> &(*(x+1))?
-Reidlemme grok that for a sec
-Reidthat might be true in some limited definition of x,
but it wouldn't be generally
-nicholasoh. fields of different sizes in a
structure.
-Reidyup
-Yorionis perhaps the type unification the reason why [
GEP x,0,1 ] and [ GEP x,1 ] cannot alias?
-Reidno
-Reidthey may or may not have the same type, but they are
definitely different pointers
-Reidlets use a concrete example for "x"
-Reidsuppose x is "struct {int a, float b} *"
-ReidGEP X,0,1 is going to return the address of
b
-ReidGEP X,1 is going to return the address of the
*second* "a" (after the first b)
-Yorionah, I see...
-Yoriontrailing zeros are still a bit confusing...
-Reidsame thing .. you're just selecting the 0th member of
an array or structure
-Yorionyou don't move away from the pointer, only the type
is changed
-Reidno, you still move away from the pointer .. the type
might change, or not
-Reidthe pointer definitely changes
-Reidlets look at an example for trailing zero
-Reidsuppose x is "int x[10][10][10][10]" (in C)
-ReidGEP X,0,0 will yield you a 3 dimensional
array
-ReidGEP X,0,0,0,0,0 will yield you an "int"
-Reidmake sense?
-Yorionyes
-Reidso, I think there's a law here: if the number of
indices in two GEP instructions are not equivalent, there is no way the
resulting pointers can alias
-Reid(assuming the x and y alias)
-YorionI was confused with some code in BasicAliasAnalysis
that says that two pointers are equal if they differ only in trailing
zeros
-YorionBasicAliasAnalysis.cpp:504-518
-Reidlemme look
-nicholasif y1 = GEP X, 0, 0 and y2 = GEP X, 0, 0, 0, 0, 0
(from Reid's example)
-nicholasthen doesn't *y1 and *y2 both refer to the same
"int"?
-Reidthey shouldn't
-Reidhmm .. actually, maybe you're right :)
-Reidthey definitely have different *types*
-Yoriontrue
-nicholasdifferent types just doesn't cut it. :)
-Reid.. thinking on this :)
-nicholassimilarly, i could create a yucky with a struct
that has a char *, then have you GEP right through the pointer into the
pointed-to data. That could mean that the resulting point might alias
anything.
-Yorionmy theory (after reading BAA) is that all zeros can
be omitted, and that the pointers alias if they have the same sequence of
indices
-Yorionhowever, this screws the typing, so that's why
zeros are for
-Yorionnicholas, does that match your hunch?
-nicholasI have to admit, I've had much grief with GEPIs
already. I wish the semantics were plainly documented as part of their own
language, instead of just relying on C aliasing rules and C
semantics...
-nicholasYorion: leading zeroes
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.11 -> 1.12 --- Log message: Fix a thinko noticed by Chandler Carruth. --- Diffs of the changes: (+4 -3) GetElementPtr.html |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.11 llvm/docs/GetElementPtr.html:1.12 --- llvm/docs/GetElementPtr.html:1.11 Tue Aug 15 07:15:08 2006 +++ llvm/docs/GetElementPtr.htmlWed Aug 16 00:53:32 2006 @@ -112,8 +112,9 @@ In this "C" example, the front end compiler (llvm-gcc) will generate three GEP instructions for the three indices through "P" in the assignment statement. The function argument P will be the first operand of each - of these GEP instructions. The second operand will be the field offset into - the struct munger_struct type, for either the f1 or + of these GEP instructions. The second operand indexes through that pointer. + The third operand will be the field offset into the + struct munger_struct type, for either the f1 or f2 field. So, in LLVM assembly the munge function looks like: @@ -630,7 +631,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 12:15:08 $ + Last modified: $Date: 2006/08/16 05:53:32 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.10 -> 1.11 --- Log message: Haste-o discovered after. --- Diffs of the changes: (+2 -2) GetElementPtr.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.10 llvm/docs/GetElementPtr.html:1.11 --- llvm/docs/GetElementPtr.html:1.10 Tue Aug 15 07:11:42 2006 +++ llvm/docs/GetElementPtr.htmlTue Aug 15 07:15:08 2006 @@ -259,7 +259,7 @@ - Why do GEP x,1,0,0 and GEP x,1 alias? + Why do GEP x,1,0,0 and GEP x,1 alias? Quick Answer: They compute the same address location. @@ -630,7 +630,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 12:11:42 $ + Last modified: $Date: 2006/08/15 12:15:08 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.9 -> 1.10 --- Log message: Hypos pointed out by Jakob Praher. --- Diffs of the changes: (+6 -6) GetElementPtr.html | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.9 llvm/docs/GetElementPtr.html:1.10 --- llvm/docs/GetElementPtr.html:1.9Tue Aug 15 03:14:19 2006 +++ llvm/docs/GetElementPtr.htmlTue Aug 15 07:11:42 2006 @@ -56,12 +56,12 @@ this leads to the following questions, all of which are answered in the following sections. -What is the first index of the GEP instruction? +What is the first index of the GEP instruction? -Why is the extra 0 index required? -What is dereferenced by GEP? -Why don't GEP x,0,0,1 and GEP x,1 alias? -Why do GEP x,1,0,0 and GEP x,1 alias? +Why is the extra 0 index required? +What is dereferenced by GEP? +Why don't GEP x,0,0,1 and GEP x,1 alias? +Why do GEP x,1,0,0 and GEP x,1 alias? @@ -630,7 +630,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 08:14:19 $ + Last modified: $Date: 2006/08/15 12:11:42 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.8 -> 1.9 --- Log message: Typo. --- Diffs of the changes: (+2 -2) GetElementPtr.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.8 llvm/docs/GetElementPtr.html:1.9 --- llvm/docs/GetElementPtr.html:1.8Mon Aug 14 23:00:29 2006 +++ llvm/docs/GetElementPtr.htmlTue Aug 15 03:14:19 2006 @@ -81,7 +81,7 @@ it is natural to think that there is only one index, the selection of the field F. However, in this example, Foo is a pointer. That pointer must be indexed explicitly in LLVM. C, on the other hand, indexs - through it ransparently. To arrive at the same address location as the C + through it transparently. To arrive at the same address location as the C code, you would provide the GEP instruction with two index operands. The first operand indexes through the pointer; the second operand indexes the field F of the structure, just as if you wrote: @@ -630,7 +630,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 04:00:29 $ + Last modified: $Date: 2006/08/15 08:14:19 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.7 -> 1.8 --- Log message: Okay, make the prose match the example too. --- Diffs of the changes: (+8 -7) GetElementPtr.html | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.7 llvm/docs/GetElementPtr.html:1.8 --- llvm/docs/GetElementPtr.html:1.7Mon Aug 14 22:57:05 2006 +++ llvm/docs/GetElementPtr.htmlMon Aug 14 23:00:29 2006 @@ -78,12 +78,13 @@ AType* Foo; ... X = &Foo->F; - it is natural to think that there is only one index, the constant value - 1. This results from C allowing you to treat pointers and arrays as - equivalent. LLVM doesn't. In this example, Foo is a pointer. That pointer must - be indexed. To arrive at the same address location as the C code, you would - provide the GEP instruction with two indices. The first indexes through the - pointer, the second index the element of the structure just as if it was: + it is natural to think that there is only one index, the selection of the + field F. However, in this example, Foo is a pointer. That + pointer must be indexed explicitly in LLVM. C, on the other hand, indexs + through it ransparently. To arrive at the same address location as the C + code, you would provide the GEP instruction with two index operands. The + first operand indexes through the pointer; the second operand indexes the + field F of the structure, just as if you wrote: X = &Foo[0].F; Sometimes this question gets rephrased as: @@ -629,7 +630,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 03:57:05 $ + Last modified: $Date: 2006/08/15 04:00:29 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.6 -> 1.7
---
Log message:
Some more correction to the examples, thanks to Chris Lattner.
---
Diffs of the changes: (+8 -5)
GetElementPtr.html | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.6 llvm/docs/GetElementPtr.html:1.7
--- llvm/docs/GetElementPtr.html:1.6Mon Aug 14 22:46:38 2006
+++ llvm/docs/GetElementPtr.htmlMon Aug 14 22:57:05 2006
@@ -77,21 +77,24 @@
AType* Foo;
...
- X = Foo[1];
+ X = &Foo->F;
it is natural to think that there is only one index, the constant value
1. This results from C allowing you to treat pointers and arrays as
equivalent. LLVM doesn't. In this example, Foo is a pointer. That pointer
must
be indexed. To arrive at the same address location as the C code, you would
provide the GEP instruction with two indices. The first indexes through the
- pointer, the second index the second element of the array.
+ pointer, the second index the element of the structure just as if it was:
+
+ X = &Foo[0].F;
Sometimes this question gets rephrased as:
Why is it okay to index through the first pointer, but
subsequent pointers won't be dereferenced?
The answer is simply because memory does not have to be accessed to
perform the computation. The first operand to the GEP instruction must be a
value of a pointer type. The value of the pointer is provided directly to
- the GEP instruction without any need for accessing memory. It must,
- therefore be indexed like any other operand. Consider this example:
+ the GEP instruction as an operand without any need for accessing memory. It
+ must, therefore be indexed and requires an index operand. Consider this
+ example:
struct munger_struct {
int f1;
@@ -626,7 +629,7 @@
http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" />
http://llvm.org";>The LLVM Compiler Infrastructure
- Last modified: $Date: 2006/08/15 03:46:38 $
+ Last modified: $Date: 2006/08/15 03:57:05 $
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.5 -> 1.6 --- Log message: Fix an example. --- Diffs of the changes: (+2 -2) GetElementPtr.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.5 llvm/docs/GetElementPtr.html:1.6 --- llvm/docs/GetElementPtr.html:1.5Mon Aug 14 22:43:31 2006 +++ llvm/docs/GetElementPtr.htmlMon Aug 14 22:46:38 2006 @@ -102,7 +102,7 @@ P[0].f1 = P[1].f1 + P[2].f2; } ... - complex Array[3]; + munger_struct Array[3]; ... munge(Array); In this "C" example, the front end compiler (llvm-gcc) will generate three @@ -626,7 +626,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/15 03:43:31 $ + Last modified: $Date: 2006/08/15 03:46:38 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.4 -> 1.5
---
Log message:
Clarify the first question.
---
Diffs of the changes: (+18 -6)
GetElementPtr.html | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.4 llvm/docs/GetElementPtr.html:1.5
--- llvm/docs/GetElementPtr.html:1.4Mon Aug 14 22:32:10 2006
+++ llvm/docs/GetElementPtr.htmlMon Aug 14 22:43:31 2006
@@ -70,9 +70,21 @@
What is the first index of the GEP instruction?
- Quick answer: Because its already present.
- Having understood the previous question, a new
- question then arises:
+ Quick answer: The index stepping through the first operand.
+ The confusion with the first index usually arises from thinking about
+ the GetElementPtr instruction as if it was a C index operator. They aren't
the
+ same. For example, when we write, in "C":
+
+ AType* Foo;
+ ...
+ X = Foo[1];
+ it is natural to think that there is only one index, the constant value
+ 1. This results from C allowing you to treat pointers and arrays as
+ equivalent. LLVM doesn't. In this example, Foo is a pointer. That pointer
must
+ be indexed. To arrive at the same address location as the C code, you would
+ provide the GEP instruction with two indices. The first indexes through the
+ pointer, the second index the second element of the array.
+ Sometimes this question gets rephrased as:
Why is it okay to index through the first pointer, but
subsequent pointers won't be dereferenced?
The answer is simply because memory does not have to be accessed to
@@ -194,7 +206,7 @@
%idx = getelementptr { [40 x int]* }* %MyVar, long 0, ubyte 0, long 0, long
17
In this example, we have a global variable, %MyVar that is a
pointer to a structure containing a pointer to an array of 40 ints. The
- GEP instruction seems to be accessing the 18th integer of of the structure's
+ GEP instruction seems to be accessing the 18th integer of the structure's
array of ints. However, this is actually an illegal GEP instruction. It
won't compile. The reason is that the pointer in the structure must
be dereferenced in order to index into the array of 40 ints. Since the
@@ -213,7 +225,7 @@
...
%idx = getelementptr { [40 x int] }*, long 0, ubyte 0, long 17
then everything works fine. In this case, the structure does not contain a
- pointer and the GEP instruction can index through the global variable
pointer,
+ pointer and the GEP instruction can index through the global variable,
into the first field of the structure and access the 18th int in
the
array there.
@@ -614,7 +626,7 @@
http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" />
http://llvm.org";>The LLVM Compiler Infrastructure
- Last modified: $Date: 2006/08/15 03:32:10 $
+ Last modified: $Date: 2006/08/15 03:43:31 $
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.3 -> 1.4
---
Log message:
Rearrange things for clarity, don't talk about "dereferencing" when we
shouldn't, and add a better example for one of the questions. Thanks to
Chris Lattner for these suggestions.
---
Diffs of the changes: (+91 -49)
GetElementPtr.html | 140 ++---
1 files changed, 91 insertions(+), 49 deletions(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.3 llvm/docs/GetElementPtr.html:1.4
--- llvm/docs/GetElementPtr.html:1.3Thu Aug 10 16:38:47 2006
+++ llvm/docs/GetElementPtr.htmlMon Aug 14 22:32:10 2006
@@ -56,10 +56,10 @@
this leads to the following questions, all of which are answered in the
following sections.
+What is the first index of the GEP instruction?
+
Why is the extra 0 index required?
What is dereferenced by GEP?
-Why can you index through the first pointer but not
- subsequent ones?
Why don't GEP x,0,0,1 and GEP x,1 alias?
Why do GEP x,1,0,0 and GEP x,1 alias?
@@ -67,6 +67,83 @@
+ What is the first index of the GEP instruction?
+
+
+ Quick answer: Because its already present.
+ Having understood the previous question, a new
+ question then arises:
+ Why is it okay to index through the first pointer, but
+ subsequent pointers won't be dereferenced?
+ The answer is simply because memory does not have to be accessed to
+ perform the computation. The first operand to the GEP instruction must be a
+ value of a pointer type. The value of the pointer is provided directly to
+ the GEP instruction without any need for accessing memory. It must,
+ therefore be indexed like any other operand. Consider this example:
+
+ struct munger_struct {
+int f1;
+int f2;
+ };
+ void munge(struct munger_struct *P)
+ {
+P[0].f1 = P[1].f1 + P[2].f2;
+ }
+ ...
+ complex Array[3];
+ ...
+ munge(Array);
+ In this "C" example, the front end compiler (llvm-gcc) will generate three
+ GEP instructions for the three indices through "P" in the assignment
+ statement. The function argument P will be the first operand of
each
+ of these GEP instructions. The second operand will be the field offset into
+ the struct munger_struct type, for either the f1 or
+ f2 field. So, in LLVM assembly the munge function looks
+ like:
+
+ void %munge(%struct.munger_struct* %P) {
+ entry:
+%tmp = getelementptr %struct.munger_struct* %P, int 1, uint 0
+%tmp = load int* %tmp
+%tmp6 = getelementptr %struct.munger_struct* %P, int 2, uint 1
+%tmp7 = load int* %tmp6
+%tmp8 = add int %tmp7, %tmp
+%tmp9 = getelementptr %struct.munger_struct* %P, int 0, uint 0
+store int %tmp8, int* %tmp9
+ret void
+ }
+ In each case the first operand is the pointer through which the GEP
+ instruction starts. The same is true whether the first operand is an
+ argument, allocated memory, or a global variable.
+ To make this clear, let's consider a more obtuse example:
+
+ %MyVar = unintialized global int
+ ...
+ %idx1 = getelementptr int* %MyVar, long 0
+ %idx2 = getelementptr int* %MyVar, long 1
+ %idx3 = getelementptr int* %MyVar, long 2
+ These GEP instructions are simply making address computations from the
+ base address of MyVar. They compute, as follows (using C syntax):
+
+
+ idx1 = (char*) &MyVar + 0
+ idx2 = (char*) &MyVar + 4
+ idx3 = (char*) &MyVar + 8
+
+ Since the type int is known to be four bytes long, the indices
+ 0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No
+ memory is accessed to make these computations because the address of
+ %MyVar is passed directly to the GEP instructions.
+ The obtuse part of this example is in the cases of %idx2 and
+ %idx3. They result in the computation of addresses that point to
+ memory past the end of the %MyVar global, which is only one
+ int long, not three ints long. While this is legal in
LLVM,
+ it is inadvisable because any load or store with the pointer that results
+ from these GEP instructions would produce undefined results.
+
+
+
+
Why is the extra 0 index required?
@@ -81,7 +158,7 @@
The GEP above yields an int* by indexing the int typed
field of the structure %MyStruct. When people first look at it,
they
wonder why the long 0 index is needed. However, a closer inspection
- of how globals and GEPs work reveals the need. Becoming aware of the
following
+ of how globals and GEPs work reveals the need. Becoming aware of the
following
facts will dispell the confusion:
The type of %MyStruct is not { float*, int }
@@ -91,8 +168,11 @@
Point #1 is evidenced by noticing the type of the first operand of
the GEP instruction (%MyStruct) which is
{ float*, int }*.
-The first index, long 0 is required to dereference the
-pointer associated with %MyStruct.
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs: GetElementPtr.html updated: 1.2 -> 1.3 --- Log message: Fix a typo noticed by Gordon Henriksen. Thanks! --- Diffs of the changes: (+2 -2) GetElementPtr.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/docs/GetElementPtr.html diff -u llvm/docs/GetElementPtr.html:1.2 llvm/docs/GetElementPtr.html:1.3 --- llvm/docs/GetElementPtr.html:1.2Thu Aug 10 16:01:14 2006 +++ llvm/docs/GetElementPtr.htmlThu Aug 10 16:38:47 2006 @@ -164,7 +164,7 @@ idx1 = &MyVar + 0 idx2 = &MyVar + 4 - idx3 = &MyVar = 8 + idx3 = &MyVar + 8 Since the type int is known to be four bytes long, the indices 0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No @@ -572,7 +572,7 @@ http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> http://llvm.org";>The LLVM Compiler Infrastructure - Last modified: $Date: 2006/08/10 21:01:14 $ + Last modified: $Date: 2006/08/10 21:38:47 $ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/docs/GetElementPtr.html
Changes in directory llvm/docs:
GetElementPtr.html updated: 1.1 -> 1.2
---
Log message:
Add a cleaned-up version of the IRC conversation that spurred this FAQ.
---
Diffs of the changes: (+330 -1)
GetElementPtr.html | 331 -
1 files changed, 330 insertions(+), 1 deletion(-)
Index: llvm/docs/GetElementPtr.html
diff -u llvm/docs/GetElementPtr.html:1.1 llvm/docs/GetElementPtr.html:1.2
--- llvm/docs/GetElementPtr.html:1.1Thu Aug 10 15:15:58 2006
+++ llvm/docs/GetElementPtr.htmlThu Aug 10 16:01:14 2006
@@ -5,6 +5,9 @@
The Often Misunderstood GEP Instruction
+
+TABLE { text-align: left; border: 1px solid black; border-collapse:
collapse; margin: 0 0 0 0; }
+
@@ -235,6 +238,332 @@
+Appendix:
Discussion
+
+
+ The following is a real discussion from the
+ #llvm IRC channel about the GEP
+ instruction. You may find this instructive as it was the basis for this
+ document.
+
+UserComment
+YorionIf x & y must alias, are [ getelementptr
x,0,0,1,2 ] and [ getelementptr x,1,2 ] aliased? (they obviously have different
types, but they should alias...)
+Yorionoops, for the second one I meant [ getelementptr
y,1,2 ]
+ReidI don't see how that could be, Yorion but I'm not the
authority on this
+Yorionhmm..
+Reidthe two geps, by definition, are going to produce
different pointers which are not aliased
+Yorionwould [ GEP x,1,0 ] and [ GEP y,1 ] be
aliased?
+Reidif the second gep was [gep y,0,0,1,2] then they
should be aliased as well
+Reidno, I wouldn't expect that to work either :)
+Reidyou can't just arbitrarily drop leading or trailing
indices :)
+Reid(.. leading or trailing 0 indices, I mean)
+Reidthis instruction walks through a data structure and
generates a pointer to the resulting thing
+Reidif the number of indices are different, you're ending
up at a different place and by definition they'll have different
addresses
+Yorionoh, I see, because of different types, [ GEP x,0,1 ]
+& [ GEP x,1 ] actually might refer to different fields, but might
also refer to the same ones...
+Reidor, at least, that's my crude understanding of it
:)
+Reidno, they'll definitely refer to different
fields
+nicholasGEP x,0,1 ==> &((*(x+0))+1)? vs. GEP x,1
==> &(*(x+1))?
+Reidlemme grok that for a sec
+Reidthat might be true in some limited definition of x,
but it wouldn't be generally
+nicholasoh. fields of different sizes in a
structure.
+Reidyup
+Yorionis perhaps the type unification the reason why [
GEP x,0,1 ] and [ GEP x,1 ] cannot alias?
+Reidno
+Reidthey may or may not have the same type, but they are
definitely different pointers
+Reidlets use a concrete example for "x"
+Reidsuppose x is "struct {int a, float b} *"
+ReidGEP X,0,1 is going to return the address of
b
+ReidGEP X,1 is going to return the address of the
*second* "a" (after the first b)
+Yorionah, I see...
+Yoriontrailing zeros are still a bit confusing...
+Reidsame thing .. you're just selecting the 0th member of
an array or structure
+Yorionyou don't move away from the pointer, only the type
is changed
+Reidno, you still move away from the pointer .. the type
might change, or not
+Reidthe pointer definitely changes
+Reidlets look at an example for trailing zero
+Reidsuppose x is "int x[10][10][10][10]" (in C)
+ReidGEP X,0,0 will yield you a 3 dimensional
array
+ReidGEP X,0,0,0,0,0 will yield you an "int"
+Reidmake sense?
+Yorionyes
+Reidso, I think there's a law here: if the number of
indices in two GEP instructions are not equivalent, there is no way the
resulting pointers can alias
+Reid(assuming the x and y alias)
+YorionI was confused with some code in BasicAliasAnalysis
that says that two pointers are equal if they differ only in trailing
zeros
+YorionBasicAliasAnalysis.cpp:504-518
+Reidlemme look
+nicholasif y1 = GEP X, 0, 0 and y2 = GEP X, 0, 0, 0, 0, 0
(from Reid's example)
+nicholasthen doesn't *y1 and *y2 both refer to the same
"int"?
+Reidthey shouldn't
+Reidhmm .. actually, maybe you're right :)
+Reidthey definitely have different *types*
+Yoriontrue
+nicholasdifferent types just doesn't cut it. :)
+Reid.. thinking on this :)
+nicholassimilarly, i could create a yucky with a struct
that has a char *, then have you GEP right through the pointer into the
pointed-to data. That could mean that the resulting point might alias
anything.
+Yorionmy theory (after reading BAA) is that all zeros can
be omitted, and that the pointers alias if they have the same sequence of
indices
+Yorionhowever, this screws the typing, so that's why
zeros are for
+Yorionnicholas, does that match your hunch?
+nicholasI have to admit, I've had much grief with GEPIs
already. I wish the semantics wer
[llvm-commits] CVS: llvm/docs/GetElementPtr.html FAQ.html
Changes in directory llvm/docs:
GetElementPtr.html added (r1.1)
FAQ.html updated: 1.37 -> 1.38
---
Log message:
Answer the most frequently asked question, about GEPs. The answer is
sufficiently long that I placed it in a separate file but it links from
the FAQ page. More might need to be added to GetElementPtr.html to
address additional confusion surrounding GEP.
---
Diffs of the changes: (+252 -1)
FAQ.html |4
GetElementPtr.html | 249 +
2 files changed, 252 insertions(+), 1 deletion(-)
Index: llvm/docs/GetElementPtr.html
diff -c /dev/null llvm/docs/GetElementPtr.html:1.1
*** /dev/null Thu Aug 10 15:16:08 2006
--- llvm/docs/GetElementPtr.htmlThu Aug 10 15:15:58 2006
***
*** 0
--- 1,249
+ http://www.w3.org/TR/html4/strict.dtd";>
+
+
+
+ The Often Misunderstood GEP Instruction
+
+
+
+
+
+ The Often Misunderstood GEP Instruction
+
+
+
+ Introduction
+ The Questions
+
+ Why is the extra 0 index required?
+ What is dereferenced by GEP?
+ Why can you index through the first pointer but
not
+ subsequent ones?
+ Why don't GEP x,0,0,1 and GEP x,1 alias?
+ Why do GEP x,1,0,0 and GEP x,1 alias?
+
+ Summary
+
+
+
+ Written by: mailto:[EMAIL PROTECTED]">Reid Spencer.
+
+
+
+
+ Introduction
+
+
+ This document seeks to dispel the mystery and confusion surrounding
LLVM's
+ GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction
are
+ probably the most frequently occuring questions once a developer gets down
to
+ coding with LLVM. Here we lay out the sources of confusion and show that the
+ GEP instruction is really quite simple.
+
+
+
+
+ The Questions
+
+
+ When people are first confronted with the GEP instruction, they tend to
+ relate it to known concepts from other programming paradigms, most notably C
+ array indexing and field selection. However, GEP is a little different and
+ this leads to the following questions, all of which are answered in the
+ following sections.
+
+ Why is the extra 0 index required?
+ What is dereferenced by GEP?
+ Why can you index through the first pointer but not
+ subsequent ones?
+ Why don't GEP x,0,0,1 and GEP x,1 alias?
+ Why do GEP x,1,0,0 and GEP x,1 alias?
+
+
+
+
+
+ Why is the extra 0 index required?
+
+
+
+ Quick answer: there are no superfluous indices.
+ This question arises most often when the GEP instruction is applied to a
+ global variable which is always a pointer type. For example, consider
+ this:
+ %MyStruct = uninitialized global { float*, int }
+ ...
+ %idx = getelementptr { float*, int }* %MyStruct, long 0, ubyte 1
+ The GEP above yields an int* by indexing the int typed
+ field of the structure %MyStruct. When people first look at it,
they
+ wonder why the long 0 index is needed. However, a closer
inspection
+ of how globals and GEPs work reveals the need. Becoming aware of the
following
+ facts will dispell the confusion:
+
+ The type of %MyStruct is not { float*, int }
+ but rather { float*, int }*. That is, %MyStruct is a
+ pointer to a structure containing a pointer to a float and an
+ int.
+ Point #1 is evidenced by noticing the type of the first operand of
+ the GEP instruction (%MyStruct) which is
+ { float*, int }*.
+ The first index, long 0 is required to dereference the
+ pointer associated with %MyStruct.
+ The second index, ubyte 1 selects the second field of the
+ structure (the int).
+
+
+
+
+
+ What is dereferenced by GEP?
+
+
+ Quick answer: nothing.
+ The GetElementPtr instruction dereferences nothing. That is, it doesn't
+ access memory in any way. That's what the Load instruction is for. GEP is
+ only involved in the computation of addresses. For example, consider
this:
+
+ %MyVar = uninitialized global { [40 x int ]* }
+ ...
+ %idx = getelementptr { [40 x int]* }* %MyVar, long 0, ubyte 0, long 0, long
17
+ In this example, we have a global variable, %MyVar that is a
+ pointer to a structure containing a pointer to an array of 40 ints. The
+ GEP instruction seems to be accessing the 18th integer of of the structure's
+ array of ints. However, this is actually an illegal GEP instruction. It
+ won't compile. The reason is that the pointer in the structure must
+ be dereferenced in order to index into the array of 40 ints. Since the
+ GEP instruction never accesses memory, it is illegal.
+ In order to access the 18th integer in the array, you would need to do
the
+ following:
+
+ %idx = getelementptr { [40 x int]* }* %, long 0, ubyte 0
+ %arr = load [40 x int]** %idx
+ %idx = getelementptr [40 x int]* %arr, long 0, long 17
+ In this case, we have to load the pointer in the structure with a load
+ instruction before we can inde
