[llvm-commits] CVS: llvm/docs/LangRef.html
John Criswell
criswell at cs.uiuc.edu
Mon May 16 09:18:03 PDT 2005
Changes in directory llvm/docs:
LangRef.html updated: 1.107 -> 1.108
---
Log message:
Added a note about how the type can be omitted in call instructions.
Added a note about how getelementptr can be used to index into structures
or arrays.
Fixed some typos, spelling, etc.
---
Diffs of the changes: (+22 -18)
LangRef.html | 40 ++++++++++++++++++++++------------------
1 files changed, 22 insertions(+), 18 deletions(-)
Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.107 llvm/docs/LangRef.html:1.108
--- llvm/docs/LangRef.html:1.107 Sun May 15 14:39:26 2005
+++ llvm/docs/LangRef.html Mon May 16 11:17:45 2005
@@ -1918,7 +1918,8 @@
elements of the aggregate object to index to. The actual types of the arguments
provided depend on the type of the first pointer argument. The
'<tt>getelementptr</tt>' instruction is used to index down through the type
-levels of a structure. When indexing into a structure, only <tt>uint</tt>
+levels of a structure or to a specific index in an array. When indexing into a
+structure, only <tt>uint</tt>
integer constants are allowed. When indexing into an array or pointer,
<tt>int</tt> and <tt>long</tt> indexes are allowed of any sign.</p>
@@ -1972,7 +1973,7 @@
sbyte }</tt>' type, another structure. The third index indexes into the second
element of the structure, yielding a '<tt>[10 x [20 x int]]</tt>' type, an
array. The two dimensions of the array are subscripted into, yielding an
-'<tt>int</tt>' type. The '<tt>getelementptr</tt>' instruction return a pointer
+'<tt>int</tt>' type. The '<tt>getelementptr</tt>' instruction returns a pointer
to this element, thus computing a value of '<tt>int*</tt>' type.</p>
<p>Note that it is perfectly legal to index partially through a
@@ -2119,7 +2120,7 @@
<p>
If the boolean condition evaluates to true, the instruction returns the first
-value argument, otherwise it returns the second value argument.
+value argument; otherwise, it returns the second value argument.
</p>
<h5>Example:</h5>
@@ -2169,13 +2170,14 @@
<li>
<p>'<tt>ty</tt>': shall be the signature of the pointer to function value
being invoked. The argument types must match the types implied by this
- signature.</p>
+ signature. This type can be omitted if the function is not varargs and
+ if the function type does not return a pointer to a function.</p>
</li>
<li>
<p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to
be invoked. In most cases, this is a direct function invocation, but
indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer
- to function values.</p>
+ to function value.</p>
</li>
<li>
<p>'<tt>function args</tt>': argument list whose types match the
@@ -2248,9 +2250,9 @@
<p><tt>vanext</tt> is an LLVM instruction instead of an <a
href="#intrinsics">intrinsic function</a> because it takes a type as an
-argument. The type refers to the current argument in the <tt>va_list</tt>, it
+argument. The type refers to the current argument in the <tt>va_list</tt>; it
tells the compiler how far on the stack it needs to advance to find the next
-argument</p>
+argument.</p>
<h5>Example:</h5>
@@ -2297,7 +2299,7 @@
function.</p>
<p><tt>vaarg</tt> is an LLVM instruction instead of an <a
-href="#intrinsics">intrinsic function</a> because it takes an type as an
+href="#intrinsics">intrinsic function</a> because it takes a type as an
argument.</p>
<h5>Example:</h5>
@@ -2313,14 +2315,14 @@
<div class="doc_text">
<p>LLVM supports the notion of an "intrinsic function". These functions have
-well known names and semantics, and are required to follow certain
+well known names and semantics and are required to follow certain
restrictions. Overall, these instructions represent an extension mechanism for
the LLVM language that does not require changing all of the transformations in
LLVM to add to the language (or the bytecode reader/writer, the parser,
etc...).</p>
-<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
-prefix is reserved in LLVM for intrinsic names, thus functions may not be named
+<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This
+prefix is reserved in LLVM for intrinsic names; thus, functions may not be named
this. Intrinsic functions must always be external functions: you cannot define
the body of intrinsic functions. Intrinsic functions may only be used in call
or invoke instructions: it is illegal to take the address of an intrinsic
@@ -2328,7 +2330,7 @@
language, it is required that they all be documented here if any are added.</p>
-<p>To learn how to add an intrinsics, please see the <a
+<p>To learn how to add an intrinsic function, please see the <a
href="ExtendingLLVM.html">Extending LLVM Guide</a>.
</p>
@@ -2396,7 +2398,7 @@
returns a <tt>va_list</tt> element, so that the next <tt>vaarg</tt>
will produce the first variable argument passed to the function. Unlike
the C <tt>va_start</tt> macro, this intrinsic does not need to know the
-last argument of the function, the compiler can figure that out.</p>
+last argument of the function; the compiler can figure that out.</p>
<p>Note that this intrinsic function is only legal to be called from
within the body of a variable argument function.</p>
</div>
@@ -2693,8 +2695,9 @@
<p>
The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert
-a prefetch instruction if supported, otherwise it is a noop. Prefetches have no
-effect on the behavior of the program, but can change its performance
+a prefetch instruction if supported; otherwise, it is a noop. Prefetches have
+no
+effect on the behavior of the program but can change its performance
characteristics.
</p>
@@ -2735,13 +2738,14 @@
<p>
-The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a PC in a region of
+The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program Counter
+(PC) in a region of
code to simulators and other tools. The method is target specific, but it is
expected that the marker will use exported symbols to transmit the PC of the marker.
The marker makes no guaranties that it will remain with any specific instruction
after optimizations. It is possible that the presense of a marker will inhibit
optimizations. The intended use is to be inserted after optmizations to allow
-corrolations of simulation runs.
+correlations of simulation runs.
</p>
<h5>Arguments:</h5>
@@ -3301,7 +3305,7 @@
<a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2005/05/15 19:39:26 $
+ Last modified: $Date: 2005/05/16 16:17:45 $
</address>
</body>
</html>
More information about the llvm-commits
mailing list