diff options
| author | rdivacky <rdivacky@FreeBSD.org> | 2009-11-04 14:58:56 +0000 |
|---|---|---|
| committer | rdivacky <rdivacky@FreeBSD.org> | 2009-11-04 14:58:56 +0000 |
| commit | 7ff99155c39edd73ebf1c6adfa023b1048fee9a4 (patch) | |
| tree | b4dc751bcee540346911aa4115729eff2f991657 /docs/LangRef.html | |
| parent | d1f06de484602e72707476a6152974847bac1570 (diff) | |
| download | FreeBSD-src-7ff99155c39edd73ebf1c6adfa023b1048fee9a4.zip FreeBSD-src-7ff99155c39edd73ebf1c6adfa023b1048fee9a4.tar.gz | |
Update LLVM to r86025.
Diffstat (limited to 'docs/LangRef.html')
| -rw-r--r-- | docs/LangRef.html | 342 |
1 files changed, 171 insertions, 171 deletions
diff --git a/docs/LangRef.html b/docs/LangRef.html index 9741fdb..c06a88b 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -83,6 +83,7 @@ <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="#blockaddress">Addresses of Basic Blocks</a></li> <li><a href="#constantexprs">Constant Expressions</a></li> <li><a href="#metadata">Embedded Metadata</a></li> </ol> @@ -110,6 +111,7 @@ <li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li> <li><a href="#i_br">'<tt>br</tt>' Instruction</a></li> <li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li> + <li><a href="#i_indirectbr">'<tt>indirectbr</tt>' Instruction</a></li> <li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li> <li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li> <li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li> @@ -156,8 +158,6 @@ </li> <li><a href="#memoryops">Memory Access and Addressing Operations</a> <ol> - <li><a href="#i_malloc">'<tt>malloc</tt>' Instruction</a></li> - <li><a href="#i_free">'<tt>free</tt>' Instruction</a></li> <li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li> <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li> <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li> @@ -338,7 +338,7 @@ IR's", allowing many source languages to be mapped to them). By providing type information, LLVM can be used as the target of optimizations: for example, through pointer analysis, it can be proven that a C automatic - variable is never accessed outside of the current function... allowing it to + variable is never accessed outside of the current function, allowing it to be promoted to a simple SSA value instead of a memory location.</p> </div> @@ -359,12 +359,12 @@ </pre> </div> -<p>...because the definition of <tt>%x</tt> does not dominate all of its - uses. The LLVM infrastructure provides a verification pass that may be used - to verify that an LLVM module is well formed. This pass is automatically run - by the parser after parsing input assembly and by the optimizer before it - outputs bitcode. The violations pointed out by the verifier pass indicate - bugs in transformation passes or input to the parser.</p> +<p>because the definition of <tt>%x</tt> does not dominate all of its uses. The + LLVM infrastructure provides a verification pass that may be used to verify + that an LLVM module is well formed. This pass is automatically run by the + parser after parsing input assembly and by the optimizer before it outputs + bitcode. The violations pointed out by the verifier pass indicate bugs in + transformation passes or input to the parser.</p> </div> @@ -438,8 +438,8 @@ <div class="doc_code"> <pre> -<a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i> -<a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i> +%0 = <a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i> +%1 = <a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i> %result = <a href="#i_add">add</a> i32 %1, %1 </pre> </div> @@ -457,7 +457,7 @@ <li>Unnamed temporaries are numbered sequentially</li> </ol> -<p>...and it also shows a convention that we follow in this document. When +<p>It also shows a convention that we follow in this document. When demonstrating instructions, we will follow an instruction with a comment that defines the type and name of value produced. Comments are shown in italic text.</p> @@ -482,24 +482,21 @@ the "hello world" module:</p> <div class="doc_code"> -<pre><i>; Declare the string constant as a global constant...</i> -<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a - href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i> +<pre> +<i>; Declare the string constant as a global constant.</i> +<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i> <i>; External declaration of the puts function</i> -<a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i> +<a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i> <i>; Definition of main function</i> -define i32 @main() { <i>; i32()* </i> - <i>; Convert [13 x i8]* to i8 *...</i> - %cast210 = <a - href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i> +define i32 @main() { <i>; i32()* </i> + <i>; Convert [13 x i8]* to i8 *...</i> + %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i> - <i>; Call puts function to write out the string to stdout...</i> - <a - href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i> - <a - href="#i_ret">ret</a> i32 0<br>}<br> + <i>; Call puts function to write out the string to stdout.</i> + <a href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i> + <a href="#i_ret">ret</a> i32 0<br>}<br> </pre> </div> @@ -527,7 +524,7 @@ define i32 @main() { <i>; i32()* </ linkage:</p> <dl> - <dt><tt><b><a name="linkage_private">private</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_private">private</a></b></tt></dt> <dd>Global values with private linkage are only directly accessible by objects in the current module. In particular, linking code into a module with an private global value may cause the private to be renamed as necessary to @@ -535,7 +532,7 @@ define i32 @main() { <i>; i32()* </ references can be updated. This doesn't show up in any symbol table in the object file.</dd> - <dt><tt><b><a name="linkage_linker_private">linker_private</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_linker_private">linker_private</a></b></tt></dt> <dd>Similar to private, but the symbol is passed through the assembler and removed by the linker after evaluation. Note that (unlike private symbols) linker_private symbols are subject to coalescing by the linker: @@ -543,12 +540,12 @@ define i32 @main() { <i>; i32()* </ normal strong symbols, they 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> + <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 corresponds to the notion of the '<tt>static</tt>' keyword in C.</dd> - <dt><tt><b><a name="linkage_available_externally">available_externally</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_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 @@ -557,20 +554,20 @@ define i32 @main() { <i>; i32()* </ 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> + <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 the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced <tt>linkonce</tt> globals are allowed to be discarded.</dd> - <dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_weak">weak</a></b></tt></dt> <dd>"<tt>weak</tt>" linkage has the same merging semantics as <tt>linkonce</tt> linkage, except that unreferenced globals with <tt>weak</tt> linkage may not be discarded. This is used for globals that are declared "weak" in C source code.</dd> - <dt><tt><b><a name="linkage_common">common</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_common">common</a></b></tt></dt> <dd>"<tt>common</tt>" linkage is most similar to "<tt>weak</tt>" linkage, but they are used for tentative definitions in C, such as "<tt>int X;</tt>" at global scope. @@ -582,20 +579,20 @@ define i32 @main() { <i>; i32()* </ have common linkage.</dd> - <dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_appending">appending</a></b></tt></dt> <dd>"<tt>appending</tt>" linkage may only be applied to global variables of pointer to array type. When two global variables with appending linkage are linked together, the two global arrays are appended together. This is the LLVM, typesafe, equivalent of having the system linker append together "sections" with identical names when .o files are linked.</dd> - <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt> + <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_odr">linkonce_odr</a></b></tt>: </dt> - <dt><tt><b><a name="linkage_weak_odr">weak_odr</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_linkonce_odr">linkonce_odr</a></b></tt></dt> + <dt><tt><b><a name="linkage_weak_odr">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" - @@ -615,14 +612,14 @@ define i32 @main() { <i>; i32()* </ DLLs (Dynamic Link Libraries).</p> <dl> - <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt></dt> <dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function or variable via a global pointer to a pointer that is set up by the DLL exporting the symbol. On Microsoft Windows targets, the pointer name is formed by combining <code>__imp_</code> and the function or variable name.</dd> - <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt> + <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt></dt> <dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global pointer to a pointer in a DLL, so that it can be referenced with the <tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer @@ -935,24 +932,24 @@ declare signext i8 @returns_signed_char() <p>Currently, only the following parameter attributes are defined:</p> <dl> - <dt><tt>zeroext</tt></dt> + <dt><tt><b>zeroext</b></tt></dt> <dd>This indicates to the code generator that the parameter or return value should be zero-extended to a 32-bit value by the caller (for a parameter) or the callee (for a return value).</dd> - <dt><tt>signext</tt></dt> + <dt><tt><b>signext</b></tt></dt> <dd>This indicates to the code generator that the parameter or return value should be sign-extended to a 32-bit value by the caller (for a parameter) or the callee (for a return value).</dd> - <dt><tt>inreg</tt></dt> + <dt><tt><b>inreg</b></tt></dt> <dd>This indicates that this parameter or return value should be treated in a special target-dependent fashion during while emitting code for a function call or return (usually, by putting it in a register as opposed to memory, though some targets use it to distinguish between two different kinds of registers). Use of this attribute is target-specific.</dd> - <dt><tt><a name="byval">byval</a></tt></dt> + <dt><tt><b><a name="byval">byval</a></b></tt></dt> <dd>This indicates that the pointer parameter should really be passed by 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 @@ -967,7 +964,7 @@ declare signext i8 @returns_signed_char() generator that usually indicates a desired alignment for the synthesized stack slot.</dd> - <dt><tt>sret</tt></dt> + <dt><tt><b>sret</b></tt></dt> <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 @@ -975,7 +972,7 @@ declare signext i8 @returns_signed_char() may only be applied to the first parameter. This is not a valid attribute for return values. </dd> - <dt><tt>noalias</tt></dt> + <dt><tt><b>noalias</b></tt></dt> <dd>This indicates that the pointer does not alias any global or any other parameter. The caller is responsible for ensuring that this is the case. On a function return value, <tt>noalias</tt> additionally indicates @@ -985,12 +982,12 @@ declare signext i8 @returns_signed_char() <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias analysis</a>.</dd> - <dt><tt>nocapture</tt></dt> + <dt><tt><b>nocapture</b></tt></dt> <dd>This indicates that the callee does not make any copies of the pointer that outlive the callee itself. This is not a valid attribute for return values.</dd> - <dt><tt>nest</tt></dt> + <dt><tt><b>nest</b></tt></dt> <dd>This indicates that the pointer parameter can be excised using the <a href="#int_trampoline">trampoline intrinsics</a>. This is not a valid attribute for return values.</dd> @@ -1010,7 +1007,7 @@ declare signext i8 @returns_signed_char() <div class="doc_code"> <pre> -define void @f() gc "name" { ... +define void @f() gc "name" { ... } </pre> </div> @@ -1040,42 +1037,42 @@ define void @f() gc "name" { ... define void @f() noinline { ... } define void @f() alwaysinline { ... } define void @f() alwaysinline optsize { ... } -define void @f() optsize +define void @f() optsize { ... } </pre> </div> <dl> - <dt><tt>alwaysinline</tt></dt> + <dt><tt><b>alwaysinline</b></tt></dt> <dd>This attribute indicates that the inliner should attempt to inline this function into callers whenever possible, ignoring any active inlining size threshold for this caller.</dd> - <dt><tt>inlinehint</tt></dt> + <dt><tt><b>inlinehint</b></tt></dt> <dd>This attribute indicates that the source code contained a hint that inlining this function is desirable (such as the "inline" keyword in C/C++). It is just a hint; it imposes no requirements on the inliner.</dd> - <dt><tt>noinline</tt></dt> + <dt><tt><b>noinline</b></tt></dt> <dd>This attribute indicates that the inliner should never inline this function in any situation. This attribute may not be used together with the <tt>alwaysinline</tt> attribute.</dd> - <dt><tt>optsize</tt></dt> + <dt><tt><b>optsize</b></tt></dt> <dd>This attribute suggests that optimization passes and code generator passes make choices that keep the code size of this function low, and otherwise do optimizations specifically to reduce code size.</dd> - <dt><tt>noreturn</tt></dt> + <dt><tt><b>noreturn</b></tt></dt> <dd>This function attribute indicates that the function never returns normally. This produces undefined behavior at runtime if the function ever does dynamically return.</dd> - <dt><tt>nounwind</tt></dt> + <dt><tt><b>nounwind</b></tt></dt> <dd>This function attribute indicates that the function never returns with an unwind or exceptional control flow. If the function does unwind, its runtime behavior is undefined.</dd> - <dt><tt>readnone</tt></dt> + <dt><tt><b>readnone</b></tt></dt> <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 @@ -1086,7 +1083,7 @@ define void @f() optsize 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> + <dt><tt><b><a name="readonly">readonly</a></b></tt></dt> <dd>This attribute indicates that the function does not write through any pointer arguments (including <tt><a href="#byval">byval</a></tt> arguments) or otherwise modify any state (e.g. memory, control registers, @@ -1097,7 +1094,7 @@ define void @f() optsize 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> + <dt><tt><b><a name="ssp">ssp</a></b></tt></dt> <dd>This attribute indicates that the function should emit a stack smashing protector. It is in the form of a "canary"—a random value placed on the stack before the local variables that's checked upon return from the @@ -1108,7 +1105,7 @@ define void @f() optsize function that doesn't have an <tt>ssp</tt> attribute, then the resulting function will have an <tt>ssp</tt> attribute.</dd> - <dt><tt>sspreq</tt></dt> + <dt><tt><b>sspreq</b></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.<br> @@ -1118,14 +1115,14 @@ define void @f() optsize an <tt>ssp</tt> attribute, then the resulting function will have an <tt>sspreq</tt> attribute.</dd> - <dt><tt>noredzone</tt></dt> + <dt><tt><b>noredzone</b></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> + <dt><tt><b>noimplicitfloat</b></tt></dt> <dd>This attributes disables implicit floating point instructions.</dd> - <dt><tt>naked</tt></dt> + <dt><tt><b>naked</b></tt></dt> <dd>This attribute disables prologue / epilogue emission for the function. This can have very system-specific consequences.</dd> </dl> @@ -2172,6 +2169,34 @@ has undefined behavior.</p> </div> <!-- ======================================================================= --> +<div class="doc_subsection"><a name="blockaddress">Addresses of Basic + Blocks</a></div> +<div class="doc_text"> + +<p><b><tt>blockaddress(@function, %block)</tt></b></p> + +<p>The '<tt>blockaddress</tt>' constant computes the address of the specified + basic block in the specified function, and always has an i8* type. Taking + the address of the entry block is illegal.</p> + +<p>This value only has defined behavior when used as an operand to the + '<a href="#i_indirectbr"><tt>indirectbr</tt></a>' instruction or for comparisons + against null. Pointer equality tests between labels addresses is undefined + behavior - though, again, comparison against null is ok, and no label is + equal to the null pointer. This may also be passed around as an opaque + pointer sized value as long as the bits are not inspected. This allows + <tt>ptrtoint</tt> and arithmetic to be performed on these values so long as + the original value is reconstituted before the <tt>indirectbr</tt>.</p> + +<p>Finally, some targets may provide defined semantics when + using the value as the operand to an inline assembly, but that is target + specific. + </p> + +</div> + + +<!-- ======================================================================= --> <div class="doc_subsection"><a name="constantexprs">Constant Expressions</a> </div> @@ -2513,6 +2538,7 @@ Instructions</a> </div> '<a href="#i_ret"><tt>ret</tt></a>' instruction, the '<a href="#i_br"><tt>br</tt></a>' instruction, the '<a href="#i_switch"><tt>switch</tt></a>' instruction, the + '<a href="#i_indirectbr">'<tt>indirectbr</tt></a>' Instruction, the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the '<a href="#i_unwind"><tt>unwind</tt></a>' instruction, and the '<a href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p> @@ -2671,6 +2697,55 @@ IfUnequal: </div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_indirectbr">'<tt>indirectbr</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ] +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>indirectbr</tt>' instruction implements an indirect branch to a label + within the current function, whose address is specified by + "<tt>address</tt>". Address must be derived from a <a + href="#blockaddress">blockaddress</a> constant.</p> + +<h5>Arguments:</h5> + +<p>The '<tt>address</tt>' argument is the address of the label to jump to. The + rest of the arguments indicate the full set of possible destinations that the + address may point to. Blocks are allowed to occur multiple times in the + destination list, though this isn't particularly useful.</p> + +<p>This destination list is required so that dataflow analysis has an accurate + understanding of the CFG.</p> + +<h5>Semantics:</h5> + +<p>Control transfers to the block specified in the address argument. All + possible destination blocks must be listed in the label list, otherwise this + instruction has undefined behavior. This implies that jumps to labels + defined in other functions have undefined behavior as well.</p> + +<h5>Implementation:</h5> + +<p>This is typically implemented with a jump through a register.</p> + +<h5>Example:</h5> +<pre> + indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ] +</pre> + +</div> + + <!-- _______________________________________________________________________ --> <div class="doc_subsubsection"> <a name="i_invoke">'<tt>invoke</tt>' Instruction</a> @@ -3650,7 +3725,7 @@ Instruction</a> </div> <h5>Example:</h5> <pre> - %result = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i> + <result> = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i> </pre> </div> @@ -3686,7 +3761,7 @@ Instruction</a> </div> <h5>Example:</h5> <pre> - %result = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i> + <result> = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i> </pre> </div> @@ -3727,13 +3802,13 @@ Instruction</a> </div> <h5>Example:</h5> <pre> - %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, + <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i> - %result = shufflevector <4 x i32> %v1, <4 x i32> undef, + <result> = shufflevector <4 x i32> %v1, <4 x i32> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle. - %result = shufflevector <8 x i32> %v1, <8 x i32> undef, + <result> = shufflevector <8 x i32> %v1, <8 x i32> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, + <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > <i>; yields <8 x i32></i> </pre> @@ -3779,7 +3854,7 @@ Instruction</a> </div> <h5>Example:</h5> <pre> - %result = extractvalue {i32, float} %agg, 0 <i>; yields i32</i> + <result> = extractvalue {i32, float} %agg, 0 <i>; yields i32</i> </pre> </div> @@ -3818,7 +3893,7 @@ Instruction</a> </div> <h5>Example:</h5> <pre> - %result = insertvalue {i32, float} %agg, i32 1, 0 <i>; yields {i32, float}</i> + <result> = insertvalue {i32, float} %agg, i32 1, 0 <i>; yields {i32, float}</i> </pre> </div> @@ -3833,95 +3908,13 @@ Instruction</a> </div> <p>A key design point of an SSA-based representation is how it represents memory. In LLVM, no memory locations are in SSA form, which makes things - very simple. This section describes how to read, write, allocate, and free + very simple. This section describes how to read, write, and allocate memory in LLVM.</p> </div> <!-- _______________________________________________________________________ --> <div class="doc_subsubsection"> - <a name="i_malloc">'<tt>malloc</tt>' Instruction</a> -</div> - -<div class="doc_text"> - -<h5>Syntax:</h5> -<pre> - <result> = malloc <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i> -</pre> - -<h5>Overview:</h5> -<p>The '<tt>malloc</tt>' instruction allocates memory from the system heap and - returns a pointer to it. The object is always allocated in the generic - address space (address space zero).</p> - -<h5>Arguments:</h5> -<p>The '<tt>malloc</tt>' instruction allocates - <tt>sizeof(<type>)*NumElements</tt> 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 compatible with the type.</p> - -<p>'<tt>type</tt>' must be a sized type.</p> - -<h5>Semantics:</h5> -<p>Memory is allocated using the system "<tt>malloc</tt>" function, and a - pointer is returned. The result of a zero byte allocation is undefined. The - result is null if there is insufficient memory available.</p> - -<h5>Example:</h5> -<pre> - %array = malloc [4 x i8] <i>; yields {[%4 x i8]*}:array</i> - - %size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i> - %array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i> - %array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i> - %array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i> - %array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i> -</pre> - -<p>Note that the code generator does not yet respect the alignment value.</p> - -</div> - -<!-- _______________________________________________________________________ --> -<div class="doc_subsubsection"> - <a name="i_free">'<tt>free</tt>' Instruction</a> -</div> - -<div class="doc_text"> - -<h5>Syntax:</h5> -<pre> - free <type> <value> <i>; yields {void}</i> -</pre> - -<h5>Overview:</h5> -<p>The '<tt>free</tt>' instruction returns memory back to the unused memory heap - to be reallocated in the future.</p> - -<h5>Arguments:</h5> -<p>'<tt>value</tt>' shall be a pointer value that points to a value that was - allocated with the '<tt><a href="#i_malloc">malloc</a></tt>' instruction.</p> - -<h5>Semantics:</h5> -<p>Access to the memory pointed to by the pointer is no longer defined after - this instruction executes. If the pointer is null, the operation is a - noop.</p> - -<h5>Example:</h5> -<pre> - %array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i> - free [4 x i8]* %array -</pre> - -</div> - -<!-- _______________________________________________________________________ --> -<div class="doc_subsubsection"> <a name="i_alloca">'<tt>alloca</tt>' Instruction</a> </div> @@ -4253,7 +4246,7 @@ entry: <pre> %X = trunc i32 257 to i8 <i>; yields i8:1</i> %Y = trunc i32 123 to i1 <i>; yields i1:true</i> - %Y = trunc i32 122 to i1 <i>; yields i1:false</i> + %Z = trunc i32 122 to i1 <i>; yields i1:false</i> </pre> </div> @@ -4437,7 +4430,7 @@ entry: <pre> %X = fptoui double 123.0 to i32 <i>; yields i32:123</i> %Y = fptoui float 1.0E+300 to i1 <i>; yields undefined:1</i> - %X = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i> + %Z = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i> </pre> </div> @@ -4475,7 +4468,7 @@ entry: <pre> %X = fptosi double -123.0 to i32 <i>; yields i32:-123</i> %Y = fptosi float 1.0E-247 to i1 <i>; yields undefined:1</i> - %X = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i> + %Z = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i> </pre> </div> @@ -4619,8 +4612,8 @@ entry: <h5>Example:</h5> <pre> %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i> - %X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i> - %Y = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i> + %Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i> + %Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i> </pre> </div> @@ -6624,7 +6617,8 @@ LLVM</a>.</p> <h5>Example:</h5> <pre> -%ptr = malloc i32 +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* store i32 4, %ptr %result1 = load i32* %ptr <i>; yields {i32}:result1 = 4</i> @@ -6675,7 +6669,8 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* store i32 4, %ptr %val1 = add i32 4, 4 @@ -6730,7 +6725,8 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* store i32 4, %ptr %val1 = add i32 4, 4 @@ -6785,8 +6781,9 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 - store i32 4, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 4, %ptr %result1 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 ) <i>; yields {i32}:result1 = 4</i> %result2 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 ) @@ -6836,8 +6833,9 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 - store i32 8, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 8, %ptr %result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 ) <i>; yields {i32}:result1 = 8</i> %result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 ) @@ -6913,8 +6911,9 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 - store i32 0x0F0F, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 0x0F0F, %ptr %result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF ) <i>; yields {i32}:result0 = 0x0F0F</i> %result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF ) @@ -6991,8 +6990,9 @@ LLVM</a>.</p> <h5>Examples:</h5> <pre> -%ptr = malloc i32 - store i32 7, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 7, %ptr %result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 ) <i>; yields {i32}:result0 = 7</i> %result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 ) @@ -7043,8 +7043,8 @@ LLVM</a>.</p> <h5>Semantics:</h5> <p>This intrinsic indicates that before this point in the code, the value of the memory pointed to by <tt>ptr</tt> is dead. This means that it is known to - never be used and has an undefined value. A load from the pointer that is - preceded by this intrinsic can be replaced with + never be used and has an undefined value. A load from the pointer that + precedes this intrinsic can be replaced with <tt>'<a href="#undefvalues">undef</a>'</tt>.</p> </div> @@ -7278,7 +7278,7 @@ LLVM</a>.</p> <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-10-22 01:28:00 +0200 (Thu, 22 Oct 2009) $ + Last modified: $Date: 2009-11-02 01:25:26 +0100 (Mon, 02 Nov 2009) $ </address> </body> |
