Newer
Older
aggressive transformations, so the value returned may not that of the obvious
source-language caller.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_os">Operating System Intrinsics</a>
</div>
<div class="doc_text">
<p>
These intrinsics are provided by LLVM to support the implementation of
operating system level code.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_readport">'<tt>llvm.readport</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call <integer type> (<integer type>)* %llvm.readport (<integer type> <address>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.readport</tt>' intrinsic reads data from the specified hardware
I/O port.
</p>
<h5>Arguments:</h5>
<p>
The argument to this intrinsic indicates the hardware I/O address from which
to read the data. The address is in the hardware I/O address namespace (as
opposed to being a memory location for memory mapped I/O).
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.readport</tt>' intrinsic reads data from the hardware I/O port
specified by <i>address</i> and returns the value. The address and return
value must be integers, but the size is dependent upon the platform upon which
the program is code generated. For example, on x86, the address must be an
unsigned 16 bit value, and the return value must be 8, 16, or 32 bits.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_writeport">'<tt>llvm.writeport</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (<integer type>, <integer type>)* %llvm.writeport (<integer type> <value>, <integer type> <address>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.writeport</tt>' intrinsic writes data to the specified hardware
I/O port.
</p>
<h5>Arguments:</h5>
<p>
The first argument to this intrinsic indicates the hardware I/O address to
which data should be written. The address is in the hardware I/O address
namespace (as opposed to being a memory location for memory mapped I/O).
</p>
<p>
The second argument is the value to write to the I/O port.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.writeport</tt>' intrinsic writes <i>value</i> to the I/O port
specified by <i>address</i>. The address and value must be integers, but the
size is dependent upon the platform upon which the program is code generated.
For example, on x86, the address must be an unsigned 16 bit value, and the
value written must be 8, 16, or 32 bits in length.
</p>
</div>
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_readio">'<tt>llvm.readio</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call <integer type> (<integer type>)* %llvm.readio (<integer type> <address>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O
address.
</p>
<h5>Arguments:</h5>
<p>
The argument to this intrinsic indicates the memory address from which to read
the data.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O
location specified by <i>address</i> and returns the value. The address and
return value must be integers, but the size allowed for each is dependent upon
the platform upon which the program is code generated.
</p>
<p>
This intrinsic ensures that the I/O data read occurs in instruction order in
relation to other I/O data reads and writes (as opposed to a normal load, where
hardware scheduling can re-arrange the actual memory accesses to occur out of
order).
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_writeio">'<tt>llvm.writeio</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (<integer type>, <integer type>)* %llvm.writeio (<integer type> <value>, <integer type> <address>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.writeio</tt>' intrinsic writes data to the specified memory
mapped I/O address.
</p>
<h5>Arguments:</h5>
<p>
The first argument to this intrinsic indicates the memory address to which data
should be written.
</p>
<p>
The second argument is the value to write to the memory mapped I/O location.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.writeio</tt>' intrinsic writes <i>value</i> to the memory mapped
I/O address specified by <i>address</i>. The address and value must be
integers, but the size is dependent upon the platform upon which the program is
code generated.
</p>
<p>
This intrinsic ensures that the I/O data write occurs in instruction order in
relation to other I/O data reads and writes (as opposed to a normal store,
where hardware scheduling can re-arrange the actual memory accesses to occur
out of order).
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_libc">Standard C Library Intrinsics</a>
</div>
Chris Lattner
committed
<div class="doc_text">
<p>
LLVM provides intrinsics for a few important standard C library functions.
These intrinsics allow source-language front-ends to pass information about the
alignment of the pointer arguments to the code generator, providing opportunity
for more efficient code generation.
Chris Lattner
committed
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* <dest>, sbyte* <src>,
uint <len>, uint <align>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memcpy</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination, the second is a pointer to
the source. The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>
Chris Lattner
committed
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>
Chris Lattner
committed
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location, which are not allowed to overlap. It
copies "len" bytes of memory over. If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* <dest>, sbyte* <src>,
uint <len>, uint <align>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memmove</tt>' intrinsic moves a block of memory from the source
location to the destination location. It is similar to the '<tt>llvm.memcpy</tt>'
intrinsic but allows the two memory locations to overlap.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memmove</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination, the second is a pointer to
the source. The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>
Chris Lattner
committed
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memmove</tt>' intrinsic copies a block of memory from the source
location to the destination location, which may overlap. It
copies "len" bytes of memory over. If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memset">'<tt>llvm.memset</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* <dest>, ubyte <val>,
uint <len>, uint <align>)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memset</tt>' intrinsic fills a block of memory with a particular
byte value.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination to fill, the second is the
byte value to fill it with, the third argument is an (arbitrarily sized) integer
argument specifying the number of bytes to fill, and the fourth argument is the
known alignment of destination location.
</p>
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that the destination pointer is aligned to that boundary.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memset</tt>' intrinsic fills "len" bytes of memory starting at the
destination location. If the argument is known to be aligned to some boundary,
this can be specified as the fourth argument, otherwise it should be set to 0 or
1.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_debugger">Debugger Intrinsics</a>
</div>
<div class="doc_text">
<p>
The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix),
are described in the <a
href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level
Debugging</a> document.
</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>