<li><a href="#t_floating">Floating Point Types</a></li>
<li><a href="#t_void">Void Type</a></li>
<li><a href="#t_label">Label Type</a></li>
+ <li><a href="#t_metadata">Metadata Type</a></li>
</ol>
</li>
<li><a href="#t_derived">Derived Types</a>
<li><a href="#constants">Constants</a>
<ol>
<li><a href="#simpleconstants">Simple Constants</a></li>
- <li><a href="#aggregateconstants">Aggregate Constants</a></li>
+ <li><a href="#complexconstants">Complex Constants</a></li>
<li><a href="#globalconstants">Global Variable and Function Addresses</a></li>
<li><a href="#undefvalues">Undefined Values</a></li>
<li><a href="#constantexprs">Constant Expressions</a></li>
+ <li><a href="#metadata">Embedded Metadata</a></li>
</ol>
</li>
<li><a href="#othervalues">Other Values</a>
<li><a href="#binaryops">Binary Operations</a>
<ol>
<li><a href="#i_add">'<tt>add</tt>' Instruction</a></li>
+ <li><a href="#i_fadd">'<tt>fadd</tt>' Instruction</a></li>
<li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li>
+ <li><a href="#i_fsub">'<tt>fsub</tt>' Instruction</a></li>
<li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li>
+ <li><a href="#i_fmul">'<tt>fmul</tt>' Instruction</a></li>
<li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li>
<li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li>
<li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li>
<li><a href="#int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt> Intrinsics</a></li>
<li><a href="#int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt> Intrinsics</a></li>
<li><a href="#int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li>
</ol>
</li>
<li><a href="#int_debugger">Debugger intrinsics</a></li>
'<tt>static</tt>' keyword in C.
</dd>
+ <dt><tt><b><a name="available_externally">available_externally</a></b></tt>:
+ </dt>
+
+ <dd>Globals with "<tt>available_externally</tt>" linkage are never emitted
+ into the object file corresponding to the LLVM module. They exist to
+ allow inlining and other optimizations to take place given knowledge of the
+ definition of the global, which is known to be somewhere outside the module.
+ Globals with <tt>available_externally</tt> linkage are allowed to be discarded
+ at will, and are otherwise the same as <tt>linkonce_odr</tt>. This linkage
+ type is only allowed on definitions, not declarations.</dd>
+
<dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
<dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of
</dd>
<dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
+
<dd>The semantics of this linkage follow the ELF object file model: the
symbol is weak until linked, if not linked, the symbol becomes null instead
of being an undefined reference.
</dd>
+ <dt><tt><b><a name="linkage_linkonce">linkonce_odr</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_weak">weak_odr</a></b></tt>: </dt>
+ <dd>Some languages allow differing globals to be merged, such as two
+ functions with different semantics. Other languages, such as <tt>C++</tt>,
+ ensure that only equivalent globals are ever merged (the "one definition
+ rule" - "ODR"). Such languages can use the <tt>linkonce_odr</tt>
+ and <tt>weak_odr</tt> linkage types to indicate that the global will only
+ 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_external">externally visible</a></b></tt>:</dt>
<dd>If none of the above identifiers are used, the global is externally
external (i.e., lacking any linkage declarations), they are accessible
outside of the current module.</p>
<p>It is illegal for a function <i>declaration</i>
-to have any linkage type other than "externally visible", <tt>dllimport</tt>,
+to have any linkage type other than "externally visible", <tt>dllimport</tt>
or <tt>extern_weak</tt>.</p>
-<p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt>
-linkages.</p>
+<p>Aliases can have only <tt>external</tt>, <tt>internal</tt>, <tt>weak</tt>
+or <tt>weak_odr</tt> linkages.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_code">
<pre>
-declare i32 @printf(i8* noalias , ...)
+declare i32 @printf(i8* noalias nocapture, ...)
declare i32 @atoi(i8 zeroext)
declare signext i8 @returns_signed_char()
</pre>
behavior is undefined.</dd>
<dt><tt>readnone</tt></dt>
-<dd>This attribute indicates that the function computes its result (or the
-exception it throws) based strictly on its arguments, without dereferencing any
+<dd>This attribute indicates that the function computes its result (or decides to
+unwind an exception) based strictly on its arguments, without dereferencing any
pointer arguments or otherwise accessing any mutable state (e.g. memory, control
registers, etc) visible to caller functions. It does not write through any
pointer arguments (including <tt><a href="#byval">byval</a></tt> arguments) and
-never changes any state visible to callers.</dd>
+never changes any state visible to callers. This means that it cannot unwind
+exceptions by calling the <tt>C++</tt> exception throwing methods, but could
+use the <tt>unwind</tt> instruction.</dd>
<dt><tt><a name="readonly">readonly</a></tt></dt>
<dd>This attribute indicates that the function does not write through any
or otherwise modify any state (e.g. memory, control registers, etc) visible to
caller functions. It may dereference pointer arguments and read state that may
be set in the caller. A readonly function always returns the same value (or
-throws the same exception) when called with the same set of arguments and global
-state.</dd>
+unwinds an exception identically) when called with the same set of arguments
+and global state. It cannot unwind an exception by calling the <tt>C++</tt>
+exception throwing methods, but may use the <tt>unwind</tt> instruction.</dd>
<dt><tt><a name="ssp">ssp</a></tt></dt>
<dd>This attribute indicates that the function should emit a stack smashing
see if it has been overwritten. A heuristic is used to determine if a function
needs stack protectors or not.
-<p>If a function that has an <tt>ssp</tt> attribute is inlined into a function
+<br><br>If a function that has an <tt>ssp</tt> attribute is inlined into a function
that doesn't have an <tt>ssp</tt> attribute, then the resulting function will
-have an <tt>ssp</tt> attribute.</p></dd>
+have an <tt>ssp</tt> attribute.</dd>
<dt><tt>sspreq</tt></dt>
<dd>This attribute indicates that the function should <em>always</em> emit a
stack smashing protector. This overrides the <tt><a href="#ssp">ssp</a></tt>
function attribute.
-<p>If a function that has an <tt>sspreq</tt> attribute is inlined into a
+If a function that has an <tt>sspreq</tt> attribute is inlined into a
function that doesn't have an <tt>sspreq</tt> attribute or which has
an <tt>ssp</tt> attribute, then the resulting function will have
-an <tt>sspreq</tt> attribute.</p></dd>
+an <tt>sspreq</tt> attribute.</dd>
+
+<dt><tt>noredzone</tt></dt>
+<dd>This attribute indicates that the code generator should not use a
+red zone, even if the target-specific ABI normally permits it.
+</dd>
+
+<dt><tt>noimplicitfloat</tt></dt>
+<dd>This attributes disables implicit floating point instructions.</dd>
+
</dl>
</div>
<dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the alignment for an aggregate type of a given bit
<i>size</i>.</dd>
+ <dt><tt>s<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the alignment for a stack object of a given bit
+ <i>size</i>.</dd>
</dl>
<p>When constructing the data layout for a given target, LLVM starts with a
default set of specifications which are then (possibly) overriden by the
<li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li>
<li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li>
<li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li>
+ <li><tt>s0:64:64</tt> - stack objects are 64-bit aligned</li>
</ul>
<p>When LLVM is determining the alignment for a given type, it uses the
following rules:</p>
<a href="#t_vector">vector</a>,
<a href="#t_struct">structure</a>,
<a href="#t_array">array</a>,
- <a href="#t_label">label</a>.
+ <a href="#t_label">label</a>,
+ <a href="#t_metadata">metadata</a>.
</td>
</tr>
<tr>
<td><a href="#t_primitive">primitive</a></td>
<td><a href="#t_label">label</a>,
<a href="#t_void">void</a>,
- <a href="#t_floating">floating point</a>.</td>
+ <a href="#t_floating">floating point</a>,
+ <a href="#t_metadata">metadata</a>.</td>
</tr>
<tr>
<td><a href="#t_derived">derived</a></td>
</pre>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_metadata">Metadata Type</a> </div>
+
+<div class="doc_text">
+<h5>Overview:</h5>
+<p>The metadata type represents embedded metadata. The only derived type that
+may contain metadata is <tt>metadata*</tt> or a function type that returns or
+takes metadata typed parameters, but not pointer to metadata types.</p>
+
+<h5>Syntax:</h5>
+
+<pre>
+ metadata
+</pre>
+</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div>
<h5>Examples:</h5>
<table class="layout">
- <tbody>
- <tr>
- <td><tt>i1</tt></td>
- <td>a single-bit integer.</td>
- </tr><tr>
- <td><tt>i32</tt></td>
- <td>a 32-bit integer.</td>
- </tr><tr>
- <td><tt>i1942652</tt></td>
- <td>a really big integer of over 1 million bits.</td>
+ <tr class="layout">
+ <td class="left"><tt>i1</tt></td>
+ <td class="left">a single-bit integer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i32</tt></td>
+ <td class="left">a 32-bit integer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i1942652</tt></td>
+ <td class="left">a really big integer of over 1 million bits.</td>
</tr>
- </tbody>
</table>
<p>Note that the code generator does not yet support large integer types
references (with their equivalent as named type declarations) include:</p>
<pre>
- { \2 * } %x = type { %t* }
+ { \2 * } %x = type { %x* }
{ \2 }* %y = type { %y }*
\1* %z = type %z*
</pre>
</dl>
-<p>The one non-intuitive notation for constants is the optional hexadecimal form
+<p>The one non-intuitive notation for constants is the hexadecimal form
of floating point constants. For example, the form '<tt>double
0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double
4.5e+15</tt>'. The only time hexadecimal floating point constants are required
(and the only time that they are generated by the disassembler) is when a
floating point constant must be emitted but it cannot be represented as a
-decimal floating point number. For example, NaN's, infinities, and other
+decimal floating point number in a reasonable number of digits. For example,
+NaN's, infinities, and other
special values are represented in their IEEE hexadecimal format so that
assembly and disassembly do not cause any bits to change in the constants.</p>
-
+<p>When using the hexadecimal form, constants of types float and double are
+represented using the 16-digit form shown above (which matches the IEEE754
+representation for double); float values must, however, be exactly representable
+as IEE754 single precision.
+Hexadecimal format is always used for long
+double, and there are three forms of long double. The 80-bit
+format used by x86 is represented as <tt>0xK</tt>
+followed by 20 hexadecimal digits.
+The 128-bit format used by PowerPC (two adjacent doubles) is represented
+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>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="aggregateconstants">Aggregate Constants</a>
+<div class="doc_subsection">
+<a name="aggregateconstants"> <!-- old anchor -->
+<a name="complexconstants">Complex Constants</a></a>
</div>
<div class="doc_text">
-<p>Aggregate constants arise from aggregation of simple constants
-and smaller aggregate constants.</p>
+<p>Complex constants are a (potentially recursive) combination of simple
+constants and smaller complex constants.</p>
<dl>
<dt><b>Structure constants</b></dt>
large arrays) and is always exactly equivalent to using explicit zero
initializers.
</dd>
+
+ <dt><b>Metadata node</b></dt>
+
+ <dd>A metadata node is a structure-like constant with
+ <a href="#t_metadata">metadata type</a>. For example:
+ "<tt>metadata !{ i32 0, metadata !"test" }</tt>". Unlike other constants
+ that are meant to be interpreted as part of the instruction stream, metadata
+ is a place to attach additional information such as debug info.
+ </dd>
</dl>
</div>
<i>really</i> dangerous!</dd>
<dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
- <dd>Convert a constant, CST, to another TYPE. The size of CST and TYPE must be
- identical (same number of bits). The conversion is done as if the CST value
- was stored to memory and read back as TYPE. In other words, no bits change
- with this operator, just the type. This can be used for conversion of
- vector types to any other type, as long as they have the same bit width. For
- pointers it is only valid to cast to another pointer type. It is not valid
- to bitcast to or from an aggregate type.
- </dd>
+ <dd>Convert a constant, CST, to another TYPE. The constraints of the operands
+ are the same as those for the <a href="#i_bitcast">bitcast
+ instruction</a>.</dd>
<dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
</dl>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="metadata">Embedded Metadata</a>
+</div>
+
+<div class="doc_text">
+
+<p>Embedded metadata provides a way to attach arbitrary data to the
+instruction stream without affecting the behaviour of the program. There are
+two metadata primitives, strings and nodes. All metadata has the
+<tt>metadata</tt> type and is identified in syntax by a preceding exclamation
+point ('<tt>!</tt>').
+</p>
+
+<p>A metadata string is a string surrounded by double quotes. It can contain
+any character by escaping non-printable characters with "\xx" where "xx" is
+the two digit hex code. For example: "<tt>!"test\00"</tt>".
+</p>
+
+<p>Metadata nodes are represented with notation similar to structure constants
+(a comma separated list of elements, surrounded by braces and preceeded by an
+exclamation point). For example: "<tt>!{ metadata !"test\00", i32 10}</tt>".
+</p>
+
+<p>A metadata node will attempt to track changes to the values it holds. In
+the event that a value is deleted, it will be replaced with a typeless
+"<tt>null</tt>", such as "<tt>metadata !{null, i32 10}</tt>".</p>
+
+<p>Optimizations may rely on metadata to provide additional information about
+the program that isn't available in the instructions, or that isn't easily
+computable. Similarly, the code generator may expect a certain metadata format
+to be used to express debugging information.</p>
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="othervalues">Other Values</a> </div>
<!-- *********************************************************************** -->
<pre>
ret i32 5 <i>; Return an integer value of 5</i>
ret void <i>; Return from a void function</i>
- ret { i32, i8 } { i32 4, i8 2 } <i>; Return an aggregate of values 4 and 2</i>
+ ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i>
</pre>
<p>Note that the code generator does not yet fully support large
to the '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p>
<h5>Example:</h5>
-<pre>Test:<br> %cond = <a href="#i_icmp">icmp</a> eq, i32 %a, %b<br> br i1 %cond, label %IfEqual, label %IfUnequal<br>IfEqual:<br> <a
+<pre>Test:<br> %cond = <a href="#i_icmp">icmp</a> eq i32 %a, %b<br> br i1 %cond, label %IfEqual, label %IfUnequal<br>IfEqual:<br> <a
href="#i_ret">ret</a> i32 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> i32 0<br></pre>
</div>
<!-- _______________________________________________________________________ -->
exception. Additionally, this is important for implementation of
'<tt>catch</tt>' clauses in high-level languages that support them.</p>
+<p>For the purposes of the SSA form, the definition of the value
+returned by the '<tt>invoke</tt>' instruction is deemed to occur on
+the edge from the current block to the "normal" label. If the callee
+unwinds then no return value is available.</p>
+
<h5>Example:</h5>
<pre>
%retval = invoke i32 @Test(i32 15) to label %Continue
<h5>Arguments:</h5>
<p>The two arguments to the '<tt>add</tt>' instruction must be <a
- href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>, or
- <a href="#t_vector">vector</a> values. Both arguments must have identical
- types.</p>
+ href="#t_integer">integer</a> or
+ <a href="#t_vector">vector</a> of integer values. Both arguments must
+ have identical types.</p>
<h5>Semantics:</h5>
-<p>The value produced is the integer or floating point sum of the two
-operands.</p>
+<p>The value produced is the integer sum of the two operands.</p>
-<p>If an integer sum has unsigned overflow, the result returned is the
+<p>If the sum has unsigned overflow, the result returned is the
mathematical result modulo 2<sup>n</sup>, where n is the bit width of
the result.</p>
</pre>
</div>
<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_fadd">'<tt>fadd</tt>' Instruction</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<pre>
+ <result> = fadd <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>fadd</tt>' instruction returns the sum of its two operands.</p>
+
+<h5>Arguments:</h5>
+
+<p>The two arguments to the '<tt>fadd</tt>' instruction must be
+<a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
+floating point values. Both arguments must have identical types.</p>
+
+<h5>Semantics:</h5>
+
+<p>The value produced is the floating point sum of the two operands.</p>
+
+<h5>Example:</h5>
+
+<pre>
+ <result> = fadd float 4.0, %var <i>; yields {float}:result = 4.0 + %var</i>
+</pre>
+</div>
+<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_sub">'<tt>sub</tt>' Instruction</a>
</div>
<h5>Arguments:</h5>
<p>The two arguments to the '<tt>sub</tt>' instruction must be <a
- href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>,
- or <a href="#t_vector">vector</a> values. Both arguments must have identical
- types.</p>
+ href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
+ integer values. Both arguments must have identical types.</p>
<h5>Semantics:</h5>
-<p>The value produced is the integer or floating point difference of
-the two operands.</p>
+<p>The value produced is the integer difference of the two operands.</p>
-<p>If an integer difference has unsigned overflow, the result returned is the
+<p>If the difference has unsigned overflow, the result returned is the
mathematical result modulo 2<sup>n</sup>, where n is the bit width of
the result.</p>
</pre>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_fsub">'<tt>fsub</tt>' Instruction</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<pre>
+ <result> = fsub <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>fsub</tt>' instruction returns the difference of its two
+operands.</p>
+
+<p>Note that the '<tt>fsub</tt>' instruction is used to represent the
+'<tt>fneg</tt>' instruction present in most other intermediate
+representations.</p>
+
+<h5>Arguments:</h5>
+
+<p>The two arguments to the '<tt>fsub</tt>' instruction must be <a
+ <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a>
+ of floating point values. Both arguments must have identical types.</p>
+
+<h5>Semantics:</h5>
+
+<p>The value produced is the floating point difference of the two operands.</p>
+
+<h5>Example:</h5>
+<pre>
+ <result> = fsub float 4.0, %var <i>; yields {float}:result = 4.0 - %var</i>
+ <result> = fsub float -0.0, %val <i>; yields {float}:result = -%var</i>
+</pre>
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_mul">'<tt>mul</tt>' Instruction</a>
<h5>Arguments:</h5>
<p>The two arguments to the '<tt>mul</tt>' instruction must be <a
-href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>,
-or <a href="#t_vector">vector</a> values. Both arguments must have identical
-types.</p>
+href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+values. Both arguments must have identical types.</p>
<h5>Semantics:</h5>
-<p>The value produced is the integer or floating point product of the
-two operands.</p>
+<p>The value produced is the integer product of the two operands.</p>
-<p>If the result of an integer multiplication has unsigned overflow,
+<p>If the result of the multiplication has unsigned overflow,
the result returned is the mathematical result modulo
2<sup>n</sup>, where n is the bit width of the result.</p>
<p>Because LLVM integers use a two's complement representation, and the
</pre>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_fmul">'<tt>fmul</tt>' Instruction</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre> <result> = fmul <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+</pre>
+<h5>Overview:</h5>
+<p>The '<tt>fmul</tt>' instruction returns the product of its two
+operands.</p>
+
+<h5>Arguments:</h5>
+
+<p>The two arguments to the '<tt>fmul</tt>' instruction must be
+<a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a>
+of floating point values. Both arguments must have identical types.</p>
+
+<h5>Semantics:</h5>
+
+<p>The value produced is the floating point product of the two operands.</p>
+
+<h5>Example:</h5>
+<pre> <result> = fmul float 4.0, %var <i>; yields {float}:result = 4.0 * %var</i>
+</pre>
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_udiv">'<tt>udiv</tt>' Instruction
</a></div>
bytes of memory from the operating system and returns a pointer of the
appropriate type to the program. If "NumElements" is specified, it is the
number of elements allocated, otherwise "NumElements" is defaulted to be one.
-If a constant alignment is specified, the value result of the allocation is guaranteed to
-be aligned to at least that boundary. If not specified, or if zero, the target can
-choose to align the allocation on any convenient boundary.</p>
+If a constant alignment is specified, the value result of the allocation is
+guaranteed to be aligned to at least that boundary. If not specified, or if
+zero, the target can choose to align the allocation on any convenient boundary
+compatible with the type.</p>
<p>'<tt>type</tt>' must be a sized type.</p>
bytes of memory on the runtime stack, returning a pointer of the
appropriate type to the program. If "NumElements" is specified, it is the
number of elements allocated, otherwise "NumElements" is defaulted to be one.
-If a constant alignment is specified, the value result of the allocation is guaranteed
-to be aligned to at least that boundary. If not specified, or if zero, the target
-can choose to align the allocation on any convenient boundary.</p>
+If a constant alignment is specified, the value result of the allocation is
+guaranteed to be aligned to at least that boundary. If not specified, or if
+zero, the target can choose to align the allocation on any convenient boundary
+compatible with the type.</p>
<p>'<tt>type</tt>' may be any sized type.</p>
<h5>Semantics:</h5>
-<p>Memory is allocated; a pointer is returned. The operation is undefiend if
+<p>Memory is allocated; a pointer is returned. The operation is undefined if
there is insufficient stack space for the allocation. '<tt>alloca</tt>'d
memory is automatically released when the function returns. The '<tt>alloca</tt>'
instruction is commonly used to represent automatic variables that must
safe.
</p>
<h5>Semantics:</h5>
-<p>The location of memory pointed to is loaded.</p>
+<p>The location of memory pointed to is loaded. If the value being loaded
+is of scalar type then the number of bytes read does not exceed the minimum
+number of bytes needed to hold all bits of the type. For example, loading an
+<tt>i24</tt> reads at most three bytes. When loading a value of a type like
+<tt>i20</tt> with a size that is not an integral number of bytes, the result
+is undefined if the value was not originally written using a store of the
+same type.</p>
<h5>Examples:</h5>
<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
<a
</p>
<h5>Semantics:</h5>
<p>The contents of memory are updated to contain '<tt><value></tt>'
-at the location specified by the '<tt><pointer></tt>' operand.</p>
+at the location specified by the '<tt><pointer></tt>' operand.
+If '<tt><value></tt>' is of scalar type then the number of bytes
+written does not exceed the minimum number of bytes needed to hold all
+bits of the type. For example, storing an <tt>i24</tt> writes at most
+three bytes. When writing a value of a type like <tt>i20</tt> with a
+size that is not an integral number of bytes, it is unspecified what
+happens to the extra bits that do not belong to the type, but they will
+typically be overwritten.</p>
<h5>Example:</h5>
<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
store i32 3, i32* %ptr <i>; yields {void}</i>
<p>The type of each index argument depends on the type it is indexing into.
When indexing into a (packed) structure, only <tt>i32</tt> integer
<b>constants</b> are allowed. When indexing into an array, pointer or vector,
-only integers of 32 or 64 bits are allowed (also non-constants). 32-bit values
-will be sign extended to 64-bits if required.</p>
+integers of any width are allowed (also non-constants).</p>
<p>For example, let's consider a C code fragment and how it gets
compiled to LLVM:</p>
}
</pre>
-<p>Note that it is undefined to access an array out of bounds: array and
-pointer indexes must always be within the defined bounds of the array type.
-The one exception for this rule is zero length arrays. These arrays are
-defined to be accessible as variable length arrays, which requires access
-beyond the zero'th element.</p>
+<p>Note that it is undefined to access an array out of bounds: array
+and pointer indexes must always be within the defined bounds of the
+array type when accessed with an instruction that dereferences the
+pointer (e.g. a load or store instruction). The one exception for
+this rule is zero length arrays. These arrays are defined to be
+accessible as variable length arrays, which requires access beyond the
+zero'th element.</p>
<p>The getelementptr instruction is often confusing. For some more insight
into how it works, see <a href="GetElementPtr.html">the getelementptr
%vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
<i>; yields i8*:eptr</i>
%eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
+ <i>; yields i32*:iptr</i>
+ %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
</pre>
</div>
block and the PHI instructions: i.e. PHI instructions must be first in
a basic block.</p>
+<p>For the purposes of the SSA form, the use of each incoming value is
+deemed to occur on the edge from the corresponding predecessor block
+to the current block (but after any definition of an '<tt>invoke</tt>'
+instruction's return value on the same edge).</p>
+
<h5>Semantics:</h5>
<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.umul.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.umul.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.umul.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
+a unsigned multiplication of the two arguments, and indicate whether an overflow
+occurred during the unsigned multiplication.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo unsigned
+multiplication.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
+an unsigned multiplication of the two arguments. They return a structure —
+the first element of which is the multiplication, and the second element of
+which is a bit specifying if the unsigned multiplication resulted in an
+overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
+</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_debugger">Debugger Intrinsics</a>