+<table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr>
+ <th>Value</th>
+ <th>Behavior</th>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td align="left">
+ <dl>
+ <dt><b>Error</b></dt>
+ <dd>Emits an error if two values disagree. It is an error to have an ID
+ with both an Error and a Warning behavior.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td align="left">
+ <dl>
+ <dt><b>Warning</b></dt>
+ <dd>Emits a warning if two values disagree.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td align="left">
+ <dl>
+ <dt><b>Require</b></dt>
+ <dd>Emits an error when the specified value is not present or doesn't
+ have the specified value. It is an error for two (or more)
+ <tt>llvm.module.flags</tt> with the same ID to have the Require
+ behavior but different values. There may be multiple Require flags
+ per ID.</dd>
+ </dl>
+ </td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td align="left">
+ <dl>
+ <dt><b>Override</b></dt>
+ <dd>Uses the specified value if the two values disagree. It is an
+ error for two (or more) <tt>llvm.module.flags</tt> with the same
+ ID to have the Override behavior but different values.</dd>
+ </dl>
+ </td>
+ </tr>
+ </tbody>
+</table>
+
+<p>An example of module flags:</p>
+
+<pre class="doc_code">
+!0 = metadata !{ i32 1, metadata !"foo", i32 1 }
+!1 = metadata !{ i32 4, metadata !"bar", i32 37 }
+!2 = metadata !{ i32 2, metadata !"qux", i32 42 }
+!3 = metadata !{ i32 3, metadata !"qux",
+ metadata !{
+ metadata !"foo", i32 1
+ }
+}
+!llvm.module.flags = !{ !0, !1, !2, !3 }
+</pre>
+
+<ul>
+ <li><p>Metadata <tt>!0</tt> has the ID <tt>!"foo"</tt> and the value '1'. The
+ behavior if two or more <tt>!"foo"</tt> flags are seen is to emit an
+ error if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!1</tt> has the ID <tt>!"bar"</tt> and the value '37'. The
+ behavior if two or more <tt>!"bar"</tt> flags are seen is to use the
+ value '37' if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!2</tt> has the ID <tt>!"qux"</tt> and the value '42'. The
+ behavior if two or more <tt>!"qux"</tt> flags are seen is to emit a
+ warning if their values are not equal.</p></li>
+
+ <li><p>Metadata <tt>!3</tt> has the ID <tt>!"qux"</tt> and the value:</p>
+
+<pre class="doc_code">
+metadata !{ metadata !"foo", i32 1 }
+</pre>
+
+ <p>The behavior is to emit an error if the <tt>llvm.module.flags</tt> does
+ not contain a flag with the ID <tt>!"foo"</tt> that has the value
+ '1'. If two or more <tt>!"qux"</tt> flags exist, then they must have
+ the same value or an error will be issued.</p></li>
+</ul>
+
+
+<!-- ======================================================================= -->
+<h3>
+<a name="objc_gc_flags">Objective-C Garbage Collection Module Flags Metadata</a>
+</h3>
+
+<div>
+
+<p>On the Mach-O platform, Objective-C stores metadata about garbage collection
+ in a special section called "image info". The metadata consists of a version
+ number and a bitmask specifying what types of garbage collection are
+ supported (if any) by the file. If two or more modules are linked together
+ their garbage collection metadata needs to be merged rather than appended
+ together.</p>
+
+<p>The Objective-C garbage collection module flags metadata consists of the
+ following key-value pairs:</p>
+
+<table border="1" cellspacing="0" cellpadding="4">
+ <col width="30%">
+ <tbody>
+ <tr>
+ <th>Key</th>
+ <th>Value</th>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Version</tt></td>
+ <td align="left"><b>[Required]</b> — The Objective-C ABI
+ version. Valid values are 1 and 2.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Image Info Version</tt></td>
+ <td align="left"><b>[Required]</b> — The version of the image info
+ section. Currently always 0.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Image Info Section</tt></td>
+ <td align="left"><b>[Required]</b> — The section to place the
+ metadata. Valid values are <tt>"__OBJC, __image_info, regular"</tt> for
+ Objective-C ABI version 1, and <tt>"__DATA,__objc_imageinfo, regular,
+ no_dead_strip"</tt> for Objective-C ABI version 2.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C Garbage Collection</tt></td>
+ <td align="left"><b>[Required]</b> — Specifies whether garbage
+ collection is supported or not. Valid values are 0, for no garbage
+ collection, and 2, for garbage collection supported.</td>
+ </tr>
+ <tr>
+ <td><tt>Objective-C GC Only</tt></td>
+ <td align="left"><b>[Optional]</b> — Specifies that only garbage
+ collection is supported. If present, its value must be 6. This flag
+ requires that the <tt>Objective-C Garbage Collection</tt> flag have the
+ value 2.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Some important flag interactions:</p>
+
+<ul>
+ <li>If a module with <tt>Objective-C Garbage Collection</tt> set to 0 is
+ merged with a module with <tt>Objective-C Garbage Collection</tt> set to
+ 2, then the resulting module has the <tt>Objective-C Garbage
+ Collection</tt> flag set to 0.</li>
+
+ <li>A module with <tt>Objective-C Garbage Collection</tt> set to 0 cannot be
+ merged with a module with <tt>Objective-C GC Only</tt> set to 6.</li>
+</ul>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="intrinsic_globals">Intrinsic Global Variables</a>
+</h2>
+<!-- *********************************************************************** -->
+<div>
+<p>LLVM has a number of "magic" global variables that contain data that affect
+code generation or other IR semantics. These are documented here. All globals
+of this sort should have a section specified as "<tt>llvm.metadata</tt>". This
+section and all globals that start with "<tt>llvm.</tt>" are reserved for use
+by LLVM.</p>
+
+<!-- ======================================================================= -->
+<h3>
+<a name="intg_used">The '<tt>llvm.used</tt>' Global Variable</a>
+</h3>
+
+<div>
+
+<p>The <tt>@llvm.used</tt> global is an array with i8* element type which has <a
+href="#linkage_appending">appending linkage</a>. This array contains a list of
+pointers to global variables and functions which may optionally have a pointer
+cast formed of bitcast or getelementptr. For example, a legal use of it is:</p>
+
+<div class="doc_code">
+<pre>
+@X = global i8 4
+@Y = global i32 123
+
+@llvm.used = appending global [2 x i8*] [
+ i8* @X,
+ i8* bitcast (i32* @Y to i8*)
+], section "llvm.metadata"
+</pre>
+</div>
+
+<p>If a global variable appears in the <tt>@llvm.used</tt> list, then the
+ compiler, assembler, and linker are required to treat the symbol as if there
+ is a reference to the global that it cannot see. For example, if a variable
+ has internal linkage and no references other than that from
+ the <tt>@llvm.used</tt> list, it cannot be deleted. This is commonly used to
+ represent references from inline asms and other things the compiler cannot
+ "see", and corresponds to "<tt>attribute((used))</tt>" in GNU C.</p>
+
+<p>On some targets, the code generator must emit a directive to the assembler or
+ object file to prevent the assembler and linker from molesting the
+ symbol.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="intg_compiler_used">
+ The '<tt>llvm.compiler.used</tt>' Global Variable
+ </a>
+</h3>
+
+<div>
+
+<p>The <tt>@llvm.compiler.used</tt> directive is the same as the
+ <tt>@llvm.used</tt> directive, except that it only prevents the compiler from
+ touching the symbol. On targets that support it, this allows an intelligent
+ linker to optimize references to the symbol without being impeded as it would
+ be by <tt>@llvm.used</tt>.</p>
+
+<p>This is a rare construct that should only be used in rare circumstances, and
+ should not be exposed to source languages.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+<a name="intg_global_ctors">The '<tt>llvm.global_ctors</tt>' Global Variable</a>
+</h3>
+
+<div>
+
+<div class="doc_code">
+<pre>
+%0 = type { i32, void ()* }
+@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
+</pre>
+</div>
+
+<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor
+ functions and associated priorities. The functions referenced by this array
+ will be called in ascending order of priority (i.e. lowest first) when the
+ module is loaded. The order of functions with the same priority is not
+ defined.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+<a name="intg_global_dtors">The '<tt>llvm.global_dtors</tt>' Global Variable</a>
+</h3>
+
+<div>
+
+<div class="doc_code">
+<pre>
+%0 = type { i32, void ()* }
+@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
+</pre>
+</div>
+
+<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions
+ and associated priorities. The functions referenced by this array will be
+ called in descending order of priority (i.e. highest first) when the module
+ is loaded. The order of functions with the same priority is not defined.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="instref">Instruction Reference</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>The LLVM instruction set consists of several different classifications of
+ instructions: <a href="#terminators">terminator
+ instructions</a>, <a href="#binaryops">binary instructions</a>,
+ <a href="#bitwiseops">bitwise binary instructions</a>,
+ <a href="#memoryops">memory instructions</a>, and
+ <a href="#otherops">other instructions</a>.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="terminators">Terminator Instructions</a>
+</h3>
+
+<div>
+
+<p>As mentioned <a href="#functionstructure">previously</a>, every basic block
+ in a program ends with a "Terminator" instruction, which indicates which
+ block should be executed after the current block is finished. These
+ terminator instructions typically yield a '<tt>void</tt>' value: they produce
+ control flow, not values (the one exception being the
+ '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p>
+
+<p>The terminator instructions are:
+ '<a href="#i_ret"><tt>ret</tt></a>',
+ '<a href="#i_br"><tt>br</tt></a>',
+ '<a href="#i_switch"><tt>switch</tt></a>',
+ '<a href="#i_indirectbr"><tt>indirectbr</tt></a>',
+ '<a href="#i_invoke"><tt>invoke</tt></a>',
+ '<a href="#i_resume"><tt>resume</tt></a>', and
+ '<a href="#i_unreachable"><tt>unreachable</tt></a>'.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="i_ret">'<tt>ret</tt>' Instruction</a>
+</h4>
+
+<div>
+
+<h5>Syntax:</h5>
+<pre>
+ ret <type> <value> <i>; Return a value from a non-void function</i>
+ ret void <i>; Return from void function</i>
+</pre>
+
+<h5>Overview:</h5>
+<p>The '<tt>ret</tt>' instruction is used to return control flow (and optionally
+ a value) from a function back to the caller.</p>
+
+<p>There are two forms of the '<tt>ret</tt>' instruction: one that returns a
+ value and then causes control flow, and one that just causes control flow to
+ occur.</p>
+
+<h5>Arguments:</h5>
+<p>The '<tt>ret</tt>' instruction optionally accepts a single argument, the
+ return value. The type of the return value must be a
+ '<a href="#t_firstclass">first class</a>' type.</p>