mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-24 09:29:42 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22083 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
77d36d4ed5
commit
fc6b895b5b
@ -1918,7 +1918,8 @@ subelement of an aggregate data structure.</p>
|
|||||||
elements of the aggregate object to index to. The actual types of the arguments
|
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
|
provided depend on the type of the first pointer argument. The
|
||||||
'<tt>getelementptr</tt>' instruction is used to index down through the type
|
'<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,
|
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>
|
<tt>int</tt> and <tt>long</tt> indexes are allowed of any sign.</p>
|
||||||
|
|
||||||
@ -1972,7 +1973,7 @@ the structure, yielding a '<tt>%RT</tt>' = '<tt>{ sbyte, [10 x [20 x int]],
|
|||||||
sbyte }</tt>' type, another structure. The third index indexes into the second
|
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
|
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
|
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>
|
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
|
<p>Note that it is perfectly legal to index partially through a
|
||||||
@ -2119,7 +2120,7 @@ The '<tt>select</tt>' instruction requires a boolean value indicating the condit
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
If the boolean condition evaluates to true, the instruction returns the first
|
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>
|
</p>
|
||||||
|
|
||||||
<h5>Example:</h5>
|
<h5>Example:</h5>
|
||||||
@ -2169,13 +2170,14 @@ value argument, otherwise it returns the second value argument.
|
|||||||
<li>
|
<li>
|
||||||
<p>'<tt>ty</tt>': shall be the signature of the pointer to function value
|
<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
|
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>
|
||||||
<li>
|
<li>
|
||||||
<p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to
|
<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
|
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
|
indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer
|
||||||
to function values.</p>
|
to function value.</p>
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
<p>'<tt>function args</tt>': argument list whose types match the
|
<p>'<tt>function args</tt>': argument list whose types match the
|
||||||
@ -2248,9 +2250,9 @@ function.</p>
|
|||||||
|
|
||||||
<p><tt>vanext</tt> is an LLVM instruction instead of an <a
|
<p><tt>vanext</tt> is an LLVM instruction instead of an <a
|
||||||
href="#intrinsics">intrinsic function</a> because it takes a type as an
|
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
|
tells the compiler how far on the stack it needs to advance to find the next
|
||||||
argument</p>
|
argument.</p>
|
||||||
|
|
||||||
<h5>Example:</h5>
|
<h5>Example:</h5>
|
||||||
|
|
||||||
@ -2297,7 +2299,7 @@ take a variable number of arguments, for example, the <tt>vfprintf</tt>
|
|||||||
function.</p>
|
function.</p>
|
||||||
|
|
||||||
<p><tt>vaarg</tt> is an LLVM instruction instead of an <a
|
<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>
|
argument.</p>
|
||||||
|
|
||||||
<h5>Example:</h5>
|
<h5>Example:</h5>
|
||||||
@ -2313,14 +2315,14 @@ argument.</p>
|
|||||||
<div class="doc_text">
|
<div class="doc_text">
|
||||||
|
|
||||||
<p>LLVM supports the notion of an "intrinsic function". These functions have
|
<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
|
restrictions. Overall, these instructions represent an extension mechanism for
|
||||||
the LLVM language that does not require changing all of the transformations in
|
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,
|
LLVM to add to the language (or the bytecode reader/writer, the parser,
|
||||||
etc...).</p>
|
etc...).</p>
|
||||||
|
|
||||||
<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
|
<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
|
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
|
this. Intrinsic functions must always be external functions: you cannot define
|
||||||
the body of intrinsic functions. Intrinsic functions may only be used in call
|
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
|
or invoke instructions: it is illegal to take the address of an intrinsic
|
||||||
@ -2328,7 +2330,7 @@ function. Additionally, because intrinsic functions are part of the LLVM
|
|||||||
language, it is required that they all be documented here if any are added.</p>
|
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>.
|
href="ExtendingLLVM.html">Extending LLVM Guide</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -2396,7 +2398,7 @@ macro available in C. In a target-dependent way, it initializes and
|
|||||||
returns a <tt>va_list</tt> element, so that the next <tt>vaarg</tt>
|
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
|
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
|
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
|
<p>Note that this intrinsic function is only legal to be called from
|
||||||
within the body of a variable argument function.</p>
|
within the body of a variable argument function.</p>
|
||||||
</div>
|
</div>
|
||||||
@ -2693,8 +2695,9 @@ source-language caller.
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert
|
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
|
a prefetch instruction if supported; otherwise, it is a noop. Prefetches have
|
||||||
effect on the behavior of the program, but can change its performance
|
no
|
||||||
|
effect on the behavior of the program but can change its performance
|
||||||
characteristics.
|
characteristics.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -2735,13 +2738,14 @@ performance.
|
|||||||
|
|
||||||
|
|
||||||
<p>
|
<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
|
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.
|
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
|
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
|
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
|
optimizations. The intended use is to be inserted after optmizations to allow
|
||||||
corrolations of simulation runs.
|
correlations of simulation runs.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h5>Arguments:</h5>
|
<h5>Arguments:</h5>
|
||||||
|
Loading…
Reference in New Issue
Block a user