<meta name="author" content="Chris Lattner">
<meta name="description"
content="LLVM Assembly Language Reference Manual.">
- <link rel="stylesheet" href="llvm.css" type="text/css">
+ <link rel="stylesheet" href="_static/llvm.css" type="text/css">
</head>
<body>
<li><a href="#linkage_private">'<tt>private</tt>' Linkage</a></li>
<li><a href="#linkage_linker_private">'<tt>linker_private</tt>' Linkage</a></li>
<li><a href="#linkage_linker_private_weak">'<tt>linker_private_weak</tt>' Linkage</a></li>
- <li><a href="#linkage_linker_private_weak_def_auto">'<tt>linker_private_weak_def_auto</tt>' Linkage</a></li>
<li><a href="#linkage_internal">'<tt>internal</tt>' Linkage</a></li>
<li><a href="#linkage_available_externally">'<tt>available_externally</tt>' Linkage</a></li>
<li><a href="#linkage_linkonce">'<tt>linkonce</tt>' Linkage</a></li>
<li><a href="#linkage_appending">'<tt>appending</tt>' Linkage</a></li>
<li><a href="#linkage_externweak">'<tt>extern_weak</tt>' Linkage</a></li>
<li><a href="#linkage_linkonce_odr">'<tt>linkonce_odr</tt>' Linkage</a></li>
+ <li><a href="#linkage_linkonce_odr_auto_hide">'<tt>linkonce_odr_auto_hide</tt>' Linkage</a></li>
<li><a href="#linkage_weak">'<tt>weak_odr</tt>' Linkage</a></li>
<li><a href="#linkage_external">'<tt>external</tt>' Linkage</a></li>
<li><a href="#linkage_dllimport">'<tt>dllimport</tt>' Linkage</a></li>
<li><a href="#metadata">Metadata Nodes and Metadata Strings</a>
<ol>
<li><a href="#tbaa">'<tt>tbaa</tt>' Metadata</a></li>
- <li><a href="#fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a></li>
+ <li><a href="#tbaa.struct">'<tt>tbaa.struct</tt>' Metadata</a></li>
+ <li><a href="#fpmath">'<tt>fpmath</tt>' Metadata</a></li>
+ <li><a href="#range">'<tt>range</tt>' Metadata</a></li>
</ol>
</li>
</ol>
<li><a href="#int_exp">'<tt>llvm.exp.*</tt>' Intrinsic</a></li>
<li><a href="#int_log">'<tt>llvm.log.*</tt>' Intrinsic</a></li>
<li><a href="#int_fma">'<tt>llvm.fma.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_fabs">'<tt>llvm.fabs.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_floor">'<tt>llvm.floor.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_ceil">'<tt>llvm.ceil.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_trunc">'<tt>llvm.trunc.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_rint">'<tt>llvm.rint.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_nearbyint">'<tt>llvm.nearbyint.*</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_manip">Bit Manipulation Intrinsics</a>
<li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li>
</ol>
</li>
+ <li><a href="#spec_arithmetic">Specialised Arithmetic Intrinsics</a>
+ <ol>
+ <li><a href="#fmuladd">'<tt>llvm.fmuladd</tt> Intrinsic</a></li>
+ </ol>
+ </li>
<li><a href="#int_fp16">Half Precision Floating Point Intrinsics</a>
<ol>
<li><a href="#int_convert_to_fp16">'<tt>llvm.convert.to.fp16</tt>' Intrinsic</a></li>
'<tt>llvm.annotation.*</tt>' Intrinsic</a></li>
<li><a href="#int_trap">
'<tt>llvm.trap</tt>' Intrinsic</a></li>
+ <li><a href="#int_debugtrap">
+ '<tt>llvm.debugtrap</tt>' Intrinsic</a></li>
<li><a href="#int_stackprotector">
'<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
- <li><a href="#int_objectsize">
+
<li><a href="#int_objectsize">
'<tt>llvm.objectsize</tt>' Intrinsic</a></li>
- <li><a href="#int_expect">
+
<li><a href="#int_expect">
'<tt>llvm.expect</tt>' Intrinsic</a></li>
+ <li><a href="#int_donothing">
+ '<tt>llvm.donothing</tt>' Intrinsic</a></li>
</ol>
</li>
</ol>
linker. The symbols are removed by the linker from the final linked image
(executable or dynamic library).</dd>
- <dt><tt><b><a name="linkage_linker_private_weak_def_auto">linker_private_weak_def_auto</a></b></tt></dt>
- <dd>Similar to "<tt>linker_private_weak</tt>", but it's known that the address
- of the object is not taken. For instance, functions that had an inline
- definition, but the compiler decided not to inline it. Note,
- unlike <tt>linker_private</tt> and <tt>linker_private_weak</tt>,
- <tt>linker_private_weak_def_auto</tt> may have only <tt>default</tt>
- visibility. The symbols are removed by the linker from the final linked
- image (executable or dynamic library).</dd>
-
<dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt>
<dd>Similar to private, but the value shows as a local symbol
(<tt>STB_LOCAL</tt> in the case of ELF) in the object file. This
be merged with equivalent globals. These linkage types are otherwise the
same as their non-<tt>odr</tt> versions.</dd>
+ <dt><tt><b><a name="linkage_linkonce_odr_auto_hide">linkonce_odr_auto_hide</a></b></tt></dt>
+ <dd>Similar to "<tt>linkonce_odr</tt>", but nothing in the translation unit
+ takes the address of this definition. For instance, functions that had an
+ inline definition, but the compiler decided not to inline it.
+ <tt>linkonce_odr_auto_hide</tt> may have only <tt>default</tt> visibility.
+ The symbols are removed by the linker from the final linked image
+ (executable or dynamic library).</dd>
+
<dt><tt><b><a name="linkage_external">external</a></b></tt></dt>
<dd>If none of the above identifiers are used, the global is externally
visible, meaning that it participates in linkage and can be used to
<p>Global variables define regions of memory allocated at compilation time
instead of run-time. Global variables may optionally be initialized, may
have an explicit section to be placed in, and may have an optional explicit
- alignment specified. A variable may be defined as "thread_local", which
+ alignment specified.</p>
+
+<p>A variable may be defined as <tt>thread_local</tt>, which
means that it will not be shared by threads (each thread will have a
- separated copy of the variable). A variable may be defined as a global
+ separated copy of the variable). Not all targets support thread-local
+ variables. Optionally, a TLS model may be specified:</p>
+
+<dl>
+ <dt><b><tt>localdynamic</tt></b>:</dt>
+ <dd>For variables that are only used within the current shared library.</dd>
+
+ <dt><b><tt>initialexec</tt></b>:</dt>
+ <dd>For variables in modules that will not be loaded dynamically.</dd>
+
+ <dt><b><tt>localexec</tt></b>:</dt>
+ <dd>For variables defined in the executable and only used within it.</dd>
+</dl>
+
+<p>The models correspond to the ELF TLS models; see
+ <a href="http://people.redhat.com/drepper/tls.pdf">ELF
+ Handling For Thread-Local Storage</a> for more information on under which
+ circumstances the different models may be used. The target may choose a
+ different TLS model if the specified model is not supported, or if a better
+ choice of model can be made.</p>
+
+<p>A variable may be defined as a global
"constant," which indicates that the contents of the variable
will <b>never</b> be modified (enabling better optimization, allowing the
global data to be placed in the read-only section of an executable, etc).
@G = addrspace(5) constant float 1.0, section "foo", align 4
</pre>
+<p>The following example defines a thread-local global with
+ the <tt>initialexec</tt> TLS model:</p>
+
+<pre class="doc_code">
+@G = thread_local(initialexec) global i32 0, align 4
+</pre>
+
</div>
value to the function. The attribute implies that a hidden copy of the
pointee
is made between the caller and the callee, so the callee is unable to
- modify the value in the callee. This attribute is only valid on LLVM
+ modify the value in the caller. This attribute is only valid on LLVM
pointer arguments. It is generally used to pass structs and arrays by
value, but is also valid on pointers to scalars. The copy is considered
to belong to the caller not the callee (for example,
<dd>This indicates that the pointer parameter specifies the address of a
structure that is the return value of the function in the source program.
This pointer must be guaranteed by the caller to be valid: loads and
- stores to the structure may be assumed by the callee to not to trap. This
- may only be applied to the first parameter. This is not a valid attribute
- for return values. </dd>
+ stores to the structure may be assumed by the callee to not to trap and
+ to be properly aligned. This may only be applied to the first parameter.
+ This is not a valid attribute for return values. </dd>
<dt><tt><b><a name="noalias">noalias</a></b></tt></dt>
<dd>This indicates that pointer values
8-bits. If omitted, the natural stack alignment defaults to "unspecified",
which does not prevent any alignment promotions.</dd>
- <dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dt><tt>p[n]:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
- <i>preferred</i> alignments. All sizes are in bits. Specifying
- the <i>pref</i> alignment is optional. If omitted, the
- preceding <tt>:</tt> should be omitted too.</dd>
+ <i>preferred</i> alignments for address space <i>n</i>. All sizes are in
+ bits. Specifying the <i>pref</i> alignment is optional. If omitted, the
+ preceding <tt>:</tt> should be omitted too. The address space,
+ <i>n</i> is optional, and if not specified, denotes the default address
+ space 0. The value of <i>n</i> must be in the range [1,2^23).</dd>
<dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the alignment for an integer type of a given bit
<ul>
<li><tt>E</tt> - big endian</li>
<li><tt>p:64:64:64</tt> - 64-bit pointers with 64-bit alignment</li>
+ <li><tt>p1:32:32:32</tt> - 32-bit pointers with 32-bit alignment for
+ address space 1</li>
+ <li><tt>p2:16:32:32</tt> - 16-bit pointers with 32-bit alignment for
+ address space 2</li>
<li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li>
<li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li>
<li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li>
<li>If no match is found, and the type sought is an integer type, then the
smallest integer type that is larger than the bitwidth of the sought type
is used. If none of the specifications are larger than the bitwidth then
- the the largest integer type is used. For example, given the default
+ the largest integer type is used. For example, given the default
specifications above, the i7 type will use the alignment of i8 (next
largest) while both i65 and i256 will use the alignment of i64 (largest
specified).</li>
<p>Structures may optionally be "packed" structures, which indicate that the
alignment of the struct is one byte, and that there is no padding between
the elements. In non-packed structs, padding between field types is inserted
- as defined by the TargetData string in the module, which is required to match
+ as defined by the DataLayout string in the module, which is required to match
what the underlying code generator expects.</p>
<p>Structures can either be "literal" or "identified". A literal structure is
by <tt>0xM</tt> followed by 32 hexadecimal digits. The IEEE 128-bit format
is represented by <tt>0xL</tt> followed by 32 hexadecimal digits; no
currently supported target uses this format. Long doubles will only work if
- they match the long double format on your target. All hexadecimal formats
- are big-endian (sign bit at the left).</p>
+ they match the long double format on your target. The IEEE 16-bit format
+ (half precision) is represented by <tt>0xH</tt> followed by 4 hexadecimal
+ digits. All hexadecimal formats are big-endian (sign bit at the left).</p>
<p>There are no constants of type x86mmx.</p>
</div>
make it fit in <tt>TYPE</tt>.</dd>
<dt><b><tt>inttoptr (CST to TYPE)</tt></b></dt>
- <dd>Convert a integer constant to a pointer constant. TYPE must be a pointer
+ <dd>Convert an integer constant to a pointer constant. TYPE must be a pointer
type. CST must be of integer type. The CST value is zero extended,
truncated, or unchanged to make it fit in a pointer size. This one is
<i>really</i> dangerous!</dd>
</pre>
<p>Inline assembler expressions may <b>only</b> be used as the callee operand of
- a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we
- have:</p>
+ a <a href="#i_call"><tt>call</tt></a> or an
+ <a href="#i_invoke"><tt>invoke</tt></a> instruction.
+ Thus, typically we have:</p>
<pre class="doc_code">
%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
call void asm alignstack "eieio", ""()
</pre>
-<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come
- first.</p>
+<p>Inline asms also support using non-standard assembly dialects. The assumed
+ dialect is ATT. When the '<tt>inteldialect</tt>' keyword is present, the
+ inline asm is using the Intel dialect. Currently, ATT and Intel are the
+ only supported dialects. An example is:</p>
+
+<pre class="doc_code">
+call void asm inteldialect "eieio", ""()
+</pre>
+
+<p>If multiple keywords appear the '<tt>sideeffect</tt>' keyword must come
+ first, the '<tt>alignstack</tt>' keyword second and the
+ '<tt>inteldialect</tt>' keyword last.</p>
<!--
<p>TODO: The format of the asm and constraints string still need to be
<!-- _______________________________________________________________________ -->
<h4>
- <a name="fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a>
+ <a name="tbaa.struct">'<tt>tbaa.struct</tt>' Metadata</a>
+</h4>
+
+<div>
+
+<p>The <a href="#int_memcpy"><tt>llvm.memcpy</tt></a> is often used to implement
+aggregate assignment operations in C and similar languages, however it is
+defined to copy a contiguous region of memory, which is more than strictly
+necessary for aggregate types which contain holes due to padding. Also, it
+doesn't contain any TBAA information about the fields of the aggregate.</p>
+
+<p><tt>!tbaa.struct</tt> metadata can describe which memory subregions in a memcpy
+are padding and what the TBAA tags of the struct are.</p>
+
+<p>The current metadata format is very simple. <tt>!tbaa.struct</tt> metadata nodes
+ are a list of operands which are in conceptual groups of three. For each
+ group of three, the first operand gives the byte offset of a field in bytes,
+ the second gives its size in bytes, and the third gives its
+ tbaa tag. e.g.:</p>
+
+<div class="doc_code">
+<pre>
+!4 = metadata !{ i64 0, i64 4, metadata !1, i64 8, i64 4, metadata !2 }
+</pre>
+</div>
+
+<p>This describes a struct with two fields. The first is at offset 0 bytes
+ with size 4 bytes, and has tbaa tag !1. The second is at offset 8 bytes
+ and has size 4 bytes and has tbaa tag !2.</p>
+
+<p>Note that the fields need not be contiguous. In this example, there is a
+ 4 byte gap between the two fields. This gap represents padding which
+ does not carry useful data and need not be preserved.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="fpmath">'<tt>fpmath</tt>' Metadata</a>
</h4>
<div>
-<p><tt>fpaccuracy</tt> metadata may be attached to any instruction of floating
- point type. It expresses the maximum relative error of the result of
- that instruction, in ULPs. ULP is defined as follows:</p>
+<p><tt>fpmath</tt> metadata may be attached to any instruction of floating point
+ type. It can be used to express the maximum acceptable error in the result of
+ that instruction, in ULPs, thus potentially allowing the compiler to use a
+ more efficient but less accurate method of computing it. ULP is defined as
+ follows:</p>
<blockquote>
</blockquote>
-<p>The maximum relative error may be any rational number. The metadata node
- shall consist of a pair of unsigned integers respectively representing
- the numerator and denominator. For example, 2.5 ULP:</p>
+<p>The metadata node shall consist of a single positive floating point number
+ representing the maximum relative error, for example:</p>
<div class="doc_code">
<pre>
-!0 = metadata !{ i32 5, i32 2 }
+!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
</pre>
</div>
</div>
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="range">'<tt>range</tt>' Metadata</a>
+</h4>
+
+<div>
+<p><tt>range</tt> metadata may be attached only to loads of integer types. It
+ expresses the possible ranges the loaded value is in. The ranges are
+ represented with a flattened list of integers. The loaded value is known to
+ be in the union of the ranges defined by each consecutive pair. Each pair
+ has the following properties:</p>
+<ul>
+ <li>The type must match the type loaded by the instruction.</li>
+ <li>The pair <tt>a,b</tt> represents the range <tt>[a,b)</tt>.</li>
+ <li>Both <tt>a</tt> and <tt>b</tt> are constants.</li>
+ <li>The range is allowed to wrap.</li>
+ <li>The range should not represent the full or empty set. That is,
+ <tt>a!=b</tt>. </li>
+</ul>
+<p> In addition, the pairs must be in signed order of the lower bound and
+ they must be non-contiguous.</p>
+
+<p>Examples:</p>
+<div class="doc_code">
+<pre>
+ %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1
+ %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
+ %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5
+ %d = load i8* %z, align 1, !range !3 ; Can only be -2, -1, 3, 4 or 5
+...
+!0 = metadata !{ i8 0, i8 2 }
+!1 = metadata !{ i8 255, i8 2 }
+!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 }
+!3 = metadata !{ i8 -2, i8 0, i8 3, i8 6 }
+</pre>
+</div>
+</div>
</div>
</div>
<h5>Arguments:</h5>
<p>The first two operands of a '<tt>shufflevector</tt>' instruction are vectors
- with types that match each other. The third argument is a shuffle mask whose
+ with the same type. The third argument is a shuffle mask whose
element type is always 'i32'. The result of the instruction is a vector
whose length is the same as the shuffle mask and whose element type is the
same as the element type of the first two operands.</p>
<p>The optional constant <tt>align</tt> argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0 or an
- omitted <tt>align</tt> argument means that the operation has the preferential
+ omitted <tt>align</tt> argument means that the operation has the abi
alignment for the target. It is the responsibility of the code emitter to
ensure that the alignment information is correct. Overestimating the
alignment results in undefined behavior. Underestimating the alignment may
<p>The optional constant "align" argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0 or an
- omitted "align" argument means that the operation has the preferential
+ omitted "align" argument means that the operation has the abi
alignment for the target. It is the responsibility of the code emitter to
ensure that the alignment information is correct. Overestimating the
alignment results in an undefined behavior. Underestimating the alignment may
<p>The type of each index argument depends on the type it is indexing into.
When indexing into a (optionally packed) structure, only <tt>i32</tt>
- integer <b>constants</b> are allowed. When indexing into an array, pointer
- or vector, integers of any width are allowed, and they are not required to be
- constant. These integers are treated as signed values where relevant.</p>
+ integer <b>constants</b> are allowed (when using a vector of indices they
+ must all be the <b>same</b> <tt>i32</tt> integer constant). When indexing
+ into an array, pointer or vector, integers of any width are allowed, and
+ they are not required to be constant. These integers are treated as signed
+ values where relevant.</p>
<p>For example, let's consider a C code fragment and how it gets compiled to
LLVM:</p>
%iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
</pre>
-<p>In cases where the pointer argument is a vector of pointers, only a
- single index may be used, and the number of vector elements has to be
- the same. For example: </p>
+<p>In cases where the pointer argument is a vector of pointers, each index must
+ be a vector with the same number of elements. For example: </p>
<pre class="doc_code">
%A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets,
</pre>
</div>
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_fabs">'<tt>llvm.fabs.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.fabs</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.fabs.f32(float %Val)
+ declare double @llvm.fabs.f64(double %Val)
+ declare x86_fp80 @llvm.fabs.f80(x86_fp80 %Val)
+ declare fp128 @llvm.fabs.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.fabs.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.fabs.*</tt>' intrinsics return the absolute value of
+ the operand.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>fabs</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_floor">'<tt>llvm.floor.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.floor</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.floor.f32(float %Val)
+ declare double @llvm.floor.f64(double %Val)
+ declare x86_fp80 @llvm.floor.f80(x86_fp80 %Val)
+ declare fp128 @llvm.floor.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.floor.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.floor.*</tt>' intrinsics return the floor of
+ the operand.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>floor</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_ceil">'<tt>llvm.ceil.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.ceil</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.ceil.f32(float %Val)
+ declare double @llvm.ceil.f64(double %Val)
+ declare x86_fp80 @llvm.ceil.f80(x86_fp80 %Val)
+ declare fp128 @llvm.ceil.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.ceil.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.ceil.*</tt>' intrinsics return the ceiling of
+ the operand.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>ceil</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_trunc">'<tt>llvm.trunc.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.trunc</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.trunc.f32(float %Val)
+ declare double @llvm.trunc.f64(double %Val)
+ declare x86_fp80 @llvm.trunc.f80(x86_fp80 %Val)
+ declare fp128 @llvm.trunc.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.trunc.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.trunc.*</tt>' intrinsics returns the operand rounded to the
+ nearest integer not larger in magnitude than the operand.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>trunc</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_rint">'<tt>llvm.rint.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.rint</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.rint.f32(float %Val)
+ declare double @llvm.rint.f64(double %Val)
+ declare x86_fp80 @llvm.rint.f80(x86_fp80 %Val)
+ declare fp128 @llvm.rint.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.rint.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.rint.*</tt>' intrinsics returns the operand rounded to the
+ nearest integer. It may raise an inexact floating-point exception if the
+ operand isn't an integer.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>rint</tt> functions
+ would, and handles error conditions in the same way.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_nearbyint">'<tt>llvm.nearbyint.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<p>This is an overloaded intrinsic. You can use <tt>llvm.nearbyint</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+
+<pre>
+ declare float @llvm.nearbyint.f32(float %Val)
+ declare double @llvm.nearbyint.f64(double %Val)
+ declare x86_fp80 @llvm.nearbyint.f80(x86_fp80 %Val)
+ declare fp128 @llvm.nearbyint.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.nearbyint.ppcf128(ppc_fp128 %Val)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.nearbyint.*</tt>' intrinsics returns the operand rounded to the
+ nearest integer.</p>
+
+<h5>Arguments:</h5>
+<p>The argument and return value are floating point numbers of the same
+ type.</p>
+
+<h5>Semantics:</h5>
+<p>This function returns the same values as the libm <tt>nearbyint</tt>
+ functions would, and handles error conditions in the same way.</p>
+
+</div>
+
</div>
<!-- ======================================================================= -->
</div>
+<!-- ======================================================================= -->
+<h3>
+ <a name="spec_arithmetic">Specialised Arithmetic Intrinsics</a>
+</h3>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="fmuladd">'<tt>llvm.fmuladd.*</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare float @llvm.fmuladd.f32(float %a, float %b, float %c)
+ declare double @llvm.fmuladd.f64(double %a, double %b, double %c)
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.fmuladd.*</tt>' intrinsic functions represent multiply-add
+expressions that can be fused if the code generator determines that the fused
+expression would be legal and efficient.</p>
+
+<h5>Arguments:</h5>
+<p>The '<tt>llvm.fmuladd.*</tt>' intrinsics each take three arguments: two
+multiplicands, a and b, and an addend c.</p>
+
+<h5>Semantics:</h5>
+<p>The expression:</p>
+<pre>
+ %0 = call float @llvm.fmuladd.f32(%a, %b, %c)
+</pre>
+<p>is equivalent to the expression a * b + c, except that rounding will not be
+performed between the multiplication and addition steps if the code generator
+fuses the operations. Fusion is not guaranteed, even if the target platform
+supports it. If a fused multiply-add is required the corresponding llvm.fma.*
+intrinsic function should be used instead.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %r2 = call float @llvm.fmuladd.f32(float %a, float %b, float %c) ; yields {float}:r2 = (a * b) + c
+</pre>
+
+</div>
+
<!-- ======================================================================= -->
<h3>
<a name="int_fp16">Half Precision Floating Point Intrinsics</a>
<div>
-<p>Half precision floating point is a storage-only format. This means that it is
+<p>For most target platforms, half precision floating point is a storage-only
+ format. This means that it is
a dense encoding (in memory) but does not support computation in the
format.</p>
<h5>Syntax:</h5>
<pre>
- declare void @llvm.trap()
+ declare void @llvm.trap() noreturn nounwind
</pre>
<h5>Overview:</h5>
<p>None.</p>
<h5>Semantics:</h5>
-<p>This intrinsics is lowered to the target dependent trap instruction. If the
+<p>This intrinsic is lowered to the target dependent trap instruction. If the
target does not have a trap instruction, this intrinsic will be lowered to
- the call of the <tt>abort()</tt> function.</p>
+ a call of the <tt>abort()</tt> function.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_debugtrap">'<tt>llvm.debugtrap</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare void @llvm.debugtrap() nounwind
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>llvm.debugtrap</tt>' intrinsic.</p>
+
+<h5>Arguments:</h5>
+<p>None.</p>
+
+<h5>Semantics:</h5>
+<p>This intrinsic is lowered to code which is intended to cause an execution
+ trap with the intention of requesting the attention of a debugger.</p>
</div>
<h5>Syntax:</h5>
<pre>
- declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>)
- declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>)
+ declare i32 @llvm.objectsize.i32(i8* <object>, i1 <min>)
+ declare i64 @llvm.objectsize.i64(i8* <object>, i1 <min>)
</pre>
<h5>Overview:</h5>
<h5>Arguments:</h5>
<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first
argument is a pointer to or into the <tt>object</tt>. The second argument
- is a boolean 0 or 1. This argument determines whether you want the
- maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
- 1, variables are not allowed.</p>
+ is a boolean and determines whether <tt>llvm.objectsize</tt> returns 0 (if
+ true) or -1 (if false) when the object size is unknown.
+ The second argument only accepts constants.</p>
<h5>Semantics:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant
- representing the size of the object concerned, or <tt>i32/i64 -1 or 0</tt>,
- depending on the <tt>type</tt> argument, if the size cannot be determined at
- compile time.</p>
+<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to a constant representing
+ the size of the object concerned. If the size cannot be determined at compile
+ time, <tt>llvm.objectsize</tt> returns <tt>i32/i64 -1 or 0</tt>
+ (depending on the <tt>min</tt> argument).</p>
</div>
<!-- _______________________________________________________________________ -->
<p>This intrinsic is lowered to the <tt>val</tt>.</p>
</div>
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="int_donothing">'<tt>llvm.donothing</tt>' Intrinsic</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ declare void @llvm.donothing() nounwind readnone
+</pre>
+
+<h5>Overview:</h5>
+<p>The <tt>llvm.donothing</tt> intrinsic doesn't perform any operation. It's the
+only intrinsic that can be called with an invoke instruction.</p>
+
+<h5>Arguments:</h5>
+<p>None.</p>
+
+<h5>Semantics:</h5>
+<p>This intrinsic does nothing, and it's removed by optimizers and ignored by
+codegen.</p>
+</div>
+
</div>
</div>
projects / oota-llvm.git / blobdiff