diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/BitCodeFormat.html | 501 | ||||
| -rw-r--r-- | docs/CommandGuide/lit.pod | 5 | ||||
| -rw-r--r-- | docs/CompilerDriver.html | 105 | ||||
| -rw-r--r-- | docs/GettingStarted.html | 4 | ||||
| -rw-r--r-- | docs/LangRef.html | 342 | ||||
| -rw-r--r-- | docs/Passes.html | 18 | ||||
| -rw-r--r-- | docs/ReleaseNotes.html | 4 | ||||
| -rw-r--r-- | docs/TableGenFundamentals.html | 4 | ||||
| -rw-r--r-- | docs/tutorial/LangImpl4.html | 35 | ||||
| -rw-r--r-- | docs/tutorial/OCamlLangImpl4.html | 31 |
10 files changed, 740 insertions, 309 deletions
diff --git a/docs/BitCodeFormat.html b/docs/BitCodeFormat.html index e75887b..7a46d90 100644 --- a/docs/BitCodeFormat.html +++ b/docs/BitCodeFormat.html @@ -27,6 +27,15 @@ <li><a href="#llvmir">LLVM IR Encoding</a> <ol> <li><a href="#basics">Basics</a></li> + <li><a href="#MODULE_BLOCK">MODULE_BLOCK Contents</a></li> + <li><a href="#PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a></li> + <li><a href="#TYPE_BLOCK">TYPE_BLOCK Contents</a></li> + <li><a href="#CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a></li> + <li><a href="#FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a></li> + <li><a href="#TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a></li> + <li><a href="#VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a></li> + <li><a href="#METADATA_BLOCK">METADATA_BLOCK Contents</a></li> + <li><a href="#METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a></li> </ol> </li> </ol> @@ -220,7 +229,7 @@ A bitstream is a sequential series of <a href="#blocks">Blocks</a> and abbreviation ID encoded as a fixed-bitwidth field. The width is specified by the current block, as described below. The value of the abbreviation ID specifies either a builtin ID (which have special meanings, defined below) or -one of the abbreviation IDs defined by the stream itself. +one of the abbreviation IDs defined for the current block by the stream itself. </p> <p> @@ -258,7 +267,7 @@ application specific. Nested blocks capture the hierarchical structure of the da encoded in it, and various properties are associated with blocks as the file is parsed. Block definitions allow the reader to efficiently skip blocks in constant time if the reader wants a summary of blocks, or if it wants to -efficiently skip data they do not understand. The LLVM IR reader uses this +efficiently skip data it does not understand. The LLVM IR reader uses this mechanism to skip function bodies, lazily reading them on demand. </p> @@ -268,7 +277,8 @@ block. In particular, each block maintains: </p> <ol> -<li>A current abbrev id width. This value starts at 2, and is set every time a +<li>A current abbrev id width. This value starts at 2 at the beginning of + the stream, and is set every time a block record is entered. The block entry specifies the abbrev id width for the body of the block.</li> @@ -335,13 +345,14 @@ an even multiple of 32-bits. <div class="doc_text"> <p> -Data records consist of a record code and a number of (up to) 64-bit integer -values. The interpretation of the code and values is application specific and -there are multiple different ways to encode a record (with an unabbrev record or -with an abbreviation). In the LLVM IR format, for example, there is a record +Data records consist of a record code and a number of (up to) 64-bit +integer values. The interpretation of the code and values is +application specific and may vary between different block types. +Records can be encoded either using an unabbrev record, or with an +abbreviation. In the LLVM IR format, for example, there is a record which encodes the target triple of a module. The code is -<tt>MODULE_CODE_TRIPLE</tt>, and the values of the record are the ASCII codes -for the characters in the string. +<tt>MODULE_CODE_TRIPLE</tt>, and the values of the record are the +ASCII codes for the characters in the string. </p> </div> @@ -358,7 +369,7 @@ Encoding</a></div> <p> An <tt>UNABBREV_RECORD</tt> provides a default fallback encoding, which is both completely general and extremely inefficient. It can describe an arbitrary -record by emitting the code and operands as vbrs. +record by emitting the code and operands as VBRs. </p> <p> @@ -391,6 +402,11 @@ allows the files to be completely self describing. The actual encoding of abbreviations is defined below. </p> +<p>The record code, which is the first field of an abbreviated record, +may be encoded in the abbreviation definition (as a literal +operand) or supplied in the abbreviated record (as a Fixed or VBR +operand value).</p> + </div> <!-- ======================================================================= --> @@ -409,8 +425,9 @@ emitted. <p> Abbreviations can be determined dynamically per client, per file. Because the abbreviations are stored in the bitstream itself, different streams of the same -format can contain different sets of abbreviations if the specific stream does -not need it. As a concrete example, LLVM IR files usually emit an abbreviation +format can contain different sets of abbreviations according to the needs +of the specific stream. +As a concrete example, LLVM IR files usually emit an abbreviation for binary operators. If a specific LLVM module contained no or few binary operators, the abbreviation does not need to be emitted. </p> @@ -431,7 +448,8 @@ defined abbreviations in the scope of this block. This definition only exists inside this immediate block — it is not visible in subblocks or enclosing blocks. Abbreviations are implicitly assigned IDs sequentially starting from 4 (the first application-defined abbreviation ID). Any abbreviations defined in a -<tt>BLOCKINFO</tt> record receive IDs first, in order, followed by any +<tt>BLOCKINFO</tt> record for the particular block type +receive IDs first, in order, followed by any abbreviations defined within the block itself. Abbreviated data records reference this ID to indicate what abbreviation they are invoking. </p> @@ -461,31 +479,32 @@ emitted as their code, followed by the extra data. <p>The possible operand encodings are:</p> -<ol> -<li>Fixed: The field should be emitted as +<ul> +<li>Fixed (code 1): The field should be emitted as a <a href="#fixedwidth">fixed-width value</a>, whose width is specified by the operand's extra data.</li> -<li>VBR: The field should be emitted as +<li>VBR (code 2): The field should be emitted as a <a href="#variablewidth">variable-width value</a>, whose width is specified by the operand's extra data.</li> -<li>Array: This field is an array of values. The array operand - has no extra data, but expects another operand to follow it which indicates +<li>Array (code 3): This field is an array of values. The array operand + has no extra data, but expects another operand to follow it, indicating the element type of the array. When reading an array in an abbreviated record, the first integer is a vbr6 that indicates the array length, followed by the encoded elements of the array. An array may only occur as the last operand of an abbreviation (except for the one final operand that gives the array's type).</li> -<li>Char6: This field should be emitted as +<li>Char6 (code 4): This field should be emitted as a <a href="#char6">char6-encoded value</a>. This operand type takes no - extra data.</li> -<li>Blob: This field is emitted as a vbr6, followed by padding to a + extra data. Char6 encoding is normally used as an array element type. + </li> +<li>Blob (code 5): This field is emitted as a vbr6, followed by padding to a 32-bit boundary (for alignment) and an array of 8-bit objects. The array of bytes is further followed by tail padding to ensure that its total length is a multiple of 4 bytes. This makes it very efficient for the reader to decode the data without having to make a copy of it: it can use a pointer to the data in the mapped in file and poke directly at it. A blob may only occur as the last operand of an abbreviation.</li> -</ol> +</ul> <p> For example, target triples in LLVM modules are encoded as a record of the @@ -517,7 +536,7 @@ as: <ol> <li>The first value, 4, is the abbreviation ID for this abbreviation.</li> -<li>The second value, 2, is the code for <tt>TRIPLE</tt> in LLVM IR files.</li> +<li>The second value, 2, is the record code for <tt>TRIPLE</tt> records within LLVM IR file <tt>MODULE_BLOCK</tt> blocks.</li> <li>The third value, 4, is the length of the array.</li> <li>The rest of the values are the char6 encoded values for <tt>"abcd"</tt>.</li> @@ -541,7 +560,7 @@ used for any other string value. <p> In addition to the basic block structure and record encodings, the bitstream -also defines specific builtin block types. These block types specify how the +also defines specific built-in block types. These block types specify how the stream is to be decoded or other metadata. In the future, new standard blocks may be added. Block IDs 0-7 are reserved for standard blocks. </p> @@ -569,7 +588,7 @@ blocks. The currently specified records are: </div> <p> -The <tt>SETBID</tt> record indicates which block ID is being +The <tt>SETBID</tt> record (code 1) indicates which block ID is being described. <tt>SETBID</tt> records can occur multiple times throughout the block to change which block ID is being described. There must be a <tt>SETBID</tt> record prior to any other records. @@ -584,13 +603,13 @@ in <tt>BLOCKINFO</tt> blocks receive abbreviation IDs as described in <tt><a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt>. </p> -<p>The <tt>BLOCKNAME</tt> can optionally occur in this block. The elements of -the record are the bytes for the string name of the block. llvm-bcanalyzer uses +<p>The <tt>BLOCKNAME</tt> record (code 2) can optionally occur in this block. The elements of +the record are the bytes of the string name of the block. llvm-bcanalyzer can use this to dump out bitcode files symbolically.</p> -<p>The <tt>SETRECORDNAME</tt> record can optionally occur in this block. The -first entry is a record ID number and the rest of the elements of the record are -the bytes for the string name of the record. llvm-bcanalyzer uses +<p>The <tt>SETRECORDNAME</tt> record (code 3) can also optionally occur in this block. The +first operand value is a record ID number, and the rest of the elements of the record are +the bytes for the string name of the record. llvm-bcanalyzer can use this to dump out bitcode files symbolically.</p> <p> @@ -626,7 +645,7 @@ Each of the fields are 32-bit fields stored in little endian form (as with the rest of the bitcode file fields). The Magic number is always <tt>0x0B17C0DE</tt> and the version is currently always <tt>0</tt>. The Offset field is the offset in bytes to the start of the bitcode stream in the file, and -the Size field is a size in bytes of the stream. CPUType is a target-specific +the Size field is the size in bytes of the stream. CPUType is a target-specific value that can be used to encode the CPU of the target. </p> @@ -681,26 +700,28 @@ When combined with the bitcode magic number and viewed as bytes, this is <div class="doc_text"> <p> -<a href="#variablewidth">Variable Width Integers</a> are an efficient way to -encode arbitrary sized unsigned values, but is an extremely inefficient way to -encode signed values (as signed values are otherwise treated as maximally large -unsigned values). +<a href="#variablewidth">Variable Width Integer</a> encoding is an efficient way to +encode arbitrary sized unsigned values, but is an extremely inefficient for +encoding signed values, as signed values are otherwise treated as maximally large +unsigned values. </p> <p> -As such, signed vbr values of a specific width are emitted as follows: +As such, signed VBR values of a specific width are emitted as follows: </p> <ul> -<li>Positive values are emitted as vbrs of the specified width, but with their +<li>Positive values are emitted as VBRs of the specified width, but with their value shifted left by one.</li> -<li>Negative values are emitted as vbrs of the specified width, but the negated +<li>Negative values are emitted as VBRs of the specified width, but the negated value is shifted left by one, and the low bit is set.</li> </ul> <p> -With this encoding, small positive and small negative values can both be emitted -efficiently. +With this encoding, small positive and small negative values can both +be emitted efficiently. Signed VBR encoding is used in +<tt>CST_CODE_INTEGER</tt> and <tt>CST_CODE_WIDE_INTEGER</tt> records +within <tt>CONSTANTS_BLOCK</tt> blocks. </p> </div> @@ -716,21 +737,23 @@ LLVM IR is defined with the following blocks: </p> <ul> -<li>8 — <tt>MODULE_BLOCK</tt> — This is the top-level block that +<li>8 — <a href="#MODULE_BLOCK"><tt>MODULE_BLOCK</tt></a> — This is the top-level block that contains the entire module, and describes a variety of per-module information.</li> -<li>9 — <tt>PARAMATTR_BLOCK</tt> — This enumerates the parameter +<li>9 — <a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a> — This enumerates the parameter attributes.</li> -<li>10 — <tt>TYPE_BLOCK</tt> — This describes all of the types in +<li>10 — <a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a> — This describes all of the types in the module.</li> -<li>11 — <tt>CONSTANTS_BLOCK</tt> — This describes constants for a +<li>11 — <a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a> — This describes constants for a module or function.</li> -<li>12 — <tt>FUNCTION_BLOCK</tt> — This describes a function +<li>12 — <a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a> — This describes a function body.</li> -<li>13 — <tt>TYPE_SYMTAB_BLOCK</tt> — This describes the type symbol +<li>13 — <a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a> — This describes the type symbol table.</li> -<li>14 — <tt>VALUE_SYMTAB_BLOCK</tt> — This describes a value symbol +<li>14 — <a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a> — This describes a value symbol table.</li> +<li>15 — <a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a> — This describes metadata items.</li> +<li>16 — <a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a> — This contains records associating metadata with function instruction values.</li> </ul> </div> @@ -741,7 +764,387 @@ LLVM IR is defined with the following blocks: <div class="doc_text"> -<p> +<p>The <tt>MODULE_BLOCK</tt> block (id 8) is the top-level block for LLVM +bitcode files, and each bitcode file must contain exactly one. In +addition to records (described below) containing information +about the module, a <tt>MODULE_BLOCK</tt> block may contain the +following sub-blocks: +</p> + +<ul> +<li><a href="#BLOCKINFO"><tt>BLOCKINFO</tt></a></li> +<li><a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a></li> +<li><a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a></li> +<li><a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a></li> +<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li> +<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li> +<li><a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a></li> +<li><a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a></li> +</ul> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_VERSION">MODULE_CODE_VERSION Record</a> +</div> + +<div class="doc_text"> + +<p><tt>[VERSION, version#]</tt></p> + +<p>The <tt>VERSION</tt> record (code 1) contains a single value +indicating the format version. Only version 0 is supported at this +time.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_TRIPLE">MODULE_CODE_TRIPLE Record</a> +</div> + +<div class="doc_text"> +<p><tt>[TRIPLE, ...string...]</tt></p> + +<p>The <tt>TRIPLE</tt> record (code 2) contains a variable number of +values representing the bytes of the <tt>target triple</tt> +specification string.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_DATALAYOUT">MODULE_CODE_DATALAYOUT Record</a> +</div> + +<div class="doc_text"> +<p><tt>[DATALAYOUT, ...string...]</tt></p> + +<p>The <tt>DATALAYOUT</tt> record (code 3) contains a variable number of +values representing the bytes of the <tt>target datalayout</tt> +specification string.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_ASM">MODULE_CODE_ASM Record</a> +</div> + +<div class="doc_text"> +<p><tt>[ASM, ...string...]</tt></p> + +<p>The <tt>ASM</tt> record (code 4) contains a variable number of +values representing the bytes of <tt>module asm</tt> strings, with +individual assembly blocks separated by newline (ASCII 10) characters.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME Record</a> +</div> + +<div class="doc_text"> +<p><tt>[SECTIONNAME, ...string...]</tt></p> + +<p>The <tt>SECTIONNAME</tt> record (code 5) contains a variable number +of values representing the bytes of a single section name +string. There should be one <tt>SECTIONNAME</tt> record for each +section name referenced (e.g., in global variable or function +<tt>section</tt> attributes) within the module. These records can be +referenced by the 1-based index in the <i>section</i> fields of +<tt>GLOBALVAR</tt> or <tt>FUNCTION</tt> records.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_DEPLIB">MODULE_CODE_DEPLIB Record</a> +</div> + +<div class="doc_text"> +<p><tt>[DEPLIB, ...string...]</tt></p> + +<p>The <tt>DEPLIB</tt> record (code 6) contains a variable number of +values representing the bytes of a single dependent library name +string, one of the libraries mentioned in a <tt>deplibs</tt> +declaration. There should be one <tt>DEPLIB</tt> record for each +library name referenced.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_GLOBALVAR">MODULE_CODE_GLOBALVAR Record</a> +</div> + +<div class="doc_text"> +<p><tt>[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal]</tt></p> + +<p>The <tt>GLOBALVAR</tt> record (code 7) marks the declaration or +definition of a global variable. The operand fields are:</p> + +<ul> +<li><i>pointer type</i>: The type index of the pointer type used to point to +this global variable</li> + +<li><i>isconst</i>: Non-zero if the variable is treated as constant within +the module, or zero if it is not</li> + +<li><i>initid</i>: If non-zero, the value index of the initializer for this +variable, plus 1.</li> + +<li><a name="linkage"><i>linkage</i></a>: An encoding of the linkage +type for this variable: + <ul> + <li><tt>external</tt>: code 0</li> + <li><tt>weak</tt>: code 1</li> + <li><tt>appending</tt>: code 2</li> + <li><tt>internal</tt>: code 3</li> + <li><tt>linkonce</tt>: code 4</li> + <li><tt>dllimport</tt>: code 5</li> + <li><tt>dllexport</tt>: code 6</li> + <li><tt>extern_weak</tt>: code 7</li> + <li><tt>common</tt>: code 8</li> + <li><tt>private</tt>: code 9</li> + <li><tt>weak_odr</tt>: code 10</li> + <li><tt>linkonce_odr</tt>: code 11</li> + <li><tt>available_externally</tt>: code 12</li> + <li><tt>linker_private</tt>: code 13</li> + </ul> +</li> + +<li><i>alignment</i>: The logarithm base 2 of the variable's requested +alignment, plus 1</li> + +<li><i>section</i>: If non-zero, the 1-based section index in the +table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a> +entries.</li> + +<li><a name="visibility"><i>visibility</i></a>: If present, an +encoding of the visibility of this variable: + <ul> + <li><tt>default</tt>: code 0</li> + <li><tt>hidden</tt>: code 1</li> + <li><tt>protected</tt>: code 2</li> + </ul> +</li> + +<li><i>threadlocal</i>: If present and non-zero, indicates that the variable +is <tt>thread_local</tt></li> + +</ul> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_FUNCTION">MODULE_CODE_FUNCTION Record</a> +</div> + +<div class="doc_text"> + +<p><tt>[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]</tt></p> + +<p>The <tt>FUNCTION</tt> record (code 8) marks the declaration or +definition of a function. The operand fields are:</p> + +<ul> +<li><i>type</i>: The type index of the function type describing this function</li> + +<li><i>callingconv</i>: The calling convention number: + <ul> + <li><tt>ccc</tt>: code 0</li> + <li><tt>fastcc</tt>: code 8</li> + <li><tt>coldcc</tt>: code 9</li> + <li><tt>x86_stdcallcc</tt>: code 64</li> + <li><tt>x86_fastcallcc</tt>: code 65</li> + <li><tt>arm_apcscc</tt>: code 66</li> + <li><tt>arm_aapcscc</tt>: code 67</li> + <li><tt>arm_aapcs_vfpcc</tt>: code 68</li> + </ul> +</li> + +<li><i>isproto</i>: Non-zero if this entry represents a declaration +rather than a definition</li> + +<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a> +for this function</li> + +<li><i>paramattr</i>: If nonzero, the 1-based parameter attribute index +into the table of <a href="#PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY</a> +entries.</li> + +<li><i>alignment</i>: The logarithm base 2 of the function's requested +alignment, plus 1</li> + +<li><i>section</i>: If non-zero, the 1-based section index in the +table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a> +entries.</li> + +<li><i>visibility</i>: An encoding of the <a href="#visibility">visibility</a> + of this function</li> + +<li><i>gc</i>: If present and nonzero, the 1-based garbage collector +index in the table of +<a href="#MODULE_CODE_GCNAME">MODULE_CODE_GCNAME</a> entries.</li> +</ul> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_ALIAS">MODULE_CODE_ALIAS Record</a> +</div> + +<div class="doc_text"> + +<p><tt>[ALIAS, alias type, aliasee val#, linkage, visibility]</tt></p> + +<p>The <tt>ALIAS</tt> record (code 9) marks the definition of an +alias. The operand fields are</p> + +<ul> +<li><i>alias type</i>: The type index of the alias</li> + +<li><i>aliasee val#</i>: The value index of the aliased value</li> + +<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a> +for this alias</li> + +<li><i>visibility</i>: If present, an encoding of the +<a href="#visibility">visibility</a> of the alias</li> + +</ul> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_PURGEVALS">MODULE_CODE_PURGEVALS Record</a> +</div> + +<div class="doc_text"> +<p><tt>[PURGEVALS, numvals]</tt></p> + +<p>The <tt>PURGEVALS</tt> record (code 10) resets the module-level +value list to the size given by the single operand value. Module-level +value list items are added by <tt>GLOBALVAR</tt>, <tt>FUNCTION</tt>, +and <tt>ALIAS</tt> records. After a <tt>PURGEVALS</tt> record is seen, +new value indices will start from the given <i>numvals</i> value.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="MODULE_CODE_GCNAME">MODULE_CODE_GCNAME Record</a> +</div> + +<div class="doc_text"> +<p><tt>[GCNAME, ...string...]</tt></p> + +<p>The <tt>GCNAME</tt> record (code 11) contains a variable number of +values representing the bytes of a single garbage collector name +string. There should be one <tt>GCNAME</tt> record for each garbage +collector name referenced in function <tt>gc</tt> attributes within +the module. These records can be referenced by 1-based index in the <i>gc</i> +fields of <tt>FUNCTION</tt> records.</p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>PARAMATTR_BLOCK</tt> block (id 9) ... +</p> + +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY Record</a> +</div> + +<div class="doc_text"> + +<p><tt>[ENTRY, paramidx0, attr0, paramidx1, attr1...]</tt></p> + +<p>The <tt>ENTRY</tt> record (code 1) ... +</p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="TYPE_BLOCK">TYPE_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>TYPE_BLOCK</tt> block (id 10) ... +</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>CONSTANTS_BLOCK</tt> block (id 11) ... +</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>FUNCTION_BLOCK</tt> block (id 12) ... +</p> + +<p>In addition to the record types described below, a +<tt>FUNCTION_BLOCK</tt> block may contain the following sub-blocks: +</p> + +<ul> +<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li> +<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li> +<li><a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a></li> +</ul> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>TYPE_SYMTAB_BLOCK</tt> block (id 13) ... +</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>VALUE_SYMTAB_BLOCK</tt> block (id 14) ... +</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="METADATA_BLOCK">METADATA_BLOCK Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>METADATA_BLOCK</tt> block (id 15) ... +</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a> +</div> + +<div class="doc_text"> + +<p>The <tt>METADATA_ATTACHMENT</tt> block (id 16) ... </p> </div> @@ -755,7 +1158,7 @@ LLVM IR is defined with the following blocks: src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> <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-12 16:46:08 +0200 (Mon, 12 Oct 2009) $ +Last modified: $Date: 2009-10-29 05:25:46 +0100 (Thu, 29 Oct 2009) $ </address> </body> </html> diff --git a/docs/CommandGuide/lit.pod b/docs/CommandGuide/lit.pod index a818302..929aed7 100644 --- a/docs/CommandGuide/lit.pod +++ b/docs/CommandGuide/lit.pod @@ -49,6 +49,11 @@ Show the B<lit> help message. Run I<N> tests in parallel. By default, this is automatically chose to match the number of detected available CPUs. +=item B<--config-prefix>=I<NAME> + +Search for I<NAME.cfg> and I<NAME.site.cfg> when searching for test suites, +instead I<lit.cfg> and I<lit.site.cfg>. + =back =head1 OUTPUT OPTIONS diff --git a/docs/CompilerDriver.html b/docs/CompilerDriver.html index 7a40a4d..ded3cf4 100644 --- a/docs/CompilerDriver.html +++ b/docs/CompilerDriver.html @@ -33,11 +33,12 @@ The ReST source lives in the directory 'tools/llvmc/doc'. --> </ul> </li> <li><a class="reference internal" href="#language-map" id="id15">Language map</a></li> -<li><a class="reference internal" href="#more-advanced-topics" id="id16">More advanced topics</a><ul> -<li><a class="reference internal" href="#hooks-and-environment-variables" id="id17">Hooks and environment variables</a></li> -<li><a class="reference internal" href="#how-plugins-are-loaded" id="id18">How plugins are loaded</a></li> -<li><a class="reference internal" href="#debugging" id="id19">Debugging</a></li> -<li><a class="reference internal" href="#conditioning-on-the-executable-name" id="id20">Conditioning on the executable name</a></li> +<li><a class="reference internal" href="#option-preprocessor" id="id16">Option preprocessor</a></li> +<li><a class="reference internal" href="#more-advanced-topics" id="id17">More advanced topics</a><ul> +<li><a class="reference internal" href="#hooks-and-environment-variables" id="id18">Hooks and environment variables</a></li> +<li><a class="reference internal" href="#how-plugins-are-loaded" id="id19">How plugins are loaded</a></li> +<li><a class="reference internal" href="#debugging" id="id20">Debugging</a></li> +<li><a class="reference internal" href="#conditioning-on-the-executable-name" id="id21">Conditioning on the executable name</a></li> </ul> </li> </ul> @@ -307,13 +308,13 @@ separate option groups syntactically.</p> <tt class="docutils literal"><span class="pre">-std=c99</span></tt>. It is also allowed to use spaces instead of the equality sign: <tt class="docutils literal"><span class="pre">-std</span> <span class="pre">c99</span></tt>. At most one occurrence is allowed.</li> <li><tt class="docutils literal"><span class="pre">parameter_list_option</span></tt> - same as the above, but more than one option -occurrence is allowed.</li> +occurence is allowed.</li> <li><tt class="docutils literal"><span class="pre">prefix_option</span></tt> - same as the parameter_option, but the option name and argument do not have to be separated. Example: <tt class="docutils literal"><span class="pre">-ofile</span></tt>. This can be also specified as <tt class="docutils literal"><span class="pre">-o</span> <span class="pre">file</span></tt>; however, <tt class="docutils literal"><span class="pre">-o=file</span></tt> will be parsed incorrectly (<tt class="docutils literal"><span class="pre">=file</span></tt> will be interpreted as option value). At most one occurrence is allowed.</li> -<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurrence of +<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurence of the option is allowed; example: <tt class="docutils literal"><span class="pre">-lm</span> <span class="pre">-lpthread</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">alias_option</span></tt> - a special option type for creating aliases. Unlike other option types, aliases are not allowed to have any properties besides the @@ -343,8 +344,9 @@ output).</li> output.</li> <li><tt class="docutils literal"><span class="pre">multi_val</span> <span class="pre">n</span></tt> - this option takes <em>n</em> arguments (can be useful in some special cases). Usage example: <tt class="docutils literal"><span class="pre">(parameter_list_option</span> <span class="pre">"foo",</span> <span class="pre">(multi_val</span> -<span class="pre">3))</span></tt>. Only list options can have this attribute; you can, however, use -the <tt class="docutils literal"><span class="pre">one_or_more</span></tt> and <tt class="docutils literal"><span class="pre">zero_or_one</span></tt> properties.</li> +<span class="pre">3))</span></tt>; the command-line syntax is '-foo a b c'. Only list options can have +this attribute; you can, however, use the <tt class="docutils literal"><span class="pre">one_or_more</span></tt>, <tt class="docutils literal"><span class="pre">zero_or_one</span></tt> +and <tt class="docutils literal"><span class="pre">required</span></tt> properties.</li> <li><tt class="docutils literal"><span class="pre">init</span></tt> - this option has a default value, either a string (if it is a parameter), or a boolean (if it is a switch; boolean constants are called <tt class="docutils literal"><span class="pre">true</span></tt> and <tt class="docutils literal"><span class="pre">false</span></tt>). List options can't have this attribute. Usage @@ -417,8 +419,15 @@ readability. It is usually better to split tool descriptions and/or use TableGen inheritance instead.</p> <ul class="simple"> <li>Possible tests are:<ul> -<li><tt class="docutils literal"><span class="pre">switch_on</span></tt> - Returns true if a given command-line switch is -provided by the user. Example: <tt class="docutils literal"><span class="pre">(switch_on</span> <span class="pre">"opt")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">switch_on</span></tt> - Returns true if a given command-line switch is provided by +the user. Can be given a list as argument, in that case <tt class="docutils literal"><span class="pre">(switch_on</span> <span class="pre">["foo",</span> +<span class="pre">"bar",</span> <span class="pre">"baz"])</span></tt> is equivalent to <tt class="docutils literal"><span class="pre">(and</span> <span class="pre">(switch_on</span> <span class="pre">"foo"),</span> <span class="pre">(switch_on</span> +<span class="pre">"bar"),</span> <span class="pre">(switch_on</span> <span class="pre">"baz"))</span></tt>. +Example: <tt class="docutils literal"><span class="pre">(switch_on</span> <span class="pre">"opt")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">any_switch_on</span></tt> - Given a list of switch options, returns true if any of +the switches is turned on. +Example: <tt class="docutils literal"><span class="pre">(any_switch_on</span> <span class="pre">["foo",</span> <span class="pre">"bar",</span> <span class="pre">"baz"])</span></tt> is equivalent to <tt class="docutils literal"><span class="pre">(or</span> +<span class="pre">(switch_on</span> <span class="pre">"foo"),</span> <span class="pre">(switch_on</span> <span class="pre">"bar"),</span> <span class="pre">(switch_on</span> <span class="pre">"baz"))</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">parameter_equals</span></tt> - Returns true if a command-line parameter equals a given value. Example: <tt class="docutils literal"><span class="pre">(parameter_equals</span> <span class="pre">"W",</span> <span class="pre">"all")</span></tt>.</li> @@ -428,16 +437,24 @@ Example: <tt class="docutils literal"><span class="pre">(parameter_in_list</span <li><tt class="docutils literal"><span class="pre">input_languages_contain</span></tt> - Returns true if a given language belongs to the current input language set. Example: <tt class="docutils literal"><span class="pre">(input_languages_contain</span> <span class="pre">"c++")</span></tt>.</li> -<li><tt class="docutils literal"><span class="pre">in_language</span></tt> - Evaluates to true if the input file language -equals to the argument. At the moment works only with <tt class="docutils literal"><span class="pre">cmd_line</span></tt> -and <tt class="docutils literal"><span class="pre">actions</span></tt> (on non-join nodes). +<li><tt class="docutils literal"><span class="pre">in_language</span></tt> - Evaluates to true if the input file language is equal to +the argument. At the moment works only with <tt class="docutils literal"><span class="pre">cmd_line</span></tt> and <tt class="docutils literal"><span class="pre">actions</span></tt> (on +non-join nodes). Example: <tt class="docutils literal"><span class="pre">(in_language</span> <span class="pre">"c++")</span></tt>.</li> -<li><tt class="docutils literal"><span class="pre">not_empty</span></tt> - Returns true if a given option (which should be -either a parameter or a parameter list) is set by the -user. +<li><tt class="docutils literal"><span class="pre">not_empty</span></tt> - Returns true if a given option (which should be either a +parameter or a parameter list) is set by the user. Like <tt class="docutils literal"><span class="pre">switch_on</span></tt>, can +be also given a list as argument. Example: <tt class="docutils literal"><span class="pre">(not_empty</span> <span class="pre">"o")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">any_not_empty</span></tt> - Returns true if <tt class="docutils literal"><span class="pre">not_empty</span></tt> returns true for any of +the options in the list. +Example: <tt class="docutils literal"><span class="pre">(any_not_empty</span> <span class="pre">["foo",</span> <span class="pre">"bar",</span> <span class="pre">"baz"])</span></tt> is equivalent to <tt class="docutils literal"><span class="pre">(or</span> +<span class="pre">(not_empty</span> <span class="pre">"foo"),</span> <span class="pre">(not_empty</span> <span class="pre">"bar"),</span> <span class="pre">(not_empty</span> <span class="pre">"baz"))</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">empty</span></tt> - The opposite of <tt class="docutils literal"><span class="pre">not_empty</span></tt>. Equivalent to <tt class="docutils literal"><span class="pre">(not</span> <span class="pre">(not_empty</span> -<span class="pre">X))</span></tt>. Provided for convenience.</li> +<span class="pre">X))</span></tt>. Provided for convenience. Can be given a list as argument.</li> +<li><tt class="docutils literal"><span class="pre">any_not_empty</span></tt> - Returns true if <tt class="docutils literal"><span class="pre">not_empty</span></tt> returns true for any of +the options in the list. +Example: <tt class="docutils literal"><span class="pre">(any_empty</span> <span class="pre">["foo",</span> <span class="pre">"bar",</span> <span class="pre">"baz"])</span></tt> is equivalent to <tt class="docutils literal"><span class="pre">(not</span> <span class="pre">(and</span> +<span class="pre">(not_empty</span> <span class="pre">"foo"),</span> <span class="pre">(not_empty</span> <span class="pre">"bar"),</span> <span class="pre">(not_empty</span> <span class="pre">"baz")))</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">single_input_file</span></tt> - Returns true if there was only one input file provided on the command-line. Used without arguments: <tt class="docutils literal"><span class="pre">(single_input_file)</span></tt>.</li> @@ -481,8 +498,8 @@ options that aren't mentioned in the option list.</p> <li>Possible tool properties:<ul> <li><tt class="docutils literal"><span class="pre">in_language</span></tt> - input language name. Can be either a string or a list, in case the tool supports multiple input languages.</li> -<li><tt class="docutils literal"><span class="pre">out_language</span></tt> - output language name. Tools are not allowed to -have multiple output languages.</li> +<li><tt class="docutils literal"><span class="pre">out_language</span></tt> - output language name. Multiple output languages are not +allowed.</li> <li><tt class="docutils literal"><span class="pre">output_suffix</span></tt> - output file suffix. Can also be changed dynamically, see documentation on actions.</li> <li><tt class="docutils literal"><span class="pre">cmd_line</span></tt> - the actual command used to run the tool. You can @@ -537,10 +554,11 @@ like a linker.</p> command. Example: <tt class="docutils literal"><span class="pre">(case</span> <span class="pre">(switch_on</span> <span class="pre">"pthread"),</span> <span class="pre">(append_cmd</span> <span class="pre">"-lpthread"))</span></tt></li> -<li><tt class="docutils literal"><span class="pre">error`</span> <span class="pre">-</span> <span class="pre">exit</span> <span class="pre">with</span> <span class="pre">error.</span> -<span class="pre">Example:</span> <span class="pre">``(error</span> <span class="pre">"Mixing</span> <span class="pre">-c</span> <span class="pre">and</span> <span class="pre">-S</span> <span class="pre">is</span> <span class="pre">not</span> <span class="pre">allowed!")</span></tt>.</li> -<li><tt class="docutils literal"><span class="pre">forward</span></tt> - forward an option unchanged. -Example: <tt class="docutils literal"><span class="pre">(forward</span> <span class="pre">"Wall")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">error</span></tt> - exit with error. +Example: <tt class="docutils literal"><span class="pre">(error</span> <span class="pre">"Mixing</span> <span class="pre">-c</span> <span class="pre">and</span> <span class="pre">-S</span> <span class="pre">is</span> <span class="pre">not</span> <span class="pre">allowed!")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">warning</span></tt> - print a warning. +Example: <tt class="docutils literal"><span class="pre">(warning</span> <span class="pre">"Specifying</span> <span class="pre">both</span> <span class="pre">-O1</span> <span class="pre">and</span> <span class="pre">-O2</span> <span class="pre">is</span> <span class="pre">meaningless!")</span></tt>.</li> +<li><tt class="docutils literal"><span class="pre">forward</span></tt> - forward an option unchanged. Example: <tt class="docutils literal"><span class="pre">(forward</span> <span class="pre">"Wall")</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">forward_as</span></tt> - Change the name of an option, but forward the argument unchanged. Example: <tt class="docutils literal"><span class="pre">(forward_as</span> <span class="pre">"O0",</span> <span class="pre">"--disable-optimization")</span></tt>.</li> @@ -583,10 +601,37 @@ linked with the root node. Since tools are not allowed to have multiple output languages, for nodes "inside" the graph the input and output languages should match. This is enforced at compile-time.</p> </div> +<div class="section" id="option-preprocessor"> +<h1><a class="toc-backref" href="#id16">Option preprocessor</a></h1> +<p>It is sometimes useful to run error-checking code before processing the +compilation graph. For example, if optimization options "-O1" and "-O2" are +implemented as switches, we might want to output a warning if the user invokes +the driver with both of these options enabled.</p> +<p>The <tt class="docutils literal"><span class="pre">OptionPreprocessor</span></tt> feature is reserved specially for these +occasions. Example (adapted from the built-in Base plugin):</p> +<pre class="literal-block"> +def Preprocess : OptionPreprocessor< +(case (and (switch_on "O3"), (any_switch_on ["O0", "O1", "O2"])), + [(unset_option ["O0", "O1", "O2"]), + (warning "Multiple -O options specified, defaulted to -O3.")], + (and (switch_on "O2"), (any_switch_on ["O0", "O1"])), + (unset_option ["O0", "O1"]), + (and (switch_on "O1"), (switch_on "O0")), + (unset_option "O0")) +>; +</pre> +<p>Here, <tt class="docutils literal"><span class="pre">OptionPreprocessor</span></tt> is used to unset all spurious optimization options +(so that they are not forwarded to the compiler).</p> +<p><tt class="docutils literal"><span class="pre">OptionPreprocessor</span></tt> is basically a single big <tt class="docutils literal"><span class="pre">case</span></tt> expression, which is +evaluated only once right after the plugin is loaded. The only allowed actions +in <tt class="docutils literal"><span class="pre">OptionPreprocessor</span></tt> are <tt class="docutils literal"><span class="pre">error</span></tt>, <tt class="docutils literal"><span class="pre">warning</span></tt> and a special action +<tt class="docutils literal"><span class="pre">unset_option</span></tt>, which, as the name suggests, unsets a given option. For +convenience, <tt class="docutils literal"><span class="pre">unset_option</span></tt> also works on lists.</p> +</div> <div class="section" id="more-advanced-topics"> -<h1><a class="toc-backref" href="#id16">More advanced topics</a></h1> +<h1><a class="toc-backref" href="#id17">More advanced topics</a></h1> <div class="section" id="hooks-and-environment-variables"> -<span id="hooks"></span><h2><a class="toc-backref" href="#id17">Hooks and environment variables</a></h2> +<span id="hooks"></span><h2><a class="toc-backref" href="#id18">Hooks and environment variables</a></h2> <p>Normally, LLVMC executes programs from the system <tt class="docutils literal"><span class="pre">PATH</span></tt>. Sometimes, this is not sufficient: for example, we may want to specify tool paths or names in the configuration file. This can be easily achieved via @@ -619,7 +664,7 @@ the <tt class="docutils literal"><span class="pre">case</span></tt> expression ( </pre> </div> <div class="section" id="how-plugins-are-loaded"> -<span id="priorities"></span><h2><a class="toc-backref" href="#id18">How plugins are loaded</a></h2> +<span id="priorities"></span><h2><a class="toc-backref" href="#id19">How plugins are loaded</a></h2> <p>It is possible for LLVMC plugins to depend on each other. For example, one can create edges between nodes defined in some other plugin. To make this work, however, that plugin should be loaded first. To @@ -635,7 +680,7 @@ with 0. Therefore, the plugin with the highest priority value will be loaded last.</p> </div> <div class="section" id="debugging"> -<h2><a class="toc-backref" href="#id19">Debugging</a></h2> +<h2><a class="toc-backref" href="#id20">Debugging</a></h2> <p>When writing LLVMC plugins, it can be useful to get a visual view of the resulting compilation graph. This can be achieved via the command line option <tt class="docutils literal"><span class="pre">--view-graph</span></tt>. This command assumes that <a class="reference external" href="http://www.graphviz.org/">Graphviz</a> and @@ -651,7 +696,7 @@ perform any compilation tasks and returns the number of encountered errors as its status code.</p> </div> <div class="section" id="conditioning-on-the-executable-name"> -<h2><a class="toc-backref" href="#id20">Conditioning on the executable name</a></h2> +<h2><a class="toc-backref" href="#id21">Conditioning on the executable name</a></h2> <p>For now, the executable name (the value passed to the driver in <tt class="docutils literal"><span class="pre">argv[0]</span></tt>) is accessible only in the C++ code (i.e. hooks). Use the following code:</p> <pre class="literal-block"> @@ -682,7 +727,7 @@ the <tt class="docutils literal"><span class="pre">Base</span></tt> plugin behav <a href="mailto:foldr@codedgers.com">Mikhail Glushenkov</a><br /> <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br /> -Last modified: $Date: 2009-10-12 16:46:08 +0200 (Mon, 12 Oct 2009) $ +Last modified: $Date: 2009-10-26 02:35:46 +0100 (Mon, 26 Oct 2009) $ </address></div> </div> </div> diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html index e3ceec6..ca6563b 100644 --- a/docs/GettingStarted.html +++ b/docs/GettingStarted.html @@ -1154,7 +1154,7 @@ first command may not be required if you are already using the module):</p> <div class="doc_code"> <pre> $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc -$ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register +$ echo ':llvm:M::BC::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register $ chmod u+x hello.bc (if needed) $ ./hello.bc </pre> @@ -1636,7 +1636,7 @@ out:</p> <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> <a href="http://llvm.x10sys.com/rspencer/">Reid Spencer</a><br> <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-10-23 08:20:06 +0200 (Fri, 23 Oct 2009) $ + Last modified: $Date: 2009-11-04 07:15:28 +0100 (Wed, 04 Nov 2009) $ </address> </body> </html> 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> diff --git a/docs/Passes.html b/docs/Passes.html index 48f5adf..2107e13 100644 --- a/docs/Passes.html +++ b/docs/Passes.html @@ -158,7 +158,6 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <tr><td><a href="#memcpyopt">-memcpyopt</a></td><td>Optimize use of memcpy and friends</td></tr> <tr><td><a href="#mergereturn">-mergereturn</a></td><td>Unify function exit nodes</td></tr> <tr><td><a href="#prune-eh">-prune-eh</a></td><td>Remove unused exception handling info</td></tr> -<tr><td><a href="#raiseallocs">-raiseallocs</a></td><td>Raise allocations from calls to instructions</td></tr> <tr><td><a href="#reassociate">-reassociate</a></td><td>Reassociate expressions</td></tr> <tr><td><a href="#reg2mem">-reg2mem</a></td><td>Demote all values to stack slots</td></tr> <tr><td><a href="#scalarrepl">-scalarrepl</a></td><td>Scalar Replacement of Aggregates</td></tr> @@ -1504,17 +1503,6 @@ if (X < 3) {</pre> <!-------------------------------------------------------------------------- --> <div class="doc_subsection"> - <a name="raiseallocs">Raise allocations from calls to instructions</a> -</div> -<div class="doc_text"> - <p> - Converts <tt>@malloc</tt> and <tt>@free</tt> calls to <tt>malloc</tt> and - <tt>free</tt> instructions. - </p> -</div> - -<!-------------------------------------------------------------------------- --> -<div class="doc_subsection"> <a name="reassociate">Reassociate expressions</a> </div> <div class="doc_text"> @@ -1799,8 +1787,8 @@ if (X < 3) {</pre> integrals f.e.</li> <li>All of the constants in a switch statement are of the correct type.</li> <li>The code is in valid SSA form.</li> - <li>It should be illegal to put a label into any other type (like a - structure) or to return one. [except constant arrays!]</li> + <li>It is illegal to put a label into any other type (like a structure) or + to return one.</li> <li>Only phi nodes can be self referential: <tt>%x = add i32 %x, %x</tt> is invalid.</li> <li>PHI nodes must have an entry for each predecessor, with no extras.</li> @@ -1860,7 +1848,7 @@ if (X < 3) {</pre> <a href="mailto:rspencer@x10sys.com">Reid Spencer</a><br> <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-10-12 16:46:08 +0200 (Mon, 12 Oct 2009) $ + Last modified: $Date: 2009-10-28 05:47:06 +0100 (Wed, 28 Oct 2009) $ </address> </body> diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 2b93b1f..5a0936f 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -1058,7 +1058,7 @@ there isn't already one.</p> <li>LLVM will not correctly compile on Solaris and/or OpenSolaris using the stock GCC 3.x.x series 'out the box', -See: <a href="#brokengcc">Broken versions of GCC and other tools</a>. +See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>. However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a> for x86/x86-64 has been made available from the third party AuroraUX Project that has been meticulously tested for bootstrapping LLVM & Clang.</li> @@ -1348,7 +1348,7 @@ lists</a>.</p> src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-10-16 18:30:58 +0200 (Fri, 16 Oct 2009) $ + Last modified: $Date: 2009-11-03 22:50:09 +0100 (Tue, 03 Nov 2009) $ </address> </body> diff --git a/docs/TableGenFundamentals.html b/docs/TableGenFundamentals.html index 7ae1ca4..4ae6718 100644 --- a/docs/TableGenFundamentals.html +++ b/docs/TableGenFundamentals.html @@ -151,7 +151,7 @@ file prints this (at the time of this writing):</p> <b>bit</b> isReMaterializable = 0; <b>bit</b> isPredicable = 0; <b>bit</b> hasDelaySlot = 0; - <b>bit</b> usesCustomDAGSchedInserter = 0; + <b>bit</b> usesCustomInserter = 0; <b>bit</b> hasCtrlDep = 0; <b>bit</b> isNotDuplicable = 0; <b>bit</b> hasSideEffects = 0; @@ -794,7 +794,7 @@ This should highlight the APIs in <tt>TableGen/Record.h</tt>.</p> <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br> - Last modified: $Date: 2009-10-05 04:51:06 +0200 (Mon, 05 Oct 2009) $ + Last modified: $Date: 2009-10-29 19:10:34 +0100 (Thu, 29 Oct 2009) $ </address> </body> diff --git a/docs/tutorial/LangImpl4.html b/docs/tutorial/LangImpl4.html index 3188135..728d518 100644 --- a/docs/tutorial/LangImpl4.html +++ b/docs/tutorial/LangImpl4.html @@ -388,24 +388,19 @@ entry: </pre> </div> -<p>This illustrates that we can now call user code, but there is something a bit subtle -going on here. Note that we only invoke the JIT on the anonymous functions -that <em>call testfunc</em>, but we never invoked it on <em>testfunc -</em>itself.</p> - -<p>What actually happened here is that the anonymous function was -JIT'd when requested. When the Kaleidoscope app calls through the function -pointer that is returned, the anonymous function starts executing. It ends up -making the call to the "testfunc" function, and ends up in a stub that invokes -the JIT, lazily, on testfunc. Once the JIT finishes lazily compiling testfunc, -it returns and the code re-executes the call.</p> - -<p>In summary, the JIT will lazily JIT code, on the fly, as it is needed. The -JIT provides a number of other more advanced interfaces for things like freeing -allocated machine code, rejit'ing functions to update them, etc. However, even -with this simple code, we get some surprisingly powerful capabilities - check -this out (I removed the dump of the anonymous functions, you should get the idea -by now :) :</p> +<p>This illustrates that we can now call user code, but there is something a bit +subtle going on here. Note that we only invoke the JIT on the anonymous +functions that <em>call testfunc</em>, but we never invoked it +on <em>testfunc</em> itself. What actually happened here is that the JIT +scanned for all non-JIT'd functions transitively called from the anonymous +function and compiled all of them before returning +from <tt>getPointerToFunction()</tt>.</p> + +<p>The JIT provides a number of other more advanced interfaces for things like +freeing allocated machine code, rejit'ing functions to update them, etc. +However, even with this simple code, we get some surprisingly powerful +capabilities - check this out (I removed the dump of the anonymous functions, +you should get the idea by now :) :</p> <div class="doc_code"> <pre> @@ -453,8 +448,8 @@ directly.</p> resolved. It allows you to establish explicit mappings between IR objects and addresses (useful for LLVM global variables that you want to map to static tables, for example), allows you to dynamically decide on the fly based on the -function name, and even allows you to have the JIT abort itself if any lazy -compilation is attempted.</p> +function name, and even allows you to have the JIT compile functions lazily the +first time they're called.</p> <p>One interesting application of this is that we can now extend the language by writing arbitrary C++ code to implement operations. For example, if we add: diff --git a/docs/tutorial/OCamlLangImpl4.html b/docs/tutorial/OCamlLangImpl4.html index 26f2532..543e12f 100644 --- a/docs/tutorial/OCamlLangImpl4.html +++ b/docs/tutorial/OCamlLangImpl4.html @@ -406,22 +406,17 @@ entry: <p>This illustrates that we can now call user code, but there is something a bit subtle going on here. Note that we only invoke the JIT on the anonymous -functions that <em>call testfunc</em>, but we never invoked it on <em>testfunc -</em>itself.</p> - -<p>What actually happened here is that the anonymous function was JIT'd when -requested. When the Kaleidoscope app calls through the function pointer that is -returned, the anonymous function starts executing. It ends up making the call -to the "testfunc" function, and ends up in a stub that invokes the JIT, lazily, -on testfunc. Once the JIT finishes lazily compiling testfunc, -it returns and the code re-executes the call.</p> - -<p>In summary, the JIT will lazily JIT code, on the fly, as it is needed. The -JIT provides a number of other more advanced interfaces for things like freeing -allocated machine code, rejit'ing functions to update them, etc. However, even -with this simple code, we get some surprisingly powerful capabilities - check -this out (I removed the dump of the anonymous functions, you should get the idea -by now :) :</p> +functions that <em>call testfunc</em>, but we never invoked it +on <em>testfunc</em> itself. What actually happened here is that the JIT +scanned for all non-JIT'd functions transitively called from the anonymous +function and compiled all of them before returning +from <tt>run_function</tt>.</p> + +<p>The JIT provides a number of other more advanced interfaces for things like +freeing allocated machine code, rejit'ing functions to update them, etc. +However, even with this simple code, we get some surprisingly powerful +capabilities - check this out (I removed the dump of the anonymous functions, +you should get the idea by now :) :</p> <div class="doc_code"> <pre> @@ -467,8 +462,8 @@ calls in the module to call the libm version of <tt>sin</tt> directly.</p> get resolved. It allows you to establish explicit mappings between IR objects and addresses (useful for LLVM global variables that you want to map to static tables, for example), allows you to dynamically decide on the fly based on the -function name, and even allows you to have the JIT abort itself if any lazy -compilation is attempted.</p> +function name, and even allows you to have the JIT compile functions lazily the +first time they're called.</p> <p>One interesting application of this is that we can now extend the language by writing arbitrary C code to implement operations. For example, if we add: |
