ReleaseNotes: C API policy; by Eric Christopher

[oota-llvm.git] / docs / GetElementPtr.rst

diff --git a/docs/GetElementPtr.rst b/docs/GetElementPtr.rst
index 3b57d78cf1ef43eb37daddb05f91b14aa76ec105..c9cfae64ace9b1e79ac3ac2a011ccad0eac146e3 100644 (file)
--- a/docs/GetElementPtr.rst
+++ b/docs/GetElementPtr.rst
@@ -1,5 +1,3 @@
-.. _gep:
-

 =======================================
 The Often Misunderstood GEP Instruction
 =======================================
 =======================================
 The Often Misunderstood GEP Instruction
 =======================================


@@ -79,7 +77,7 @@ therefore be indexed and requires an index operand. Consider this example:
   ...
   munge(Array);
 
   ...
   munge(Array);
 

-In this "C" example, the front end compiler (llvm-gcc) will generate three GEP
+In this "C" example, the front end compiler (Clang) 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 indexes through that pointer.  The third
 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 indexes through that pointer.  The third


@@ -91,12 +89,12 @@ looks like:
 
   void %munge(%struct.munger_struct* %P) {
   entry:
 
   void %munge(%struct.munger_struct* %P) {
   entry:

-    %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
+    %tmp = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 1, i32 0

     %tmp = load i32* %tmp
     %tmp = load i32* %tmp

-    %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
+    %tmp6 = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 2, i32 1

     %tmp7 = load i32* %tmp6
     %tmp8 = add i32 %tmp7, %tmp
     %tmp7 = load i32* %tmp6
     %tmp8 = add i32 %tmp7, %tmp

-    %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
+    %tmp9 = getelementptr %struct.munger_struct, %struct.munger_struct* %P, i32 0, i32 0

     store i32 %tmp8, i32* %tmp9
     ret void
   }
     store i32 %tmp8, i32* %tmp9
     ret void
   }


@@ -111,9 +109,9 @@ To make this clear, let's consider a more obtuse example:
 
   %MyVar = uninitialized global i32
   ...
 
   %MyVar = uninitialized global i32
   ...

-  %idx1 = getelementptr i32* %MyVar, i64 0
-  %idx2 = getelementptr i32* %MyVar, i64 1
-  %idx3 = getelementptr i32* %MyVar, i64 2
+  %idx1 = getelementptr i32, i32* %MyVar, i64 0
+  %idx2 = getelementptr i32, i32* %MyVar, i64 1
+  %idx3 = getelementptr i32, 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):
 
 These GEP instructions are simply making address computations from the base
 address of ``MyVar``.  They compute, as follows (using C syntax):


@@ -148,7 +146,7 @@ variable which is always a pointer type. For example, consider this:
 
   %MyStruct = uninitialized global { float*, i32 }
   ...
 
   %MyStruct = uninitialized global { float*, i32 }
   ...

-  %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1
+  %idx = getelementptr { float*, i32 }, { 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 ``i64
 
 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 ``i64


@@ -184,7 +182,7 @@ only involved in the computation of addresses. For example, consider this:
 
   %MyVar = uninitialized global { [40 x i32 ]* }
   ...
 
   %MyVar = uninitialized global { [40 x i32 ]* }
   ...

-  %idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17
+  %idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 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
 
 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


@@ -199,9 +197,9 @@ following:
 
 .. code-block:: llvm
 
 
 .. code-block:: llvm
 

-  %idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
+  %idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0

   %arr = load [40 x i32]** %idx
   %arr = load [40 x i32]** %idx

-  %idx = getelementptr [40 x i32]* %arr, i64 0, i64 17
+  %idx = getelementptr [40 x i32], [40 x i32]* %arr, i64 0, i64 17

 
 In this case, we have to load the pointer in the structure with a load
 instruction before we can index into the array. If the example was changed to:
 
 In this case, we have to load the pointer in the structure with a load
 instruction before we can index into the array. If the example was changed to:


@@ -210,7 +208,7 @@ instruction before we can index into the array. If the example was changed to:
 
   %MyVar = uninitialized global { [40 x i32 ] }
   ...
 
   %MyVar = uninitialized global { [40 x i32 ] }
   ...

-  %idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17
+  %idx = getelementptr { [40 x i32] }, { [40 x i32] }*, i64 0, i32 0, i64 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, into the
 
 then everything works fine. In this case, the structure does not contain a
 pointer and the GEP instruction can index through the global variable, into the


@@ -227,9 +225,9 @@ index. Consider this example:
 
 .. code-block:: llvm
 
 
 .. code-block:: llvm
 

-  %MyVar = global { [10 x i32 ] }
-  %idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
-  %idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1
+  %MyVar = global { [10 x i32] }
+  %idx1 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 0, i32 0, i64 1
+  %idx2 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1

 
 In this example, ``idx1`` computes the address of the second integer in the
 array that is in the structure in ``%MyVar``, that is ``MyVar+4``. The type of
 
 In this example, ``idx1`` computes the address of the second integer in the
 array that is in the structure in ``%MyVar``, that is ``MyVar+4``. The type of


@@ -250,9 +248,9 @@ type. Consider this example:
 
 .. code-block:: llvm
 
 
 .. code-block:: llvm
 

-  %MyVar = global { [10 x i32 ] }
-  %idx1 = getelementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
-  %idx2 = getelementptr { [10 x i32 ] }* %MyVar, i64 1
+  %MyVar = global { [10 x i32] }
+  %idx1 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1, i32 0, i64 0
+  %idx2 = getelementptr { [10 x i32] }, { [10 x i32] }* %MyVar, i64 1

 
 In this example, the value of ``%idx1`` is ``%MyVar+40`` and its type is
 ``i32*``. The value of ``%idx2`` is also ``MyVar+40`` but its type is ``{ [10 x
 
 In this example, the value of ``%idx1`` is ``%MyVar+40`` and its type is
 ``i32*``. The value of ``%idx2`` is also ``MyVar+40`` but its type is ``{ [10 x