diff options
52 files changed, 1632 insertions, 1569 deletions
diff --git a/docs/BitCodeFormat.html b/docs/BitCodeFormat.html index 396904a..d208848 100644 --- a/docs/BitCodeFormat.html +++ b/docs/BitCodeFormat.html @@ -50,7 +50,7 @@ <h2><a name="abstract">Abstract</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document describes the LLVM bitstream file format and the encoding of the LLVM IR into it.</p> @@ -61,7 +61,7 @@ the LLVM IR into it.</p> <h2><a name="overview">Overview</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> What is commonly known as the LLVM bitcode file format (also, sometimes @@ -91,7 +91,7 @@ wrapper format, then describes the record structure used by LLVM IR files. <h2><a name="bitstream">Bitstream Format</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The bitstream format is literally a stream of bits, with a very simple @@ -114,14 +114,12 @@ href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a> tool can be used to dump and inspect arbitrary bitstreams, which is very useful for understanding the encoding.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="magic">Magic Numbers</a> </h3> -<div class="doc_text"> +<div> <p>The first two bytes of a bitcode file are 'BC' (0x42, 0x43). The second two bytes are an application-specific magic number. Generic @@ -135,7 +133,7 @@ bitcode, while application-specific programs will want to look at all four.</p> <a name="primitives">Primitives</a> </h3> -<div class="doc_text"> +<div> <p> A bitstream literally consists of a stream of bits, which are read in order @@ -146,14 +144,12 @@ Width Integers</a> or as <a href="#variablewidth">Variable Width Integers</a>. </p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="fixedwidth">Fixed Width Integers</a> </h4> -<div class="doc_text"> +<div> <p>Fixed-width integer values have their low bits emitted directly to the file. For example, a 3-bit integer value encodes 1 as 001. Fixed width integers @@ -168,7 +164,7 @@ Integers</a>. <a name="variablewidth">Variable Width Integers</a> </h4> -<div class="doc_text"> +<div> <p>Variable-width integer (VBR) values encode values of arbitrary size, optimizing for the case where the values are small. Given a 4-bit VBR field, @@ -188,7 +184,7 @@ value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value <!-- _______________________________________________________________________ --> <h4><a name="char6">6-bit characters</a></h4> -<div class="doc_text"> +<div> <p>6-bit characters encode common characters into a fixed 6-bit field. They represent the following characters with the following 6-bit values:</p> @@ -212,7 +208,7 @@ characters not in the set.</p> <!-- _______________________________________________________________________ --> <h4><a name="wordalign">Word Alignment</a></h4> -<div class="doc_text"> +<div> <p>Occasionally, it is useful to emit zero bits until the bitstream is a multiple of 32 bits. This ensures that the bit position in the stream can be @@ -220,13 +216,14 @@ represented as a multiple of 32-bit words.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="abbrevid">Abbreviation IDs</a> </h3> -<div class="doc_text"> +<div> <p> A bitstream is a sequential series of <a href="#blocks">Blocks</a> and @@ -262,7 +259,7 @@ an <a href="#abbrev_records">abbreviated record encoding</a>.</p> <a name="blocks">Blocks</a> </h3> -<div class="doc_text"> +<div> <p> Blocks in a bitstream denote nested regions of the stream, and are identified by @@ -303,12 +300,10 @@ its own set of abbreviations, and its own abbrev id width. When a sub-block is popped, the saved values are restored. </p> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="ENTER_SUBBLOCK">ENTER_SUBBLOCK Encoding</a></h4> -<div class="doc_text"> +<div> <p><tt>[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>, <align32bits>, blocklen<sub>32</sub>]</tt></p> @@ -329,7 +324,7 @@ reader to skip over the entire block in one jump. <!-- _______________________________________________________________________ --> <h4><a name="END_BLOCK">END_BLOCK Encoding</a></h4> -<div class="doc_text"> +<div> <p><tt>[END_BLOCK, <align32bits>]</tt></p> @@ -341,14 +336,14 @@ an even multiple of 32-bits. </div> - +</div> <!-- ======================================================================= --> <h3> <a name="datarecord">Data Records</a> </h3> -<div class="doc_text"> +<div> <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 @@ -360,12 +355,10 @@ which encodes the target triple of a module. The code is ASCII codes for the characters in the string. </p> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="UNABBREV_RECORD">UNABBREV_RECORD Encoding</a></h4> -<div class="doc_text"> +<div> <p><tt>[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>, op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]</tt></p> @@ -391,7 +384,7 @@ bits. This is not an efficient encoding, but it is fully general. <!-- _______________________________________________________________________ --> <h4><a name="abbrev_records">Abbreviated Record Encoding</a></h4> -<div class="doc_text"> +<div> <p><tt>[<abbrevid>, fields...]</tt></p> @@ -412,12 +405,14 @@ operand value).</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="abbreviations">Abbreviations</a> </h3> -<div class="doc_text"> +<div> <p> Abbreviations are an important form of compression for bitstreams. The idea is to specify a dense encoding for a class of records once, then use that encoding @@ -435,12 +430,11 @@ 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> -</div> <!-- _______________________________________________________________________ --> <h4><a name="DEFINE_ABBREV">DEFINE_ABBREV Encoding</a></h4> -<div class="doc_text"> +<div> <p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1, ...]</tt></p> @@ -555,12 +549,14 @@ used for any other string value. </div> +</div> + <!-- ======================================================================= --> <h3> <a name="stdblocks">Standard Blocks</a> </h3> -<div class="doc_text"> +<div> <p> In addition to the basic block structure and record encodings, the bitstream @@ -569,12 +565,10 @@ 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> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="BLOCKINFO">#0 - BLOCKINFO Block</a></h4> -<div class="doc_text"> +<div> <p> The <tt>BLOCKINFO</tt> block allows the description of metadata for other @@ -623,11 +617,15 @@ from the corresponding blocks. It is not safe to skip them. </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2><a name="wrapper">Bitcode Wrapper Format</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper @@ -658,7 +656,7 @@ value that can be used to encode the CPU of the target. <h2><a name="llvmir">LLVM IR Encoding</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> LLVM IR is encoded into a bitstream by defining blocks and records. It uses @@ -669,17 +667,17 @@ that the writer uses, as these are fully self-described in the file, and the reader is not allowed to build in any knowledge of this. </p> -</div> - <!-- ======================================================================= --> <h3> <a name="basics">Basics</a> </h3> +<div> + <!-- _______________________________________________________________________ --> <h4><a name="ir_magic">LLVM IR Magic Number</a></h4> -<div class="doc_text"> +<div> <p> The magic number for LLVM IR files is: @@ -701,7 +699,7 @@ When combined with the bitcode magic number and viewed as bytes, this is <!-- _______________________________________________________________________ --> <h4><a name="ir_signed_vbr">Signed VBRs</a></h4> -<div class="doc_text"> +<div> <p> <a href="#variablewidth">Variable Width Integer</a> encoding is an efficient way to @@ -734,7 +732,7 @@ within <tt>CONSTANTS_BLOCK</tt> blocks. <!-- _______________________________________________________________________ --> <h4><a name="ir_blocks">LLVM IR Blocks</a></h4> -<div class="doc_text"> +<div> <p> LLVM IR is defined with the following blocks: @@ -762,12 +760,14 @@ LLVM IR is defined with the following blocks: </div> +</div> + <!-- ======================================================================= --> <h3> <a name="MODULE_BLOCK">MODULE_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <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 @@ -787,12 +787,10 @@ following sub-blocks: <li><a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a></li> </ul> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_VERSION">MODULE_CODE_VERSION Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[VERSION, version#]</tt></p> @@ -804,7 +802,7 @@ time.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_TRIPLE">MODULE_CODE_TRIPLE Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[TRIPLE, ...string...]</tt></p> <p>The <tt>TRIPLE</tt> record (code 2) contains a variable number of @@ -815,7 +813,7 @@ specification string.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_DATALAYOUT">MODULE_CODE_DATALAYOUT Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[DATALAYOUT, ...string...]</tt></p> <p>The <tt>DATALAYOUT</tt> record (code 3) contains a variable number of @@ -826,7 +824,7 @@ specification string.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_ASM">MODULE_CODE_ASM Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[ASM, ...string...]</tt></p> <p>The <tt>ASM</tt> record (code 4) contains a variable number of @@ -837,7 +835,7 @@ individual assembly blocks separated by newline (ASCII 10) characters.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[SECTIONNAME, ...string...]</tt></p> <p>The <tt>SECTIONNAME</tt> record (code 5) contains a variable number @@ -852,7 +850,7 @@ referenced by the 1-based index in the <i>section</i> fields of <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_DEPLIB">MODULE_CODE_DEPLIB Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[DEPLIB, ...string...]</tt></p> <p>The <tt>DEPLIB</tt> record (code 6) contains a variable number of @@ -865,7 +863,7 @@ library name referenced.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_GLOBALVAR">MODULE_CODE_GLOBALVAR Record</a></h4> -<div class="doc_text"> +<div> <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 @@ -929,7 +927,7 @@ has <tt>unnamed_addr</tt></li> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_FUNCTION">MODULE_CODE_FUNCTION Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]</tt></p> @@ -985,7 +983,7 @@ has <tt>unnamed_addr</tt></li> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_ALIAS">MODULE_CODE_ALIAS Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[ALIAS, alias type, aliasee val#, linkage, visibility]</tt></p> @@ -1009,7 +1007,7 @@ for this alias</li> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_PURGEVALS">MODULE_CODE_PURGEVALS Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[PURGEVALS, numvals]</tt></p> <p>The <tt>PURGEVALS</tt> record (code 10) resets the module-level @@ -1022,7 +1020,7 @@ new value indices will start from the given <i>numvals</i> value.</p> <!-- _______________________________________________________________________ --> <h4><a name="MODULE_CODE_GCNAME">MODULE_CODE_GCNAME Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[GCNAME, ...string...]</tt></p> <p>The <tt>GCNAME</tt> record (code 11) contains a variable number of @@ -1033,12 +1031,14 @@ 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> + <!-- ======================================================================= --> <h3> <a name="PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>PARAMATTR_BLOCK</tt> block (id 9) contains a table of entries describing the attributes of function parameters. These @@ -1052,13 +1052,10 @@ href="#FUNC_CODE_INST_CALL"><tt>INST_CALL</tt></a> records.</p> that each is unique (i.e., no two indicies represent equivalent attribute lists). </p> -</div> - - <!-- _______________________________________________________________________ --> <h4><a name="PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[ENTRY, paramidx0, attr0, paramidx1, attr1...]</tt></p> @@ -1099,12 +1096,14 @@ the logarithm base 2 of the requested alignment, plus 1</li> </ul> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="TYPE_BLOCK">TYPE_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TYPE_BLOCK</tt> block (id 10) contains records which constitute a table of type operator entries used to represent types @@ -1119,12 +1118,10 @@ type operator records. each entry is unique (i.e., no two indicies represent structurally equivalent types). </p> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_NUMENTRY">TYPE_CODE_NUMENTRY Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[NUMENTRY, numentries]</tt></p> @@ -1138,7 +1135,7 @@ in the block. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_VOID">TYPE_CODE_VOID Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[VOID]</tt></p> @@ -1150,7 +1147,7 @@ type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_FLOAT">TYPE_CODE_FLOAT Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[FLOAT]</tt></p> @@ -1162,7 +1159,7 @@ floating point) type to the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_DOUBLE">TYPE_CODE_DOUBLE Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[DOUBLE]</tt></p> @@ -1174,7 +1171,7 @@ floating point) type to the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_LABEL">TYPE_CODE_LABEL Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[LABEL]</tt></p> @@ -1186,7 +1183,7 @@ the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_OPAQUE">TYPE_CODE_OPAQUE Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[OPAQUE]</tt></p> @@ -1199,7 +1196,7 @@ unified. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_INTEGER">TYPE_CODE_INTEGER Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[INTEGER, width]</tt></p> @@ -1212,7 +1209,7 @@ integer type. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_POINTER">TYPE_CODE_POINTER Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[POINTER, pointee type, address space]</tt></p> @@ -1232,7 +1229,7 @@ default address space is zero. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_FUNCTION">TYPE_CODE_FUNCTION Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[FUNCTION, vararg, ignored, retty, ...paramty... ]</tt></p> @@ -1256,7 +1253,7 @@ parameter types of the function</li> <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_STRUCT">TYPE_CODE_STRUCT Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[STRUCT, ispacked, ...eltty...]</tt></p> @@ -1274,7 +1271,7 @@ types of the structure</li> <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_ARRAY">TYPE_CODE_ARRAY Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[ARRAY, numelts, eltty]</tt></p> @@ -1291,7 +1288,7 @@ table. The operand fields are</p> <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_VECTOR">TYPE_CODE_VECTOR Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[VECTOR, numelts, eltty]</tt></p> @@ -1308,7 +1305,7 @@ table. The operand fields are</p> <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_X86_FP80">TYPE_CODE_X86_FP80 Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[X86_FP80]</tt></p> @@ -1320,7 +1317,7 @@ floating point) type to the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_FP128">TYPE_CODE_FP128 Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[FP128]</tt></p> @@ -1332,7 +1329,7 @@ floating point) type to the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_PPC_FP128">TYPE_CODE_PPC_FP128 Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[PPC_FP128]</tt></p> @@ -1344,7 +1341,7 @@ floating point) type to the type table. <!-- _______________________________________________________________________ --> <h4><a name="TYPE_CODE_METADATA">TYPE_CODE_METADATA Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[METADATA]</tt></p> @@ -1353,12 +1350,14 @@ type to the type table. </p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>CONSTANTS_BLOCK</tt> block (id 11) ... </p> @@ -1371,7 +1370,7 @@ type to the type table. <a name="FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>FUNCTION_BLOCK</tt> block (id 12) ... </p> @@ -1394,19 +1393,17 @@ type to the type table. <a name="TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TYPE_SYMTAB_BLOCK</tt> block (id 13) contains entries which map between module-level named types and their corresponding type indices. </p> -</div> - <!-- _______________________________________________________________________ --> <h4><a name="TST_CODE_ENTRY">TST_CODE_ENTRY Record</a></h4> -<div class="doc_text"> +<div> <p><tt>[ENTRY, typeid, ...string...]</tt></p> @@ -1417,13 +1414,14 @@ name. Each entry corresponds to a single named type. </p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>VALUE_SYMTAB_BLOCK</tt> block (id 14) ... </p> @@ -1436,7 +1434,7 @@ name. Each entry corresponds to a single named type. <a name="METADATA_BLOCK">METADATA_BLOCK Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>METADATA_BLOCK</tt> block (id 15) ... </p> @@ -1449,13 +1447,14 @@ name. Each entry corresponds to a single named type. <a name="METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>METADATA_ATTACHMENT</tt> block (id 16) ... </p> </div> +</div> <!-- *********************************************************************** --> <hr> diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index 5568fc7..154edfd 100644 --- a/docs/Bugpoint.html +++ b/docs/Bugpoint.html @@ -32,7 +32,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><tt>bugpoint</tt> narrows down the source of problems in LLVM tools and passes. It can be used to debug three types of failures: optimizer crashes, @@ -55,7 +55,7 @@ href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><tt>bugpoint</tt> is designed to be a useful tool without requiring any hooks into the LLVM infrastructure at all. It works with any and all LLVM @@ -68,14 +68,12 @@ is still worth it. Note that <tt>bugpoint</tt> is generally very quick unless debugging a miscompilation where each test of the program (which requires executing it) takes a long time.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="autoselect">Automatic Debugger Selection</a> </h3> -<div class="doc_text"> +<div> <p><tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file specified on the command line and links them together into a single module, called the test @@ -108,7 +106,7 @@ Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p> <a name="crashdebug">Crash debugger</a> </h3> -<div class="doc_text"> +<div> <p>If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard as it can to reduce the list of passes (for optimizer crashes) and the size of @@ -133,7 +131,7 @@ reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p> <a name="codegendebug">Code generator debugger</a> </h3> -<div class="doc_text"> +<div> <p>The code generator debugger attempts to narrow down the amount of code that is being miscompiled by the selected code generator. To do this, it takes the @@ -154,7 +152,7 @@ good code.</p> <a name="miscompilationdebug">Miscompilation debugger</a> </h3> -<div class="doc_text"> +<div> <p>The miscompilation debugger works similarly to the code generator debugger. It works by splitting the test program into two pieces, running the @@ -166,13 +164,15 @@ assumes that the selected code generator is working properly.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="advice">Advice for using bugpoint</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <tt>bugpoint</tt> can be a remarkably useful tool, but it sometimes works in non-obvious ways. Here are some hints and tips:<p> diff --git a/docs/CMake.html b/docs/CMake.html index 8ea4377..ba23208 100644 --- a/docs/CMake.html +++ b/docs/CMake.html @@ -41,7 +41,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><a href="http://www.cmake.org/">CMake</a> is a cross-platform build-generator tool. CMake does not build the project, it generates @@ -64,7 +64,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> We use here the command-line, non-interactive CMake interface </p> @@ -117,7 +117,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section explains basic aspects of CMake, mostly for explaining those options which you may need on your day-to-day @@ -165,7 +165,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Variables customize how the build will be generated. Options are boolean variables, with possible values ON/OFF. Options and @@ -194,14 +194,12 @@ <p><tt>cmake -DVARIABLE:TYPE=value path/to/llvm/source</tt></p> </div> -</div> - <!-- ======================================================================= --> <h3> <a name="freccmake">Frequently-used CMake variables</a> </h3> -<div class="doc_text"> +<div> <p>Here are listed some of the CMake variables that are used often, along with a brief explanation and LLVM-specific notes. For full @@ -244,7 +242,7 @@ <a name="llvmvars">LLVM-specific variables</a> </h3> -<div class="doc_text"> +<div> <dl> <dt><b>LLVM_TARGETS_TO_BUILD</b>:STRING</dt> @@ -357,13 +355,15 @@ </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="testing">Executing the test suite</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Testing is performed when the <i>check</i> target is built. For instance, if you are using makefiles, execute this command while on @@ -383,7 +383,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>See <a href="http://www.vtk.org/Wiki/CMake_Cross_Compiling">this wiki page</a> for generic instructions on how to cross-compile @@ -404,7 +404,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The most difficult part of adding LLVM to the build of a project is to determine the set of LLVM libraries corresponding to the set @@ -459,14 +459,12 @@ </pre> </div> -</div> - <!-- ======================================================================= --> <h3> <a name="passdev">Developing LLVM pass out of source</a> </h3> -<div class="doc_text"> +<div> <p>It is possible to develop LLVM passes against installed LLVM. An example of project layout provided below:</p> @@ -518,23 +516,23 @@ </div> <!-- *********************************************************************** --> +</div> + <!-- *********************************************************************** --> <h2> <a name="specifics">Compiler/Platform specific topics</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Notes for specific compilers and/or platforms.</p> -</div> - <h3> <a name="msvc">Microsoft Visual C++</a> </h3> -<div class="doc_text"> +<div> <dl> <dt><b>LLVM_COMPILER_JOBS</b>:STRING</dt> @@ -546,6 +544,8 @@ </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 50036f2..9185563 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -132,7 +132,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM target-independent code generator is a framework that provides a suite of reusable components for translating the LLVM internal representation @@ -188,14 +188,12 @@ depend on the target-description and machine code representation classes, ensuring that it is portable.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="required">Required components in the code generator</a> </h3> -<div class="doc_text"> +<div> <p>The two pieces of the LLVM code generator are the high-level interface to the code generator and the set of reusable components that can be used to build @@ -227,7 +225,7 @@ <a name="high-level-design">The high-level design of the code generator</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM target-independent code generator is designed to support efficient and quality code generation for standard register-based microprocessors. @@ -301,7 +299,7 @@ <a name="tablegen">Using TableGen for target description</a> </h3> -<div class="doc_text"> +<div> <p>The target description classes require a detailed description of the target architecture. These target descriptions often have a large amount of common @@ -324,13 +322,15 @@ </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="targetdesc">Target description classes</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM target description classes (located in the <tt>include/llvm/Target</tt> directory) provide an abstract description of @@ -346,14 +346,12 @@ <tt><a href="#targetmachine">TargetMachine</a></tt> class provides accessors that should be implemented by the target.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="targetmachine">The <tt>TargetMachine</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetMachine</tt> class provides virtual methods that are used to access the target-specific implementations of the various target description @@ -373,7 +371,7 @@ <a name="targetdata">The <tt>TargetData</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetData</tt> class is the only required target description class, and it is the only class that is not extensible (you cannot derived a new @@ -389,7 +387,7 @@ <a name="targetlowering">The <tt>TargetLowering</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction selectors primarily to describe how LLVM code should be lowered to @@ -415,7 +413,7 @@ <a name="targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetRegisterInfo</tt> class is used to describe the register file of the target and any interactions between the registers.</p> @@ -449,7 +447,7 @@ <a name="targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetInstrInfo</tt> class is used to describe the machine instructions supported by the target. It is essentially an array of @@ -467,7 +465,7 @@ <a name="targetframeinfo">The <tt>TargetFrameInfo</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetFrameInfo</tt> class is used to provide information about the stack frame layout of the target. It holds the direction of stack growth, the @@ -483,7 +481,7 @@ <a name="targetsubtarget">The <tt>TargetSubtarget</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetSubtarget</tt> class is used to provide information about the specific chip set being targeted. A sub-target informs code generation of @@ -499,7 +497,7 @@ <a name="targetjitinfo">The <tt>TargetJITInfo</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>TargetJITInfo</tt> class exposes an abstract interface used by the Just-In-Time code generator to perform target-specific activities, such as @@ -509,13 +507,15 @@ </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="codegendesc">Machine code description classes</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>At the high-level, LLVM code is translated to a machine specific representation formed out of @@ -528,14 +528,12 @@ SSA representation for machine code, as well as a register allocated, non-SSA form.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="machineinstr">The <tt>MachineInstr</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>Target machine instructions are represented as instances of the <tt>MachineInstr</tt> class. This class is an extremely abstract way of @@ -576,14 +574,12 @@ <p>Also if the first operand is a def, it is easier to <a href="#buildmi">create instructions</a> whose only def is the first operand.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="buildmi">Using the <tt>MachineInstrBuilder.h</tt> functions</a> </h4> -<div class="doc_text"> +<div> <p>Machine instructions are created by using the <tt>BuildMI</tt> functions, located in the <tt>include/llvm/CodeGen/MachineInstrBuilder.h</tt> file. The @@ -634,7 +630,7 @@ MI.addReg(Reg, RegState::Define); <a name="fixedregs">Fixed (preassigned) registers</a> </h4> -<div class="doc_text"> +<div> <p>One important issue that the code generator needs to be aware of is the presence of fixed registers. In particular, there are often places in the @@ -706,7 +702,7 @@ ret <a name="ssa">Machine code in SSA form</a> </h4> -<div class="doc_text"> +<div> <p><tt>MachineInstr</tt>'s are initially selected in SSA-form, and are maintained in SSA-form until register allocation happens. For the most part, @@ -719,12 +715,14 @@ ret </div> +</div> + <!-- ======================================================================= --> <h3> <a name="machinebasicblock">The <tt>MachineBasicBlock</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>MachineBasicBlock</tt> class contains a list of machine instructions (<tt><a href="#machineinstr">MachineInstr</a></tt> instances). It roughly @@ -741,7 +739,7 @@ ret <a name="machinefunction">The <tt>MachineFunction</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The <tt>MachineFunction</tt> class contains a list of machine basic blocks (<tt><a href="#machinebasicblock">MachineBasicBlock</a></tt> instances). It @@ -754,6 +752,7 @@ ret </div> +</div> <!-- *********************************************************************** --> <h2> @@ -761,7 +760,7 @@ ret </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The MC Layer is used to represent and process code at the raw machine code @@ -779,15 +778,12 @@ of important subsystems that interact at this layer, they are described later in this manual. </p> -</div> - - <!-- ======================================================================= --> <h3> <a name="mcstreamer">The <tt>MCStreamer</tt> API</a> </h3> -<div class="doc_text"> +<div> <p> MCStreamer is best thought of as an assembler API. It is an abstract API which @@ -821,7 +817,7 @@ MCObjectStreamer implements a full assembler. <a name="mccontext">The <tt>MCContext</tt> class</a> </h3> -<div class="doc_text"> +<div> <p> The MCContext class is the owner of a variety of uniqued data structures at the @@ -836,7 +832,7 @@ interact with to create symbols and sections. This class can not be subclassed. <a name="mcsymbol">The <tt>MCSymbol</tt> class</a> </h3> -<div class="doc_text"> +<div> <p> The MCSymbol class represents a symbol (aka label) in the assembly file. There @@ -868,7 +864,7 @@ like this to the .s file:<p> <a name="mcsection">The <tt>MCSection</tt> class</a> </h3> -<div class="doc_text"> +<div> <p> The MCSection class represents an object-file specific section. It is subclassed @@ -886,7 +882,7 @@ directive in a .s file). <a name="mcinst">The <tt>MCInst</tt> class</a> </h3> -<div class="doc_text"> +<div> <p> The MCInst class is a target-independent representation of an instruction. It @@ -904,6 +900,7 @@ printer, and the type generated by the assembly parser and disassembler. </div> +</div> <!-- *********************************************************************** --> <h2> @@ -911,20 +908,18 @@ printer, and the type generated by the assembly parser and disassembler. </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section documents the phases described in the <a href="#high-level-design">high-level design of the code generator</a>. It explains how they work and some of the rationale behind their design.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="instselect">Instruction Selection</a> </h3> -<div class="doc_text"> +<div> <p>Instruction Selection is the process of translating LLVM code presented to the code generator into target-specific machine instructions. There are @@ -936,14 +931,12 @@ printer, and the type generated by the assembly parser and disassembler. selector to be generated from these <tt>.td</tt> files, though currently there are still things that require custom C++ code.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="selectiondag_intro">Introduction to SelectionDAGs</a> </h4> -<div class="doc_text"> +<div> <p>The SelectionDAG provides an abstraction for code representation in a way that is amenable to instruction selection using automatic techniques @@ -1005,7 +998,7 @@ printer, and the type generated by the assembly parser and disassembler. <a name="selectiondag_process">SelectionDAG Instruction Selection Process</a> </h4> -<div class="doc_text"> +<div> <p>SelectionDAG-based instruction selection consists of the following steps:</p> @@ -1086,7 +1079,7 @@ printer, and the type generated by the assembly parser and disassembler. <a name="selectiondag_build">Initial SelectionDAG Construction</a> </h4> -<div class="doc_text"> +<div> <p>The initial SelectionDAG is naïvely peephole expanded from the LLVM input by the <tt>SelectionDAGLowering</tt> class in the @@ -1106,7 +1099,7 @@ printer, and the type generated by the assembly parser and disassembler. <a name="selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a> </h4> -<div class="doc_text"> +<div> <p>The Legalize phase is in charge of converting a DAG to only use the types that are natively supported by the target.</p> @@ -1139,7 +1132,7 @@ printer, and the type generated by the assembly parser and disassembler. <a name="selectiondag_legalize">SelectionDAG Legalize Phase</a> </h4> -<div class="doc_text"> +<div> <p>The Legalize phase is in charge of converting a DAG to only use the operations that are natively supported by the target.</p> @@ -1173,7 +1166,7 @@ printer, and the type generated by the assembly parser and disassembler. </a> </h4> -<div class="doc_text"> +<div> <p>The SelectionDAG optimization phase is run multiple times for code generation, immediately after the DAG is built and once after each @@ -1207,7 +1200,7 @@ printer, and the type generated by the assembly parser and disassembler. <a name="selectiondag_select">SelectionDAG Select Phase</a> </h4> -<div class="doc_text"> +<div> <p>The Select phase is the bulk of the target-specific code for instruction selection. This phase takes a legal SelectionDAG as input, pattern matches @@ -1368,7 +1361,7 @@ def : Pat<(i32 imm:$imm), <a name="selectiondag_sched">SelectionDAG Scheduling and Formation Phase</a> </h4> -<div class="doc_text"> +<div> <p>The scheduling phase takes the DAG of target instructions from the selection phase and assigns an order. The scheduler can pick an order depending on @@ -1389,7 +1382,7 @@ def : Pat<(i32 imm:$imm), <a name="selectiondag_future">Future directions for the SelectionDAG</a> </h4> -<div class="doc_text"> +<div> <ol> <li>Optional function-at-a-time selection.</li> @@ -1399,18 +1392,20 @@ def : Pat<(i32 imm:$imm), </div> +</div> + <!-- ======================================================================= --> <h3> <a name="ssamco">SSA-based Machine Code Optimizations</a> </h3> -<div class="doc_text"><p>To Be Written</p></div> +<div><p>To Be Written</p></div> <!-- ======================================================================= --> <h3> <a name="liveintervals">Live Intervals</a> </h3> -<div class="doc_text"> +<div> <p>Live Intervals are the ranges (intervals) where a variable is <i>live</i>. They are used by some <a href="#regalloc">register allocator</a> passes to @@ -1418,14 +1413,12 @@ def : Pat<(i32 imm:$imm), register are live at the same point in the program (i.e., they conflict). When this situation occurs, one virtual register must be <i>spilled</i>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="livevariable_analysis">Live Variable Analysis</a> </h4> -<div class="doc_text"> +<div> <p>The first step in determining the live intervals of variables is to calculate the set of registers that are immediately dead after the instruction (i.e., @@ -1471,7 +1464,7 @@ def : Pat<(i32 imm:$imm), <a name="liveintervals_analysis">Live Intervals Analysis</a> </h4> -<div class="doc_text"> +<div> <p>We now have the information available to perform the live intervals analysis and build the live intervals themselves. We start off by numbering the basic @@ -1486,12 +1479,14 @@ def : Pat<(i32 imm:$imm), </div> +</div> + <!-- ======================================================================= --> <h3> <a name="regalloc">Register Allocation</a> </h3> -<div class="doc_text"> +<div> <p>The <i>Register Allocation problem</i> consists in mapping a program <i>P<sub>v</sub></i>, that can use an unbounded number of virtual registers, @@ -1501,15 +1496,13 @@ def : Pat<(i32 imm:$imm), accommodate all the virtual registers, some of them will have to be mapped into memory. These virtuals are called <i>spilled virtuals</i>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="regAlloc_represent">How registers are represented in LLVM</a> </h4> -<div class="doc_text"> +<div> <p>In LLVM, physical registers are denoted by integer numbers that normally range from 1 to 1023. To see how this numbering is defined for a particular @@ -1622,7 +1615,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, <a name="regAlloc_howTo">Mapping virtual registers to physical registers</a> </h4> -<div class="doc_text"> +<div> <p>There are two ways to map virtual registers to physical registers (or to memory slots). The first way, that we will call <i>direct mapping</i>, is @@ -1672,7 +1665,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, <a name="regAlloc_twoAddr">Handling two address instructions</a> </h4> -<div class="doc_text"> +<div> <p>With very rare exceptions (e.g., function calls), the LLVM machine code instructions are three address instructions. That is, each instruction is @@ -1708,7 +1701,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, <a name="regAlloc_ssaDecon">The SSA deconstruction phase</a> </h4> -<div class="doc_text"> +<div> <p>An important transformation that happens during register allocation is called the <i>SSA Deconstruction Phase</i>. The SSA form simplifies many analyses @@ -1732,7 +1725,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, <a name="regAlloc_fold">Instruction folding</a> </h4> -<div class="doc_text"> +<div> <p><i>Instruction folding</i> is an optimization performed during register allocation that removes unnecessary copy instructions. For instance, a @@ -1769,7 +1762,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, <a name="regAlloc_builtIn">Built in register allocators</a> </h4> -<div class="doc_text"> +<div> <p>The LLVM infrastructure provides the application developer with three different register allocators:</p> @@ -1806,23 +1799,25 @@ $ llc -regalloc=pbqp file.bc -o pbqp.s; </div> +</div> + <!-- ======================================================================= --> <h3> <a name="proepicode">Prolog/Epilog Code Insertion</a> </h3> -<div class="doc_text"><p>To Be Written</p></div> +<div><p>To Be Written</p></div> <!-- ======================================================================= --> <h3> <a name="latemco">Late Machine Code Optimizations</a> </h3> -<div class="doc_text"><p>To Be Written</p></div> +<div><p>To Be Written</p></div> <!-- ======================================================================= --> <h3> <a name="codeemit">Code Emission</a> </h3> -<div class="doc_text"> +<div> <p>The code emission step of code generation is responsible for lowering from the code generator abstractions (like <a @@ -1881,6 +1876,7 @@ to implement an assembler for your target.</p> </div> +</div> <!-- *********************************************************************** --> <h2> @@ -1888,7 +1884,7 @@ to implement an assembler for your target.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Though you're probably reading this because you want to write or maintain a compiler backend, LLVM also fully supports building a native assemblers too. @@ -1897,12 +1893,10 @@ We've tried hard to automate the generation of the assembler from the .td files part of the manual and repetitive data entry can be factored and shared with the compiler.</p> -</div> - <!-- ======================================================================= --> <h3 id="na_instparsing">Instruction Parsing</h3> -<div class="doc_text"><p>To Be Written</p></div> +<div><p>To Be Written</p></div> <!-- ======================================================================= --> @@ -1910,7 +1904,7 @@ compiler.</p> Instruction Alias Processing </h3> -<div class="doc_text"> +<div> <p>Once the instruction is parsed, it enters the MatchInstructionImpl function. The MatchInstructionImpl function performs alias processing and then does actual matching.</p> @@ -1923,12 +1917,10 @@ complex/powerful). Generally you want to use the first alias mechanism that meets the needs of your instruction, because it will allow a more concise description.</p> -</div> - <!-- _______________________________________________________________________ --> <h4>Mnemonic Aliases</h4> -<div class="doc_text"> +<div> <p>The first phase of alias processing is simple instruction mnemonic remapping for classes of instructions which are allowed with two different @@ -1968,7 +1960,7 @@ on the current instruction set.</p> <!-- _______________________________________________________________________ --> <h4>Instruction Aliases</h4> -<div class="doc_text"> +<div> <p>The most general phase of alias processing occurs while matching is happening: it provides new forms for the matcher to match along with a specific @@ -2029,15 +2021,14 @@ subtarget specific.</p> </div> - +</div> <!-- ======================================================================= --> <h3 id="na_matching">Instruction Matching</h3> -<div class="doc_text"><p>To Be Written</p></div> - - +<div><p>To Be Written</p></div> +</div> <!-- *********************************************************************** --> <h2> @@ -2045,20 +2036,18 @@ subtarget specific.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section of the document explains features or design decisions that are specific to the code generator for a particular target. First we start with a table that summarizes what features are supported by each target.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="targetfeatures">Target Feature Matrix</a> </h3> -<div class="doc_text"> +<div> <p>Note that this table does not include the C backend or Cpp backends, since they do not use the target independent code generator infrastructure. It also @@ -2229,12 +2218,10 @@ is the key:</p> </table> -</div> - <!-- _______________________________________________________________________ --> <h4 id="feat_reliable">Is Generally Reliable</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target is considered to be production quality. This indicates that the target has been used as a static compiler to compile large amounts of code by a variety of different people and is in @@ -2244,7 +2231,7 @@ continuous use.</p> <!-- _______________________________________________________________________ --> <h4 id="feat_asmparser">Assembly Parser</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports parsing target specific .s files by implementing the MCAsmParser interface. This is required for llvm-mc to be able to act as a native assembler and is required for inline assembly @@ -2256,7 +2243,7 @@ support in the native .o file writer.</p> <!-- _______________________________________________________________________ --> <h4 id="feat_disassembler">Disassembler</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports the MCDisassembler API for disassembling machine opcode bytes into MCInst's.</p> @@ -2265,7 +2252,7 @@ disassembling machine opcode bytes into MCInst's.</p> <!-- _______________________________________________________________________ --> <h4 id="feat_inlineasm">Inline Asm</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports most popular inline assembly constraints and modifiers.</p> @@ -2277,7 +2264,7 @@ constraints relating to the X86 floating point stack.</p> <!-- _______________________________________________________________________ --> <h4 id="feat_jit">JIT Support</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports the JIT compiler through the ExecutionEngine interface.</p> @@ -2289,7 +2276,7 @@ in ARM codegen mode, but lacks NEON and full Thumb support.</p> <!-- _______________________________________________________________________ --> <h4 id="feat_objectwrite">.o File Writing</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports writing .o files (e.g. MachO, ELF, and/or COFF) files directly from the target. Note that the target also @@ -2305,7 +2292,7 @@ file to a .o file (as is the case for many C compilers).</p> <!-- _______________________________________________________________________ --> <h4 id="feat_tailcall">Tail Calls</h4> -<div class="doc_text"> +<div> <p>This box indicates whether the target supports guaranteed tail calls. These are calls marked "<a href="LangRef.html#i_call">tail</a>" and use the fastcc @@ -2314,15 +2301,14 @@ more more details</a>.</p> </div> - - +</div> <!-- ======================================================================= --> <h3> <a name="tailcallopt">Tail call optimization</a> </h3> -<div class="doc_text"> +<div> <p>Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if:</p> @@ -2388,7 +2374,7 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { <a name="sibcallopt">Sibling call optimization</a> </h3> -<div class="doc_text"> +<div> <p>Sibling call optimization is a restricted form of tail call optimization. Unlike tail call optimization described in the previous section, it can be @@ -2432,20 +2418,18 @@ entry: <a name="x86">The X86 backend</a> </h3> -<div class="doc_text"> +<div> <p>The X86 code generator lives in the <tt>lib/Target/X86</tt> directory. This code generator is capable of targeting a variety of x86-32 and x86-64 processors, and includes support for ISA extensions such as MMX and SSE.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="x86_tt">X86 Target Triples supported</a> </h4> -<div class="doc_text"> +<div> <p>The following are the known target triples that are supported by the X86 backend. This is not an exhaustive list, and it would be useful to add those @@ -2475,7 +2459,7 @@ entry: </h4> -<div class="doc_text"> +<div> <p>The following target-specific calling conventions are known to backend:</p> @@ -2494,7 +2478,7 @@ entry: <a name="x86_memory">Representing X86 addressing modes in MachineInstrs</a> </h4> -<div class="doc_text"> +<div> <p>The x86 has a very flexible way of accessing memory. It is capable of forming memory addresses of the following expression directly in integer @@ -2531,7 +2515,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg <a name="x86_memory">X86 address spaces supported</a> </h4> -<div class="doc_text"> +<div> <p>x86 has a feature which provides the ability to perform loads and stores to different address spaces @@ -2576,7 +2560,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg <a name="x86_names">Instruction naming</a> </h4> -<div class="doc_text"> +<div> <p>An instruction name consists of the base name, a default operand size, and a a character per operand with an optional special size. For example:</p> @@ -2592,25 +2576,25 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory </div> +</div> + <!-- ======================================================================= --> <h3> <a name="ppc">The PowerPC backend</a> </h3> -<div class="doc_text"> +<div> <p>The PowerPC code generator lives in the lib/Target/PowerPC directory. The code generation is retargetable to several variations or <i>subtargets</i> of the PowerPC ISA; including ppc32, ppc64 and altivec.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="ppc_abi">LLVM PowerPC ABI</a> </h4> -<div class="doc_text"> +<div> <p>LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative (PIC) or static addressing for accessing global values, so no TOC @@ -2630,7 +2614,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory <a name="ppc_frame">Frame Layout</a> </h4> -<div class="doc_text"> +<div> <p>The size of a PowerPC frame is usually fixed for the duration of a function's invocation. Since the frame is fixed size, all references @@ -2777,7 +2761,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory <a name="ppc_prolog">Prolog/Epilog</a> </h4> -<div class="doc_text"> +<div> <p>The llvm prolog and epilog are the same as described in the PowerPC ABI, with the following exceptions. Callee saved registers are spilled after the frame @@ -2794,12 +2778,15 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory <a name="ppc_dynamic">Dynamic Allocation</a> </h4> -<div class="doc_text"> +<div> <p><i>TODO - More to come.</i></p> </div> +</div> + +</div> <!-- *********************************************************************** --> <hr> diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index ca31cab..7f92b9a 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -88,7 +88,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document attempts to describe a few coding standards that are being used in the LLVM source tree. Although no coding standards should be regarded as @@ -122,17 +122,21 @@ href="mailto:sabre@nondot.org">Chris</a>.</p> </h2> <!-- *********************************************************************** --> +<div> + <!-- ======================================================================= --> <h3> <a name="sourceformating">Source Code Formatting</a> </h3> +<div> + <!-- _______________________________________________________________________ --> <h4> <a name="scf_commenting">Commenting</a> </h4> -<div class="doc_text"> +<div> <p>Comments are one critical part of readability and maintainability. Everyone knows they should comment, so should you. When writing comments, write them as @@ -141,7 +145,9 @@ etc. Although we all should probably comment our code more than we do, there are a few very critical places that documentation is very useful:</p> -<b>File Headers</b> +<h5>File Headers</h5> + +<div> <p>Every source file should have a header on it that describes the basic purpose of the file. If a file does not have a header, it should not be @@ -184,7 +190,9 @@ Here it's only two lines. If an algorithm is being implemented or something tricky is going on, a reference to the paper where it is published should be included, as well as any notes or "gotchas" in the code to watch out for.</p> -<b>Class overviews</b> +</div> + +<h5>Class overviews</h5> <p>Classes are one fundamental part of a good object oriented design. As such, a class definition should have a comment block that explains what the class is @@ -193,7 +201,9 @@ could figure it out, it's probably safe to leave it out. Naming classes something sane goes a long ways towards avoiding writing documentation.</p> -<b>Method information</b> +<h5>Method information</h5> + +<div> <p>Methods defined in a class (as well as any global functions) should also be documented properly. A quick note about what it does and a description of the @@ -207,12 +217,14 @@ happens: does the method return null? Abort? Format your hard disk?</p> </div> +</div> + <!-- _______________________________________________________________________ --> <h4> <a name="scf_commentformat">Comment Formatting</a> </h4> -<div class="doc_text"> +<div> <p>In general, prefer C++ style (<tt>//</tt>) comments. They take less space, require less typing, don't have nesting problems, etc. There are a few cases @@ -237,7 +249,7 @@ These nest properly and are better behaved in general than C style comments.</p> <a name="scf_includes"><tt>#include</tt> Style</a> </h4> -<div class="doc_text"> +<div> <p>Immediately after the <a href="#scf_commenting">header file comment</a> (and include guards if working on a header file), the <a @@ -277,7 +289,7 @@ implements are defined.</p> <a name="scf_codewidth">Source Code Width</a> </h4> -<div class="doc_text"> +<div> <p>Write your code to fit within 80 columns of text. This helps those of us who like to print out code and look at your code in an xterm without resizing @@ -302,7 +314,7 @@ for debate.</p> <a name="scf_spacestabs">Use Spaces Instead of Tabs</a> </h4> -<div class="doc_text"> +<div> <p>In all cases, prefer spaces to tabs in source files. People have different preferred indentation levels, and different styles of indentation that they @@ -323,7 +335,7 @@ makes for incredible diffs that are absolutely worthless.</p> <a name="scf_indentation">Indent Code Consistently</a> </h4> -<div class="doc_text"> +<div> <p>Okay, in your first year of programming you were told that indentation is important. If you didn't believe and internalize this then, now is the time. @@ -331,19 +343,21 @@ Just do it.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="compilerissues">Compiler Issues</a> </h3> +<div> <!-- _______________________________________________________________________ --> <h4> <a name="ci_warningerrors">Treat Compiler Warnings Like Errors</a> </h4> -<div class="doc_text"> +<div> <p>If your code has compiler warnings in it, something is wrong — you aren't casting values correctly, your have "questionable" constructs in your @@ -397,7 +411,7 @@ be fixed by massaging the code appropriately.</p> <a name="ci_portable_code">Write Portable Code</a> </h4> -<div class="doc_text"> +<div> <p>In almost all cases, it is possible and within reason to write completely portable code. If there are cases where it isn't possible to write portable @@ -415,7 +429,7 @@ libSystem.</p> <h4> <a name="ci_rtti_exceptions">Do not use RTTI or Exceptions</a> </h4> -<div class="doc_text"> +<div> <p>In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. <tt>dynamic_cast<></tt>) or exceptions. These two language features @@ -436,7 +450,7 @@ than <tt>dynamic_cast<></tt>.</p> <h4> <a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a> </h4> -<div class="doc_text"> +<div> <p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost interchangeably. The only difference is when they are used to declare a class: @@ -454,12 +468,17 @@ which case <tt>struct</tt> is allowed.</p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2> <a name="styleissues">Style Issues</a> </h2> <!-- *********************************************************************** --> +<div> <!-- ======================================================================= --> <h3> @@ -467,13 +486,14 @@ which case <tt>struct</tt> is allowed.</p> </h3> <!-- ======================================================================= --> +<div> <!-- _______________________________________________________________________ --> <h4> <a name="hl_module">A Public Header File <b>is</b> a Module</a> </h4> -<div class="doc_text"> +<div> <p>C++ doesn't do too well in the modularity department. There is no real encapsulation or data hiding (unless you use expensive protocol classes), but it @@ -503,7 +523,7 @@ translation unit.</p> <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a> </h4> -<div class="doc_text"> +<div> <p><tt>#include</tt> hurts compile time performance. Don't do it unless you have to, especially in header files.</p> @@ -532,7 +552,7 @@ dependencies that you'll find out about later.</p> <a name="hl_privateheaders">Keep "Internal" Headers Private</a> </h4> -<div class="doc_text"> +<div> <p>Many modules have a complex implementation that causes them to use more than one implementation (<tt>.cpp</tt>) file. It is often tempting to put the @@ -553,7 +573,7 @@ class itself. Just make them private (or protected) and all is well.</p> <a name="hl_earlyexit">Use Early Exits and <tt>continue</tt> to Simplify Code</a> </h4> -<div class="doc_text"> +<div> <p>When reading code, keep in mind how much state and how many previous decisions have to be remembered by the reader to understand a block of code. @@ -662,7 +682,7 @@ can be a big understandability win.</p> <a name="hl_else_after_return">Don't use <tt>else</tt> after a <tt>return</tt></a> </h4> -<div class="doc_text"> +<div> <p>For similar reasons above (reduction of indentation and easier reading), please do not use '<tt>else</tt>' or '<tt>else if</tt>' after something that @@ -745,7 +765,7 @@ track of when reading the code.</p> <a name="hl_predicateloops">Turn Predicate Loops into Predicate Functions</a> </h4> -<div class="doc_text"> +<div> <p>It is very common to write small loops that just compute a boolean value. There are a number of ways that people commonly write these, but an example of @@ -802,6 +822,7 @@ locality.</p> </div> +</div> <!-- ======================================================================= --> <h3> @@ -809,6 +830,7 @@ locality.</p> </h3> <!-- ======================================================================= --> +<div> <!-- _______________________________________________________________________ --> <h4> @@ -817,7 +839,7 @@ locality.</p> </a> </h4> -<div class="doc_text"> +<div> <p>Poorly-chosen names can mislead the reader and cause bugs. We cannot stress enough how important it is to use <em>descriptive</em> names. Pick names that @@ -900,7 +922,7 @@ Vehicle MakeVehicle(VehicleType Type) { <a name="ll_assert">Assert Liberally</a> </h4> -<div class="doc_text"> +<div> <p>Use the "<tt>assert</tt>" macro to its fullest. Check all of your preconditions and assumptions, you never know when a bug (not necessarily even @@ -1003,7 +1025,7 @@ assert(NewToSet && "The value shouldn't be in the set yet"); <a name="ll_ns_std">Do Not Use '<tt>using namespace std</tt>'</a> </h4> -<div class="doc_text"> +<div> <p>In LLVM, we prefer to explicitly prefix all identifiers from the standard namespace with an "<tt>std::</tt>" prefix, rather than rely on @@ -1043,7 +1065,7 @@ use any others.</p> </a> </h4> -<div class="doc_text"> +<div> <p>If a class is defined in a header file and has a v-table (either it has virtual methods or it derives from classes with virtual methods), it must @@ -1059,7 +1081,7 @@ increasing link times.</p> <a name="ll_end">Don't evaluate <tt>end()</tt> every time through a loop</a> </h4> -<div class="doc_text"> +<div> <p>Because C++ doesn't have a standard "<tt>foreach</tt>" loop (though it can be emulated with macros and may be coming in C++'0x) we end up writing a lot of @@ -1121,7 +1143,7 @@ prefer it.</p> <a name="ll_iostream"><tt>#include <iostream></tt> is Forbidden</a> </h4> -<div class="doc_text"> +<div> <p>The use of <tt>#include <iostream></tt> in library files is hereby <b><em>forbidden</em></b>. The primary reason for doing this is to @@ -1156,7 +1178,7 @@ the <tt>llvm::MemoryBuffer</tt> API for reading files.</b></p> <a name="ll_raw_ostream">Use <tt>raw_ostream</tt></a> </h4> -<div class="doc_text"> +<div> <p>LLVM includes a lightweight, simple, and efficient stream implementation in <tt>llvm/Support/raw_ostream.h</tt>, which provides all of the common @@ -1176,7 +1198,7 @@ declarations and constant references to <tt>raw_ostream</tt> instances.</p> <a name="ll_avoidendl">Avoid <tt>std::endl</tt></a> </h4> -<div class="doc_text"> +<div> <p>The <tt>std::endl</tt> modifier, when used with <tt>iostreams</tt> outputs a newline to the output stream specified. In addition to doing this, however, it @@ -1194,6 +1216,7 @@ it's better to use a literal <tt>'\n'</tt>.</p> </div> +</div> <!-- ======================================================================= --> <h3> @@ -1201,6 +1224,8 @@ it's better to use a literal <tt>'\n'</tt>.</p> </h3> <!-- ======================================================================= --> +<div> + <p>This section describes preferred low-level formatting guidelines along with reasoning on why we prefer them.</p> @@ -1209,7 +1234,7 @@ reasoning on why we prefer them.</p> <a name="micro_spaceparen">Spaces Before Parentheses</a> </h4> -<div class="doc_text"> +<div> <p>We prefer to put a space before an open parenthesis only in control flow statements, but not in normal function call expressions and function-like @@ -1267,7 +1292,7 @@ this misinterpretation.</p> <a name="micro_preincrement">Prefer Preincrement</a> </h4> -<div class="doc_text"> +<div> <p>Hard fast rule: Preincrement (<tt>++X</tt>) may be no slower than postincrement (<tt>X++</tt>) and could very well be a lot faster than it. Use @@ -1287,7 +1312,7 @@ get in the habit of always using preincrement, and you won't have a problem.</p> <a name="micro_namespaceindent">Namespace Indentation</a> </h4> -<div class="doc_text"> +<div> <p> In general, we strive to reduce indentation wherever possible. This is useful @@ -1375,7 +1400,7 @@ the contents of the namespace.</p> <a name="micro_anonns">Anonymous Namespaces</a> </h4> -<div class="doc_text"> +<div> <p>After talking about namespaces in general, you may be wondering about anonymous namespaces in particular. @@ -1455,7 +1480,9 @@ namespace just because it was declared there. </div> +</div> +</div> <!-- *********************************************************************** --> <h2> @@ -1463,7 +1490,7 @@ namespace just because it was declared there. </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>A lot of these comments and recommendations have been culled for other sources. Two particularly important books for our work are:</p> diff --git a/docs/CommandGuide/index.html b/docs/CommandGuide/index.html index 98e97ee..b839d3c 100644 --- a/docs/CommandGuide/index.html +++ b/docs/CommandGuide/index.html @@ -11,7 +11,7 @@ LLVM Command Guide </h1> -<div class="doc_text"> +<div> <p>These documents are HTML versions of the <a href="man/man1/">man pages</a> for all of the LLVM tools. These pages describe how to use the LLVM commands @@ -28,7 +28,7 @@ options) arguments to the tool you are interested in.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ul> @@ -85,7 +85,7 @@ options) arguments to the tool you are interested in.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ul> <li><a href="/cmds/llvmgcc.html"><b>llvm-gcc</b></a> - @@ -105,7 +105,7 @@ options) arguments to the tool you are interested in.</p> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ul> @@ -128,7 +128,7 @@ options) arguments to the tool you are interested in.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ul> <li><a href="/cmds/FileCheck.html"><b>FileCheck</b></a> - diff --git a/docs/CommandLine.html b/docs/CommandLine.html index 0bcd382..179e8e6 100644 --- a/docs/CommandLine.html +++ b/docs/CommandLine.html @@ -105,7 +105,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document describes the CommandLine argument processing library. It will show you how to use it, and what it can do. The CommandLine library uses a @@ -189,7 +189,7 @@ href="mailto:sabre@nondot.org">Chris Lattner</a>.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section of the manual runs through a simple CommandLine'ification of a basic compiler tool. This is intended to show you how to jump into using the @@ -321,14 +321,12 @@ OPTIONS: <p>... indicating that an input filename is expected.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="bool">Boolean Arguments</a> </h3> -<div class="doc_text"> +<div> <p>In addition to input and output filenames, we would like the compiler example to support three boolean flags: "<tt>-f</tt>" to force writing binary output to @@ -410,7 +408,7 @@ and <a href="#list">lists</a> of options.</p> <a name="alias">Argument Aliases</a> </h3> -<div class="doc_text"> +<div> <p>So far, the example works well, except for the fact that we need to check the quiet condition like this now:</p> @@ -461,7 +459,7 @@ uses.</p> possibilities</a> </h3> -<div class="doc_text"> +<div> <p>So far we have seen how the CommandLine library handles builtin types like <tt>std::string</tt>, <tt>bool</tt> and <tt>int</tt>, but how does it handle @@ -571,7 +569,7 @@ which is when you would use it.</p> <a name="namedalternatives">Named Alternatives</a> </h3> -<div class="doc_text"> +<div> <p>Another useful argument form is a named alternative style. We shall use this style in our compiler to specify different debug levels that can be used. @@ -633,7 +631,7 @@ that you can choose the form most appropriate for your application.</p> <a name="list">Parsing a list of options</a> </h3> -<div class="doc_text"> +<div> <p>Now that we have the standard run-of-the-mill argument types out of the way, lets get a little wild and crazy. Lets say that we want our optimizer to accept @@ -703,7 +701,7 @@ checking we have to do.</p> <a name="bits">Collecting options as a set of flags</a> </h3> -<div class="doc_text"> +<div> <p>Instead of collecting sets of options in a list, it is also possible to gather information for enum values in a <b>bit vector</b>. The representation used by @@ -762,7 +760,7 @@ href="#list"> <tt>cl::list</tt></a> option.</p> <a name="description">Adding freeform text to help output</a> </h3> -<div class="doc_text"> +<div> <p>As our program grows and becomes more mature, we may decide to put summary information about what it does into the help output. The help output is styled @@ -800,6 +798,7 @@ OPTIONS: </div> +</div> <!-- *********************************************************************** --> <h2> @@ -807,21 +806,19 @@ OPTIONS: </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that you know the basics of how to use the CommandLine library, this section will give you the detailed information you need to tune how command line options work, as well as information on more "advanced" command line option processing capabilities.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="positional">Positional Arguments</a> </h3> -<div class="doc_text"> +<div> <p>Positional arguments are those arguments that are not named, and are not specified with a hyphen. Positional arguments should be used when an option is @@ -854,15 +851,12 @@ that command line options will be ordered according to how they are listed in a are defined in multiple .cpp files. The fix for this problem is simply to define all of your positional arguments in one .cpp file.</p> -</div> - - <!-- _______________________________________________________________________ --> <h4> <a name="--">Specifying positional options with hyphens</a> </h4> -<div class="doc_text"> +<div> <p>Sometimes you may want to specify a value to your positional argument that starts with a hyphen (for example, searching for '<tt>-foo</tt>' in a file). At @@ -898,7 +892,7 @@ can use it like this:</p> <h4> <a name="getPosition">Determining absolute position with getPosition()</a> </h4> -<div class="doc_text"> +<div> <p>Sometimes an option can affect or modify the meaning of another option. For example, consider <tt>gcc</tt>'s <tt>-x LANG</tt> option. This tells <tt>gcc</tt> to ignore the suffix of subsequent positional arguments and force @@ -958,7 +952,7 @@ can use it like this:</p> <a name="cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt> modifier</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::ConsumeAfter</tt> <a href="#formatting">formatting option</a> is used to construct programs that use "interpreter style" option processing. With @@ -1006,12 +1000,14 @@ href="#cl::list">cl::list</a> option.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="storage">Internal vs External Storage</a> </h3> -<div class="doc_text"> +<div> <p>By default, all command line options automatically hold the value that they parse from the command line. This is very convenient in the common case, @@ -1080,7 +1076,7 @@ that <tt>DebugFlag</tt> is automatically set.</p> <a name="attributes">Option Attributes</a> </h3> -<div class="doc_text"> +<div> <p>This section describes the basic attributes that you can specify on options.</p> @@ -1170,7 +1166,7 @@ obviously).</li> <a name="modifiers">Option Modifiers</a> </h3> -<div class="doc_text"> +<div> <p>Option modifiers are the flags and expressions that you pass into the constructors for <tt><a href="#cl::opt">cl::opt</a></tt> and <tt><a @@ -1196,14 +1192,12 @@ category. The CommandLine library specifies defaults for all of these settings that are the most useful in practice and the most common, which mean that you usually shouldn't have to worry about these.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="hiding">Hiding an option from <tt>-help</tt> output</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::NotHidden</tt>, <tt>cl::Hidden</tt>, and <tt>cl::ReallyHidden</tt> modifiers are used to control whether or not an option @@ -1235,7 +1229,7 @@ indicates that the option should not appear in any help output.</li> allowed</a> </h4> -<div class="doc_text"> +<div> <p>This group of options is used to control how many time an option is allowed (or required) to be specified on the command line of your program. Specifying a @@ -1283,7 +1277,7 @@ retained.</p> <a name="valrequired">Controlling whether or not a value must be specified</a> </h4> -<div class="doc_text"> +<div> <p>This group of options is used to control whether or not the option allows a value to be present. In the case of the CommandLine library, a value is either @@ -1332,7 +1326,7 @@ when <a href="#extensionguide">extending the library</a>.</p> <a name="formatting">Controlling other formatting options</a> </h4> -<div class="doc_text"> +<div> <p>The formatting option group is used to specify that the command line option has special abilities and is otherwise different from other command line @@ -1413,7 +1407,7 @@ strategy basically looks like this:</p> <a name="misc">Miscellaneous option modifiers</a> </h4> -<div class="doc_text"> +<div> <p>The miscellaneous option modifiers are the only flags where you can specify more than one flag from the set: they are not mutually exclusive. These flags @@ -1457,7 +1451,7 @@ only makes sense with a <a href="#cl::list">cl::list</a> option.</li> <a name="response">Response files</a> </h4> -<div class="doc_text"> +<div> <p>Some systems, such as certain variants of Microsoft Windows and some older Unices have a relatively low limit on command-line @@ -1474,13 +1468,14 @@ and </div> +</div> <!-- ======================================================================= --> <h3> <a name="toplevel">Top-Level Classes and Functions</a> </h3> -<div class="doc_text"> +<div> <p>Despite all of the built-in flexibility, the CommandLine option library really only consists of one function (<a @@ -1490,15 +1485,13 @@ href="#cl::list"><tt>cl::list</tt></a>, and <a href="#cl::alias"><tt>cl::alias</tt></a>. This section describes these three classes in detail.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="cl::ParseCommandLineOptions">The <tt>cl::ParseCommandLineOptions</tt> function</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::ParseCommandLineOptions</tt> function is designed to be called directly from <tt>main</tt>, and is used to fill in the values of all of the @@ -1519,7 +1512,7 @@ which holds <a href="#description">additional extra text</a> to emit when the function</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::ParseEnvironmentOptions</tt> function has mostly the same effects as <a @@ -1556,7 +1549,7 @@ input.</p> function</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::SetVersionPrinter</tt> function is designed to be called directly from <tt>main</tt> and <i>before</i> @@ -1576,7 +1569,7 @@ called when the <tt>--version</tt> option is given by the user.</p> <a name="cl::opt">The <tt>cl::opt</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::opt</tt> class is the class used to represent scalar command line options, and is the one used most of the time. It is a templated class which @@ -1611,7 +1604,7 @@ href="#customparser">custom parser</a>.</p> <a name="cl::list">The <tt>cl::list</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::list</tt> class is the class used to represent a list of command line options. It too is a templated class which can take up to three @@ -1638,7 +1631,7 @@ be used.</p> <a name="cl::bits">The <tt>cl::bits</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::bits</tt> class is the class used to represent a list of command line options in the form of a bit vector. It is also a templated class which @@ -1663,7 +1656,7 @@ must be of <b>type</b> <tt>unsigned</tt> if external storage is used.</p> <a name="cl::alias">The <tt>cl::alias</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::alias</tt> class is a nontemplated class that is used to form aliases for other arguments.</p> @@ -1686,7 +1679,7 @@ the conversion from string to data.</p> <a name="cl::extrahelp">The <tt>cl::extrahelp</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>cl::extrahelp</tt> class is a nontemplated class that allows extra help text to be printed out for the <tt>-help</tt> option.</p> @@ -1709,12 +1702,14 @@ single <tt>cl::extrahelp</tt> instance.</p> </pre></div> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="builtinparsers">Builtin parsers</a> </h3> -<div class="doc_text"> +<div> <p>Parsers control how the string value taken from the command line is translated into a typed value, suitable for use in a C++ program. By default, @@ -1773,27 +1768,27 @@ exponential notation (ex: <tt>1.7e15</tt>) and properly supports locales. </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="extensionguide">Extension Guide</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Although the CommandLine library has a lot of functionality built into it already (as discussed previously), one of its true strengths lie in its extensibility. This section discusses how the CommandLine library works under the covers and illustrates how to do some simple, common, extensions.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="customparser">Writing a custom parser</a> </h3> -<div class="doc_text"> +<div> <p>One of the simplest and most common extensions is the use of a custom parser. As <a href="#builtinparsers">discussed previously</a>, parsers are the portion @@ -1936,7 +1931,7 @@ tutorial.</p> <a name="explotingexternal">Exploiting external storage</a> </h3> -<div class="doc_text"> +<div> <p>Several of the LLVM libraries define static <tt>cl::opt</tt> instances that will automatically be included in any program that links with that library. This is a feature. However, sometimes it is necessary to know the value of the @@ -1955,12 +1950,14 @@ tutorial.</p> <a name="dynamicopts">Dynamically adding command line options</a> </h3> -<div class="doc_text"> +<div> <p>TODO: fill in this section</p> </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/CompilerWriterInfo.html b/docs/CompilerWriterInfo.html index 6be1b63..d9201fc 100644 --- a/docs/CompilerWriterInfo.html +++ b/docs/CompilerWriterInfo.html @@ -46,10 +46,12 @@ <h2><a name="hw">Hardware</a></h2> <!-- *********************************************************************** --> +<div> + <!-- ======================================================================= --> <h3><a name="alpha">Alpha</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.html">Alpha manuals</a> @@ -60,7 +62,7 @@ href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-libra <!-- ======================================================================= --> <h3><a name="arm">ARM</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://www.arm.com/documentation/">ARM documentation</a> (<a href="http://www.arm.com/documentation/ARMProcessor_Cores/">Processor @@ -72,7 +74,7 @@ Cores</a>)</li> <!-- ======================================================================= --> <h3><a name="ia64">Itanium (ia64)</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium documentation</a> @@ -83,7 +85,7 @@ href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium docu <!-- ======================================================================= --> <h3><a name="mips">MIPS</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary">MIPS @@ -94,10 +96,12 @@ Processor Architecture</a></li> <!-- ======================================================================= --> <h3><a name="ppc">PowerPC</a></h3> +<div> + <!-- _______________________________________________________________________ --> <h4>IBM - Official manuals and docs</h4> -<div class="doc_text"> +<div> <ul> <li><a @@ -131,7 +135,7 @@ PowerPC architecture</a></li> <!-- _______________________________________________________________________ --> <h4>Other documents, collections, notes</h4> -<div class="doc_text"> +<div> <ul> <li><a href="http://penguinppc.org/dev/#library">PowerPC ABI documents</a></li> @@ -143,10 +147,12 @@ branch stubs for powerpc64-linux (from binutils)</a></li> </div> +</div> + <!-- ======================================================================= --> <h3><a name="sparc">SPARC</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://www.sparc.org/resource.htm">SPARC resources</a></li> @@ -158,10 +164,12 @@ branch stubs for powerpc64-linux (from binutils)</a></li> <!-- ======================================================================= --> <h3><a name="x86">X86</a></h3> +<div> + <!-- _______________________________________________________________________ --> <h4>AMD - Official manuals and docs</h4> -<div class="doc_text"> +<div> <ul> <li><a href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html">AMD processor manuals</a></li> @@ -172,7 +180,7 @@ href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.ht <!-- _______________________________________________________________________ --> <h4>Intel - Official manuals and docs</h4> -<div class="doc_text"> +<div> <ul> <li><a href="http://developer.intel.com/design/pentium4/manuals/index_new.htm">IA-32 @@ -186,17 +194,19 @@ Itanium documentation</a></li> <!-- _______________________________________________________________________ --> <h4>Other x86-specific information</h4> -<div class="doc_text"> +<div> <ul> <li><a href="http://www.agner.org/assem/calling_conventions.pdf">Calling conventions for different C++ compilers and operating systems</a></li> </ul> </div> +</div> + <!-- ======================================================================= --> <h3><a name="other">Other relevant lists</a></h3> -<div class="doc_text"> +<div> <ul> <li><a href="http://gcc.gnu.org/readings.html">GCC reading list</a></li> @@ -204,14 +214,18 @@ conventions for different C++ compilers and operating systems</a></li> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="abi">ABI</a></h2> <!-- *********************************************************************** --> +<div> + <!-- ======================================================================= --> <h3><a name="linux">Linux</a></h3> -<div class="doc_text"> +<div> <ol> <li><a href="http://www.linuxbase.org/spec/ELF/ppc64/">PowerPC 64-bit ELF ABI Supplement</a></li> @@ -221,7 +235,7 @@ Supplement</a></li> <!-- ======================================================================= --> <h3><a name="osx">OS X</a></h3> -<div class="doc_text"> +<div> <ol> <li><a href="http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html">Mach-O @@ -232,6 +246,8 @@ ABI</a></li> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="misc">Miscellaneous resources</a></h2> <!-- *********************************************************************** --> diff --git a/docs/DebuggingJITedCode.html b/docs/DebuggingJITedCode.html index f23fdf6..3911ea7 100644 --- a/docs/DebuggingJITedCode.html +++ b/docs/DebuggingJITedCode.html @@ -17,7 +17,7 @@ <!--=========================================================================--> <h2><a name="example">Example usage</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>In order to debug code JITed by LLVM, you need GDB 7.0 or newer, which is available on most modern distributions of Linux. The version of GDB that Apple @@ -98,7 +98,7 @@ function names. <!--=========================================================================--> <h2><a name="background">Background</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>Without special runtime support, debugging dynamically generated code with GDB (as well as most debuggers) can be quite painful. Debuggers generally read diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 5d6c2d8..fee2838 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -36,7 +36,7 @@ <!--=========================================================================--> <h2><a name="introduction">Introduction</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>This document contains the LLVM Developer Policy which defines the project's policy towards developers and their contributions. The intent of this policy is to eliminate miscommunication, rework, and confusion that might arise from @@ -65,18 +65,17 @@ <!--=========================================================================--> <h2><a name="policies">Developer Policies</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>This section contains policies that pertain to frequent LLVM developers. We always welcome <a href="#patches">one-off patches</a> from people who do not routinely contribute to LLVM, but we expect more from frequent contributors to keep the system as efficient as possible for everyone. Frequent LLVM contributors are expected to meet the following requirements in order for LLVM to maintain a high standard of quality.<p> -</div> <!-- _______________________________________________________________________ --> <h3><a name="informed">Stay Informed</a></h3> -<div class="doc_text"> +<div> <p>Developers should stay informed by reading at least the "dev" mailing list for the projects you are interested in, such as <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a> for @@ -104,7 +103,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="patches">Making a Patch</a></h3> -<div class="doc_text"> +<div> <p>When making a patch for review, the goal is to make it as easy for the reviewer to read it as possible. As such, we recommend that you:</p> @@ -143,7 +142,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="reviews">Code Reviews</a></h3> -<div class="doc_text"> +<div> <p>LLVM has a code review policy. Code review is one way to increase the quality of software. We generally follow these policies:</p> @@ -175,7 +174,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="owners">Code Owners</a></h3> -<div class="doc_text"> +<div> <p>The LLVM Project relies on two features of its process to maintain rapid development in addition to the high quality of its source base: the @@ -226,7 +225,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="testcases">Test Cases</a></h3> -<div class="doc_text"> +<div> <p>Developers are required to create test cases for any bugs fixed and any new features added. Some tips for getting your testcase approved:</p> @@ -259,7 +258,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="quality">Quality</a></h3> -<div class="doc_text"> +<div> <p>The minimum quality standards that any change must satisfy before being committed to the main development branch are:</p> @@ -319,7 +318,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="commitaccess">Obtaining Commit Access</a></h3> -<div class="doc_text"> +<div> <p>We grant commit access to contributors with a track record of submitting high quality patches. If you would like commit access, please send an email to @@ -381,7 +380,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="newwork">Making a Major Change</a></h3> -<div class="doc_text"> +<div> <p>When a developer begins a major new project with the aim of contributing it back to LLVM, s/he should inform the community with an email to the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a> @@ -410,7 +409,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="incremental">Incremental Development</a></h3> -<div class="doc_text"> +<div> <p>In the LLVM project, we do all significant changes as a series of incremental patches. We have a strong dislike for huge changes or long-term development branches. Long-term development branches have a number of drawbacks:</p> @@ -471,7 +470,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="attribution">Attribution of Changes</a></h3> -<div class="doc_text"> +<div> <p>We believe in correct attribution of contributions to their contributors. However, we do not want the source code to be littered with random attributions "this code written by J. Random Hacker" (this is noisy and @@ -483,13 +482,15 @@ <p>Overall, please do not add contributor names to the source code.</p> </div> +</div> + <!--=========================================================================--> <h2> <a name="clp">Copyright, License, and Patents</a> </h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>This section addresses the issues of copyright, license and patents for the LLVM project. Currently, the University of Illinois is the LLVM copyright holder and the terms of its license to LLVM users and developers is the @@ -501,11 +502,10 @@ legal matters but does not provide legal advice. We are not lawyers, please seek legal counsel from an attorney.</p> </div> -</div> <!-- _______________________________________________________________________ --> <h3><a name="copyright">Copyright</a></h3> -<div class="doc_text"> +<div> <p>The LLVM project does not require copyright assignments, which means that the copyright for the code in the project is held by its respective contributors @@ -528,7 +528,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="license">License</a></h3> -<div class="doc_text"> +<div> <p>We intend to keep LLVM perpetually open source and to use a liberal open source license. All of the code in LLVM is available under the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">University of @@ -583,7 +583,7 @@ <!-- _______________________________________________________________________ --> <h3><a name="patents">Patents</a></h3> -<div class="doc_text"> +<div> <p>To the best of our knowledge, LLVM does not infringe on any patents (we have actually removed code from LLVM in the past that was found to infringe). Having code in LLVM that infringes on patents would violate an important goal @@ -599,6 +599,8 @@ details.</p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index 09e0946..0d3ea1b 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -61,7 +61,7 @@ <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is the central repository for all information pertaining to exception handling in LLVM. It describes the format that LLVM exception @@ -70,14 +70,12 @@ provides specific examples of what exception handling information is used for in C/C++.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="itanium">Itanium ABI Zero-cost Exception Handling</a> </h3> -<div class="doc_text"> +<div> <p>Exception handling for most programming languages is designed to recover from conditions that rarely occur during general use of an application. To that @@ -110,7 +108,7 @@ <a name="sjlj">Setjmp/Longjmp Exception Handling</a> </h3> -<div class="doc_text"> +<div> <p>Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics <a href="#llvm_eh_sjlj_setjmp"><tt>llvm.eh.sjlj.setjmp</tt></a> and @@ -142,7 +140,7 @@ <a name="overview">Overview</a> </h3> -<div class="doc_text"> +<div> <p>When an exception is thrown in LLVM code, the runtime does its best to find a handler suited to processing the circumstance.</p> @@ -185,12 +183,14 @@ </div> +</div> + <!-- ======================================================================= --> <h2> <a name="codegen">LLVM Code Generation</a> </h2> -<div class="doc_text"> +<div> <p>At the time of this writing, only C++ exception handling support is available in LLVM. So the remainder of this document will be somewhat C++-centric.</p> @@ -200,14 +200,12 @@ we will describe the implementation of LLVM exception handling in terms of C++ examples.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="throw">Throw</a> </h3> -<div class="doc_text"> +<div> <p>Languages that support exception handling typically provide a <tt>throw</tt> operation to initiate the exception process. Internally, a throw operation @@ -229,7 +227,7 @@ <a name="try_catch">Try/Catch</a> </h3> -<div class="doc_text"> +<div> <p>A call within the scope of a <i>try</i> statement can potentially raise an exception. In those circumstances, the LLVM C++ front-end replaces the call @@ -317,7 +315,7 @@ <a name="cleanups">Cleanups</a> </h3> -<div class="doc_text"> +<div> <p>To handle destructors and cleanups in <tt>try</tt> code, control may not run directly from a landing pad to the first catch. Control may actually flow @@ -336,7 +334,7 @@ <a name="throw_filters">Throw Filters</a> </h3> -<div class="doc_text"> +<div> <p>C++ allows the specification of which exception types can be thrown from a function. To represent this a top level landing pad may exist to filter out @@ -363,7 +361,7 @@ <a name="restrictions">Restrictions</a> </h3> -<div class="doc_text"> +<div> <p>The semantics of the invoke instruction require that any exception that unwinds through an invoke call should result in a branch to the invoke's @@ -384,25 +382,25 @@ </div> +</div> + <!-- ======================================================================= --> <h2> <a name="format_common_intrinsics">Exception Handling Intrinsics</a> </h2> -<div class="doc_text"> +<div> <p>LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to provide exception handling information at various points in generated code.</p> -</div> - <!-- ======================================================================= --> <h4> <a name="llvm_eh_exception">llvm.eh.exception</a> </h4> -<div class="doc_text"> +<div> <pre> i8* %<a href="#llvm_eh_exception">llvm.eh.exception</a>() @@ -417,7 +415,7 @@ <a name="llvm_eh_selector">llvm.eh.selector</a> </h4> -<div class="doc_text"> +<div> <pre> i32 %<a href="#llvm_eh_selector">llvm.eh.selector</a>(i8*, i8*, ...) @@ -449,7 +447,7 @@ <a name="llvm_eh_typeid_for">llvm.eh.typeid.for</a> </h4> -<div class="doc_text"> +<div> <pre> i32 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for</a>(i8*) @@ -467,7 +465,7 @@ <a name="llvm_eh_sjlj_setjmp">llvm.eh.sjlj.setjmp</a> </h4> -<div class="doc_text"> +<div> <pre> i32 %<a href="#llvm_eh_sjlj_setjmp">llvm.eh.sjlj.setjmp</a>(i8*) @@ -496,7 +494,7 @@ <a name="llvm_eh_sjlj_longjmp">llvm.eh.sjlj.longjmp</a> </h4> -<div class="doc_text"> +<div> <pre> void %<a href="#llvm_eh_sjlj_longjmp">llvm.eh.sjlj.setjmp</a>(i8*) @@ -516,7 +514,7 @@ <a name="llvm_eh_sjlj_lsda">llvm.eh.sjlj.lsda</a> </h4> -<div class="doc_text"> +<div> <pre> i8* %<a href="#llvm_eh_sjlj_lsda">llvm.eh.sjlj.lsda</a>() @@ -535,7 +533,7 @@ <a name="llvm_eh_sjlj_callsite">llvm.eh.sjlj.callsite</a> </h4> -<div class="doc_text"> +<div> <pre> void %<a href="#llvm_eh_sjlj_callsite">llvm.eh.sjlj.callsite</a>(i32) @@ -553,7 +551,7 @@ <a name="llvm_eh_sjlj_dispatchsetup">llvm.eh.sjlj.dispatchsetup</a> </h4> -<div class="doc_text"> +<div> <pre> void %<a href="#llvm_eh_sjlj_dispatchsetup">llvm.eh.sjlj.dispatchsetup</a>(i32) @@ -565,24 +563,24 @@ </div> +</div> + <!-- ======================================================================= --> <h2> <a name="asm">Asm Table Formats</a> </h2> -<div class="doc_text"> +<div> <p>There are two tables that are used by the exception handling runtime to determine which actions should take place when an exception is thrown.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="unwind_tables">Exception Handling Frame</a> </h3> -<div class="doc_text"> +<div> <p>An exception handling frame <tt>eh_frame</tt> is very similar to the unwind frame used by dwarf debug info. The frame contains all the information @@ -600,7 +598,7 @@ <a name="exception_tables">Exception Tables</a> </h3> -<div class="doc_text"> +<div> <p>An exception table contains information about what actions to take when an exception is thrown in a particular part of a function's code. There is one @@ -611,12 +609,14 @@ </div> +</div> + <!-- ======================================================================= --> <h2> <a name="todo">ToDo</a> </h2> -<div class="doc_text"> +<div> <ol> diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index 7f77bb7..b720911 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -36,7 +36,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>During the course of using LLVM, you may wish to customize it for your research project or for experimentation. At this point, you may realize that @@ -73,7 +73,7 @@ effort by doing so.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Adding a new intrinsic function to LLVM is much easier than adding a new instruction. Almost all extensions to LLVM should start as an intrinsic @@ -135,7 +135,7 @@ support for it. Generally you must do the following steps:</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>As with intrinsics, adding a new SelectionDAG node to LLVM is much easier than adding a new instruction. New nodes are often added to help represent @@ -225,7 +225,7 @@ complicated behavior in a single node (rotate).</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><span class="doc_warning">WARNING: adding instructions changes the bitcode format, and it will take some effort to maintain compatibility with @@ -282,20 +282,18 @@ to understand this new instruction.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><span class="doc_warning">WARNING: adding new types changes the bitcode format, and will break compatibility with currently-existing LLVM installations.</span> Only add new types if it is absolutely necessary.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="fund_type">Adding a fundamental type</a> </h3> -<div class="doc_text"> +<div> <ol> @@ -321,7 +319,7 @@ installations.</span> Only add new types if it is absolutely necessary.</p> <a name="derived_type">Adding a derived type</a> </h3> -<div class="doc_text"> +<div> <ol> <li><tt>llvm/include/llvm/Type.h</tt>: @@ -373,6 +371,8 @@ void calcTypeName(const Type *Ty, </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/GCCFEBuildInstrs.html b/docs/GCCFEBuildInstrs.html index f3c9459..6eb409b 100644 --- a/docs/GCCFEBuildInstrs.html +++ b/docs/GCCFEBuildInstrs.html @@ -27,7 +27,7 @@ <h2><a name="instructions">Building llvm-gcc from Source</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section describes how to acquire and build llvm-gcc 4.2, which is based on the GCC 4.2.1 front-end. Supported languages are Ada, C, C++, Fortran, @@ -70,7 +70,7 @@ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk <i>dst-directory</i> <h2><a name="ada">Building the Ada front-end</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Building with support for Ada amounts to following the directions in the top-level <tt>README.LLVM</tt> file, adding ",ada" to EXTRALANGS, for example: <tt>EXTRALANGS=,ada</tt></p> @@ -236,7 +236,7 @@ make install <h2><a name="fortran">Building the Fortran front-end</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>To build with support for Fortran, follow the directions in the top-level <tt>README.LLVM</tt> file, adding ",fortran" to EXTRALANGS, for example:</p> @@ -250,7 +250,7 @@ EXTRALANGS=,fortran <h2><a name="license">License Information</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The LLVM GCC frontend is licensed to you under the GNU General Public License and the GNU Lesser General Public License. Please see the files COPYING and diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index aa83a2d..761e1d0 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -84,7 +84,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Garbage collection is a widely used technique that frees the programmer from having to know the lifetimes of heap objects, making software easier to produce @@ -124,14 +124,12 @@ techniques dominates any low-level losses.</p> <p>This document describes the mechanisms and interfaces provided by LLVM to support accurate garbage collection.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="feature">Goals and non-goals</a> </h3> -<div class="doc_text"> +<div> <p>LLVM's intermediate representation provides <a href="#intrinsics">garbage collection intrinsics</a> that offer support for a broad class of @@ -198,13 +196,15 @@ compiler matures.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="quickstart">Getting started</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Using a GC with LLVM implies many things, for example:</p> @@ -246,14 +246,12 @@ compiler matures.</p> includes a highly portable, built-in ShadowStack code generator. It is compiled into <tt>llc</tt> and works even with the interpreter and C backends.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="quickstart-compiler">In your compiler</a> </h3> -<div class="doc_text"> +<div> <p>To turn the shadow stack on for your functions, first call:</p> @@ -280,7 +278,7 @@ switching to a more advanced GC.</p> <a name="quickstart-runtime">In your runtime</a> </h3> -<div class="doc_text"> +<div> <p>The shadow stack doesn't imply a memory allocation algorithm. A semispace collector or building atop <tt>malloc</tt> are great places to start, and can @@ -347,7 +345,7 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) { <a name="shadow-stack">About the shadow stack</a> </h3> -<div class="doc_text"> +<div> <p>Unlike many GC algorithms which rely on a cooperative code generator to compile stack maps, this algorithm carefully maintains a linked list of stack @@ -372,13 +370,15 @@ in order to improve performance.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="core">IR features</a><a name="intrinsics"></a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section describes the garbage collection facilities provided by the <a href="LangRef.html">LLVM intermediate representation</a>. The exact behavior @@ -390,8 +390,6 @@ intended to be a complete interface to any garbage collector. A program will need to interface with the GC library using the facilities provided by that program.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="gcattr">Specifying GC code generation: <tt>gc "..."</tt></a> @@ -401,7 +399,7 @@ program.</p> define <i>ty</i> @<i>name</i>(...) <span style="text-decoration: underline">gc "<i>name</i>"</span> { ... </tt></div> -<div class="doc_text"> +<div> <p>The <tt>gc</tt> function attribute is used to specify the desired GC style to the compiler. Its programmatic equivalent is the <tt>setGC</tt> method of @@ -426,7 +424,7 @@ programs that use different garbage collection algorithms (or none at all).</p> void @llvm.gcroot(i8** %ptrloc, i8* %metadata) </tt></div> -<div class="doc_text"> +<div> <p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM that a stack variable references an object on the heap and is to be tracked for garbage @@ -498,7 +496,7 @@ CodeBlock: <a name="barriers">Reading and writing references in the heap</a> </h3> -<div class="doc_text"> +<div> <p>Some collectors need to be informed when the mutator (the program that needs garbage collection) either reads a pointer from or writes a pointer to a field @@ -534,8 +532,6 @@ require the corresponding barrier. Such a GC plugin will replace the intrinsic calls with the corresponding <tt>load</tt> or <tt>store</tt> instruction if they are used.</p> -</div> - <!-- ======================================================================= --> <h4> <a name="gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a> @@ -545,7 +541,7 @@ are used.</p> void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived) </tt></div> -<div class="doc_text"> +<div> <p>For write barriers, LLVM provides the <tt>llvm.gcwrite</tt> intrinsic function. It has exactly the same semantics as a non-volatile <tt>store</tt> to @@ -567,7 +563,7 @@ implement reference counting.</p> i8* @llvm.gcread(i8* %object, i8** %derived)<br> </tt></div> -<div class="doc_text"> +<div> <p>For read barriers, LLVM provides the <tt>llvm.gcread</tt> intrinsic function. It has exactly the same semantics as a non-volatile <tt>load</tt> from the @@ -580,13 +576,17 @@ writes.</p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2> <a name="plugin">Implementing a collector plugin</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>User code specifies which GC code generation to use with the <tt>gc</tt> function attribute or, equivalently, with the <tt>setGC</tt> method of @@ -666,14 +666,12 @@ $ llvm-as < sample.ll | llc -load=MyGC.so</pre></blockquote> <p>It is also possible to statically link the collector plugin into tools, such as a language-specific compiler front-end.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="collector-algos">Overview of available features</a> </h3> -<div class="doc_text"> +<div> <p><tt>GCStrategy</tt> provides a range of features through which a plugin may do useful work. Some of these are callbacks, some are algorithms that can @@ -962,7 +960,7 @@ interest.</p> <a name="stack-map">Computing stack maps</a> </h3> -<div class="doc_text"> +<div> <p>LLVM automatically computes a stack map. One of the most important features of a <tt>GCStrategy</tt> is to compile this information into the executable in @@ -1018,7 +1016,7 @@ for collector plugins which implement reference counting or a shadow stack.</p> <a name="init-roots">Initializing roots to null: <tt>InitRoots</tt></a> </h3> -<div class="doc_text"> +<div> <blockquote><pre >MyGC::MyGC() { @@ -1044,7 +1042,7 @@ this feature should be used by all GC plugins. It is enabled by default.</p> <tt>CustomReadBarriers</tt>, and <tt>CustomWriteBarriers</tt></a> </h3> -<div class="doc_text"> +<div> <p>For GCs which use barriers or unusual treatment of stack roots, these flags allow the collector to perform arbitrary transformations of the LLVM @@ -1133,7 +1131,7 @@ bool MyGC::performCustomLowering(Function &F) { <a name="safe-points">Generating safe points: <tt>NeededSafePoints</tt></a> </h3> -<div class="doc_text"> +<div> <p>LLVM can compute four kinds of safe points:</p> @@ -1197,7 +1195,7 @@ safe point (because only the topmost function has been patched).</p> <a name="assembly">Emitting assembly code: <tt>GCMetadataPrinter</tt></a> </h3> -<div class="doc_text"> +<div> <p>LLVM allows a plugin to print arbitrary assembly code before and after the rest of a module's assembly code. At the end of the module, the GC can compile @@ -1341,6 +1339,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP, </div> +</div> <!-- *********************************************************************** --> <h2> @@ -1348,7 +1347,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP, </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><a name="appel89">[Appel89]</a> Runtime Tags Aren't Necessary. Andrew W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.</p> diff --git a/docs/GetElementPtr.html b/docs/GetElementPtr.html index d1c5b6c..2c32a9e 100644 --- a/docs/GetElementPtr.html +++ b/docs/GetElementPtr.html @@ -61,7 +61,7 @@ <h2><a name="intro">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document seeks to dispel the mystery and confusion surrounding LLVM's <a href="LangRef.html#i_getelementptr">GetElementPtr</a> (GEP) instruction. Questions about the wily GEP instruction are @@ -74,19 +74,18 @@ <!-- *********************************************************************** --> <h2><a name="addresses">Address Computation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>When people are first confronted with the GEP instruction, they tend to relate it to known concepts from other programming paradigms, most notably C array indexing and field selection. GEP closely resembles C array indexing and field selection, however it's is a little different and this leads to the following questions.</p> -</div> <!-- *********************************************************************** --> <h3> <a name="firstptr">What is the first index of the GEP instruction?</a> </h3> -<div class="doc_text"> +<div> <p>Quick answer: The index stepping through the first operand.</p> <p>The confusion with the first index usually arises from thinking about the GetElementPtr instruction as if it was a C index operator. They aren't the @@ -209,7 +208,7 @@ idx3 = (char*) &MyVar + 8 <a name="extra_index">Why is the extra 0 index required?</a> </h3> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Quick answer: there are no superfluous indices.</p> <p>This question arises most often when the GEP instruction is applied to a global variable which is always a pointer type. For example, consider @@ -250,7 +249,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="deref">What is dereferenced by GEP?</a> </h3> -<div class="doc_text"> +<div> <p>Quick answer: nothing.</p> <p>The GetElementPtr instruction dereferences nothing. That is, it doesn't access memory in any way. That's what the Load and Store instructions are for. @@ -305,7 +304,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="lead0">Why don't GEP x,0,0,1 and GEP x,1 alias?</a> </h3> -<div class="doc_text"> +<div> <p>Quick Answer: They compute different address locations.</p> <p>If you look at the first indices in these GEP instructions you find that they are different (0 and 1), therefore the address @@ -334,7 +333,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="trail0">Why do GEP x,1,0,0 and GEP x,1 alias?</a> </h3> -<div class="doc_text"> +<div> <p>Quick Answer: They compute the same address location.</p> <p>These two GEP instructions will compute the same address because indexing through the 0th element does not change the address. However, it does change @@ -358,7 +357,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="vectors">Can GEP index into vector elements?</a> </h3> -<div class="doc_text"> +<div> <p>This hasn't always been forcefully disallowed, though it's not recommended. It leads to awkward special cases in the optimizers, and fundamental inconsistency in the IR. In the future, it will probably be outright @@ -371,7 +370,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="addrspace">What effect do address spaces have on GEPs?</a> </h3> -<div class="doc_text"> +<div> <p>None, except that the address space qualifier on the first operand pointer type always matches the address space qualifier on the result type.</p> @@ -384,7 +383,7 @@ idx3 = (char*) &MyVar + 8 How is GEP different from ptrtoint, arithmetic, and inttoptr? </a> </h3> -<div class="doc_text"> +<div> <p>It's very similar; there are only subtle differences.</p> <p>With ptrtoint, you have to pick an integer type. One approach is to pick i64; @@ -416,7 +415,7 @@ idx3 = (char*) &MyVar + 8 How do I do this? </a> </h3> -<div class="doc_text"> +<div> <p>You don't. The integer computation implied by a GEP is target-independent. Typically what you'll need to do is make your backend pattern-match expressions trees involving ADD, MUL, etc., which are what GEP is lowered @@ -437,7 +436,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="vla">How does VLA addressing work with GEPs?</a> </h3> -<div class="doc_text"> +<div> <p>GEPs don't natively support VLAs. LLVM's type system is entirely static, and GEP address computations are guided by an LLVM type.</p> @@ -453,16 +452,18 @@ idx3 = (char*) &MyVar + 8 VLA and non-VLA indexing in the same manner.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="rules">Rules</a></h2> <!-- *********************************************************************** --> - +<div> <!-- *********************************************************************** --> <h3> <a name="bounds">What happens if an array index is out of bounds?</a> </h3> -<div class="doc_text"> +<div> <p>There are two senses in which an array index can be out of bounds.</p> <p>First, there's the array type which comes from the (static) type of @@ -504,7 +505,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="negative">Can array indices be negative?</a> </h3> -<div class="doc_text"> +<div> <p>Yes. This is basically a special case of array indices being out of bounds.</p> @@ -514,7 +515,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="compare">Can I compare two values computed with GEPs?</a> </h3> -<div class="doc_text"> +<div> <p>Yes. If both addresses are within the same allocated object, or one-past-the-end, you'll get the comparison result you expect. If either is outside of it, integer arithmetic wrapping may occur, so the @@ -529,7 +530,7 @@ idx3 = (char*) &MyVar + 8 the underlying object? </a> </h3> -<div class="doc_text"> +<div> <p>Yes. There are no restrictions on bitcasting a pointer value to an arbitrary pointer type. The types in a GEP serve only to define the parameters for the underlying integer computation. They need not correspond with the actual @@ -548,7 +549,7 @@ idx3 = (char*) &MyVar + 8 Can I cast an object's address to integer and add it to null? </a> </h3> -<div class="doc_text"> +<div> <p>You can compute an address that way, but if you use GEP to do the add, you can't use that pointer to actually access the object, unless the object is managed outside of LLVM.</p> @@ -574,7 +575,7 @@ idx3 = (char*) &MyVar + 8 that value to one address to compute the other address? </a> </h3> -<div class="doc_text"> +<div> <p>As with arithmetic on null, You can use GEP to compute an address that way, but you can't use that pointer to actually access the object if you do, unless the object is managed outside of LLVM.</p> @@ -588,7 +589,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="tbaa">Can I do type-based alias analysis on LLVM IR?</a> </h3> -<div class="doc_text"> +<div> <p>You can't do type-based alias analysis using LLVM's built-in type system, because LLVM has no restrictions on mixing types in addressing, loads or stores.</p> @@ -605,7 +606,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="overflow">What happens if a GEP computation overflows?</a> </h3> -<div class="doc_text"> +<div> <p>If the GEP lacks the <tt>inbounds</tt> keyword, the value is the result from evaluating the implied two's complement integer computation. However, since there's no guarantee of where an object will be allocated in the @@ -637,7 +638,7 @@ idx3 = (char*) &MyVar + 8 How can I tell if my front-end is following the rules? </a> </h3> -<div class="doc_text"> +<div> <p>There is currently no checker for the getelementptr rules. Currently, the only way to do this is to manually check each place in your front-end where GetElementPtr operators are created.</p> @@ -650,16 +651,18 @@ idx3 = (char*) &MyVar + 8 </div> +</div> + <!-- *********************************************************************** --> <h2><a name="rationale">Rationale</a></h2> <!-- *********************************************************************** --> - +<div> <!-- *********************************************************************** --> <h3> <a name="goals">Why is GEP designed this way?</a> </h3> -<div class="doc_text"> +<div> <p>The design of GEP has the following goals, in rough unofficial order of priority:</p> <ul> @@ -681,7 +684,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="i32">Why do struct member indices always use i32?</a> </h3> -<div class="doc_text"> +<div> <p>The specific type i32 is probably just a historical artifact, however it's wide enough for all practical purposes, so there's been no need to change it. It doesn't necessarily imply i32 address arithmetic; it's just an identifier @@ -696,7 +699,7 @@ idx3 = (char*) &MyVar + 8 <h3> <a name="uglygep">What's an uglygep?</a> </h3> -<div class="doc_text"> +<div> <p>Some LLVM optimizers operate on GEPs by internally lowering them into more primitive integer expressions, which allows them to be combined with other integer expressions and/or split into multiple separate @@ -713,11 +716,13 @@ idx3 = (char*) &MyVar + 8 </div> +</div> + <!-- *********************************************************************** --> <h2><a name="summary">Summary</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>In summary, here's some things to always remember about the GetElementPtr instruction:</p> <ol> diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html index 2bca7ae..7360893 100644 --- a/docs/GettingStarted.html +++ b/docs/GettingStarted.html @@ -75,7 +75,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to LLVM! In order to get started, you first need to know some basic information.</p> @@ -107,7 +107,7 @@ and performance. </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Here's the short story for getting up and running quickly with LLVM:</p> @@ -196,20 +196,18 @@ Layout</a> to learn about the layout of the source code tree.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Before you begin to use the LLVM system, review the requirements given below. This may save you some trouble by knowing ahead of time what hardware and software you will need.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="hardware">Hardware</a> </h3> -<div class="doc_text"> +<div> <p>LLVM is known to work on the following platforms:</p> @@ -373,7 +371,7 @@ href="GCCFEBuildInstrs.html">try to compile it</a> on your platform.</p> <h3> <a name="software">Software</a> </h3> -<div class="doc_text"> +<div> <p>Compiling LLVM requires that you have several software packages installed. The table below lists those required packages. The Package column is the usual name for the software package that LLVM depends on. The Version @@ -514,7 +512,7 @@ href="GCCFEBuildInstrs.html">try to compile it</a> on your platform.</p> <a name="brokengcc">Broken versions of GCC and other tools</a> </h3> -<div class="doc_text"> +<div> <p>LLVM is very demanding of the host C++ compiler, and as such tends to expose bugs in the compiler. In particular, several versions of GCC crash when trying @@ -607,7 +605,7 @@ upgrading to a newer version of Gold.</p> </div> - +</div> <!-- *********************************************************************** --> <h2> @@ -615,7 +613,7 @@ upgrading to a newer version of Gold.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The remainder of this guide is meant to get you up and running with LLVM and to give you some basic information about the LLVM environment.</p> @@ -625,14 +623,13 @@ href="#layout">general layout</a> of the the LLVM source tree, a <a href="#tutorial">simple example</a> using the LLVM tool chain, and <a href="#links">links</a> to find more information about LLVM or to get help via e-mail.</p> -</div> <!-- ======================================================================= --> <h3> <a name="terminology">Terminology and Notation</a> </h3> -<div class="doc_text"> +<div> <p>Throughout this manual, the following names are used to denote paths specific to the local system and working environment. <i>These are not @@ -669,7 +666,7 @@ All these paths are absolute:</p> <a name="environment">Setting Up Your Environment</a> </h3> -<div class="doc_text"> +<div> <p> In order to compile and use LLVM, you may need to set some environment @@ -692,7 +689,7 @@ variables. <a name="unpack">Unpacking the LLVM Archives</a> </h3> -<div class="doc_text"> +<div> <p> If you have the LLVM distribution, you will need to unpack it before you @@ -726,7 +723,7 @@ compressed with the gzip program. <a name="checkout">Checkout LLVM from Subversion</a> </h3> -<div class="doc_text"> +<div> <p>If you have access to our Subversion repository, you can get a fresh copy of the entire source code. All you need to do is check it out from Subversion as @@ -797,7 +794,7 @@ instructions</a> to successfully get and build the LLVM GCC front-end.</p> <a name="git_mirror">GIT mirror</a> </h3> -<div class="doc_text"> +<div> <p>GIT mirrors are available for a number of LLVM subprojects. These mirrors sync automatically with each Subversion commit and contain all necessary @@ -816,7 +813,7 @@ instructions</a> to successfully get and build the LLVM GCC front-end.</p> <a name="installcf">Install the GCC Front End</a> </h3> -<div class="doc_text"> +<div> <p>Before configuring and compiling the LLVM suite (or if you want to use just the LLVM GCC front end) you can optionally extract the front end from the binary distribution. @@ -886,7 +883,7 @@ please let us know how you would like to see things improved by dropping us a no <a name="config">Local LLVM Configuration</a> </h3> -<div class="doc_text"> +<div> <p>Once checked out from the Subversion repository, the LLVM suite source code must be @@ -1008,7 +1005,7 @@ script to configure the build system:</p> <a name="compile">Compiling the LLVM Suite Source Code</a> </h3> -<div class="doc_text"> +<div> <p>Once you have configured LLVM, you can build it. There are three types of builds:</p> @@ -1142,7 +1139,7 @@ that directory that is out of date.</p> <a name="cross-compile">Cross-Compiling LLVM</a> </h3> -<div class="doc_text"> +<div> <p>It is possible to cross-compile LLVM itself. That is, you can create LLVM executables and libraries to be hosted on a platform different from the platform where they are build (a Canadian Cross build). To configure a @@ -1160,7 +1157,7 @@ that directory that is out of date.</p> <a name="objfiles">The Location of LLVM Object Files</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM build system is capable of sharing a single LLVM source tree among several LLVM builds. Hence, it is possible to build LLVM for several different @@ -1220,7 +1217,7 @@ named after the build type:</p> <a name="optionalconfig">Optional Configuration Items</a> </h3> -<div class="doc_text"> +<div> <p> If you're running on a Linux system that supports the "<a @@ -1251,27 +1248,27 @@ $ sudo update-binfmts --install llvm /path/to/lli --magic 'BC' </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="layout">Program Layout</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>One useful source of information about the LLVM source base is the LLVM <a href="http://www.doxygen.org/">doxygen</a> documentation available at <tt><a href="http://llvm.org/doxygen/">http://llvm.org/doxygen/</a></tt>. The following is a brief introduction to code layout:</p> -</div> - <!-- ======================================================================= --> <h3> <a name="examples"><tt>llvm/examples</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains some simple examples of how to use the LLVM IR and JIT.</p> </div> @@ -1281,7 +1278,7 @@ The following is a brief introduction to code layout:</p> <a name="include"><tt>llvm/include</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains public header files exported from the LLVM library. The three main subdirectories of this directory are:</p> @@ -1312,7 +1309,7 @@ library. The three main subdirectories of this directory are:</p> <a name="lib"><tt>llvm/lib</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains most of the source files of the LLVM system. In LLVM, almost all code exists in libraries, making it very easy to share code among the @@ -1381,7 +1378,7 @@ different <a href="#tools">tools</a>.</p> <a name="projects"><tt>llvm/projects</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains projects that are not strictly part of LLVM but are shipped with LLVM. This is also the directory where you should create your own LLVM-based projects. See <tt>llvm/projects/sample</tt> for an example of how @@ -1393,7 +1390,7 @@ different <a href="#tools">tools</a>.</p> <a name="runtime"><tt>llvm/runtime</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains libraries which are compiled into LLVM bitcode and used when linking programs with the GCC front end. Most of these libraries are @@ -1410,7 +1407,7 @@ end to compile.</p> <a name="test"><tt>llvm/test</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains feature and regression tests and other basic sanity checks on the LLVM infrastructure. These are intended to run quickly and cover a lot of territory without being exhaustive.</p> @@ -1421,7 +1418,7 @@ end to compile.</p> <a name="test-suite"><tt>test-suite</tt></a> </h3> -<div class="doc_text"> +<div> <p>This is not a directory in the normal llvm module; it is a separate Subversion module that must be checked out (usually to <tt>projects/test-suite</tt>). @@ -1440,7 +1437,7 @@ end to compile.</p> <a name="tools"><tt>llvm/tools</tt></a> </h3> -<div class="doc_text"> +<div> <p>The <b>tools</b> directory contains the executables built out of the libraries above, which form the main part of the user interface. You can @@ -1528,7 +1525,7 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p> <a name="utils"><tt>llvm/utils</tt></a> </h3> -<div class="doc_text"> +<div> <p>This directory contains utilities for working with LLVM source code, and some of the utilities are actually required as part of the build process because they @@ -1589,13 +1586,15 @@ are code generators for parts of LLVM infrastructure.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="tutorial">An Example Using the LLVM Tool Chain</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section gives an example of using LLVM. llvm-gcc3 is now obsolete, so we only include instructions for llvm-gcc4. </p> @@ -1606,14 +1605,13 @@ create bitcode by default: <i>gcc4</i> produces native code. As the example belo the '--emit-llvm' flag is needed to produce LLVM bitcode output. For <i>makefiles</i> and <i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode output.</p> -</div> <!-- ======================================================================= --> <h3> <a name="tutorial4">Example with llvm-gcc4</a> </h3> -<div class="doc_text"> +<div> <ol> <li><p>First, create a simple C file, name it 'hello.c':</p> @@ -1694,6 +1692,7 @@ int main() { </div> +</div> <!-- *********************************************************************** --> <h2> @@ -1701,7 +1700,7 @@ int main() { </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>If you are having problems building or using LLVM, or if you have any other general questions about LLVM, please consult the <a href="FAQ.html">Frequently @@ -1715,7 +1714,7 @@ Asked Questions</a> page.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is just an <b>introduction</b> on how to use LLVM to do some simple things... there are many more interesting and complicated things diff --git a/docs/GettingStartedVS.html b/docs/GettingStartedVS.html index 469b537..d6bf1b6 100644 --- a/docs/GettingStartedVS.html +++ b/docs/GettingStartedVS.html @@ -36,7 +36,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to LLVM on Windows! This document only covers LLVM on Windows using Visual Studio, not mingw or cygwin. In order to get started, you first need to @@ -75,20 +75,18 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Before you begin to use the LLVM system, review the requirements given below. This may save you some trouble by knowing ahead of time what hardware and software you will need.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="hardware"><b>Hardware</b></a> </h3> -<div class="doc_text"> +<div> <p>Any system that can adequately run Visual Studio .NET 2005 SP1 is fine. The LLVM source tree and object files, libraries and executables will consume @@ -98,7 +96,7 @@ <!-- ======================================================================= --> <h3><a name="software"><b>Software</b></a></h3> -<div class="doc_text"> +<div> <p>You will need Visual Studio .NET 2005 SP1 or higher. The VS2005 SP1 beta and the normal VS2005 still have bugs that are not completely @@ -118,13 +116,15 @@ </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="quickstart"><b>Getting Started</b></a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Here's the short story for getting up and running quickly with LLVM:</p> @@ -234,7 +234,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ol> <li><p>First, create a simple C file, name it 'hello.c':</p> @@ -324,7 +324,7 @@ int main() { </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>If you are having problems building or using LLVM, or if you have any other general questions about LLVM, please consult the <a href="FAQ.html">Frequently @@ -338,7 +338,7 @@ Asked Questions</a> page.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is just an <b>introduction</b> to how to use LLVM to do some simple things... there are many more interesting and complicated things diff --git a/docs/GoldPlugin.html b/docs/GoldPlugin.html index 7ba1186..e25c457 100644 --- a/docs/GoldPlugin.html +++ b/docs/GoldPlugin.html @@ -23,7 +23,7 @@ <!--=========================================================================--> <h2><a name="introduction">Introduction</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>Building with link time optimization requires cooperation from the system linker. LTO support on Linux systems requires that you use the <a href="http://sourceware.org/binutils">gold linker</a> which supports @@ -40,7 +40,7 @@ The same plugin can also be used by other tools such as <tt>ar</tt> and <!--=========================================================================--> <h2><a name="build">How to build it</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>You need to have gold with plugin support and build the LLVMgold plugin. Check whether you have gold running <tt>/usr/bin/ld -v</tt>. It will report “GNU gold” or else “GNU ld” if not. If you have @@ -74,7 +74,7 @@ placed. <!--=========================================================================--> <h2><a name="usage">Usage</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>The linker takes a <tt>-plugin</tt> option that points to the path of the plugin <tt>.so</tt> file. To find out what link command <tt>gcc</tt> would run in a given situation, run <tt>gcc -v <em>[...]</em></tt> and look @@ -95,14 +95,13 @@ placed. own gold, be sure to install the <tt>ar</tt> and <tt>nm-new</tt> you built to <tt>/usr/bin</tt>. <p> -</div> <!-- ======================================================================= --> <h3> <a name="example1">Example of link time optimization</a> </h3> -<div class="doc_text"> +<div> <p>The following example shows a worked example of the gold plugin mixing LLVM bitcode and native code. <pre class="doc_code"> @@ -149,6 +148,8 @@ $ llvm-gcc -use-gold-plugin a.a b.o -o main # <-- link with LLVMgold plugin example</a> gold does not currently eliminate foo4.</p> </div> +</div> + <!--=========================================================================--> <h2> <a name="lto_autotools"> @@ -156,7 +157,7 @@ $ llvm-gcc -use-gold-plugin a.a b.o -o main # <-- link with LLVMgold plugin </a> </h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>Once your system <tt>ld</tt>, <tt>ar</tt> and <tt>nm</tt> all support LLVM bitcode, everything is in place for an easy to use LTO build of autotooled projects:</p> @@ -195,7 +196,7 @@ export CFLAGS="-O4" <!--=========================================================================--> <h2><a name="licensing">Licensing</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>Gold is licensed under the GPLv3. LLVMgold uses the interface file <tt>plugin-api.h</tt> from gold which means that the resulting LLVMgold.so binary is also GPLv3. This can still be used to link non-GPLv3 programs just diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html index 59e7864..8a7d7f4 100644 --- a/docs/HowToReleaseLLVM.html +++ b/docs/HowToReleaseLLVM.html @@ -26,7 +26,7 @@ <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document contains information about successfully releasing LLVM — including subprojects: e.g., <tt>llvm-gcc</tt> and <tt>clang</tt> — to @@ -38,7 +38,7 @@ <!-- *********************************************************************** --> <h2><a name="process">Release Timeline</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM is released on a time based schedule — roughly every 6 months. We do not normally have dot releases because of the nature of LLVM's incremental @@ -79,7 +79,7 @@ <h2><a name="process">Release Process</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <ol> <li><a href="#release-admin">Release Administrative Tasks</a> @@ -119,12 +119,10 @@ </li> </ol> -</div> - <!-- ======================================================================= --> <h3><a name="release-admin">Release Administrative Tasks</a></h3> -<div class="doc_text"> +<div> <p>This section describes a few administrative tasks that need to be done for the release process to begin. Specifically, it involves:</p> @@ -135,12 +133,10 @@ <li>Tagging release candidates for the release team to begin testing</li> </ul> -</div> - <!-- ======================================================================= --> <h4><a name="branch">Create Release Branch</a></h4> -<div class="doc_text"> +<div> <p>Branch the Subversion trunk using the following procedure:</p> @@ -200,7 +196,7 @@ $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> clang- <!-- ======================================================================= --> <h4><a name="verchanges">Update LLVM Version</a></h4> -<div class="doc_text"> +<div> <p>After creating the LLVM release branch, update the release branches' <tt>autoconf</tt> and <tt>configure.ac</tt> versions from '<tt>X.Ysvn</tt>' @@ -216,7 +212,7 @@ $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> clang- <!-- ======================================================================= --> <h4><a name="dist">Build the LLVM Release Candidates</a></h4> -<div class="doc_text"> +<div> <p>Create release candidates for <tt>llvm</tt>, <tt>llvm-gcc</tt>, <tt>clang</tt>, and the LLVM <tt>test-suite</tt> by tagging the branch with @@ -268,10 +264,12 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g </div> +</div> + <!-- ======================================================================= --> <h3><a name="release-build">Building the Release</a></h3> -<div class="doc_text"> +<div> <p>The builds of <tt>llvm</tt>, <tt>llvm-gcc</tt>, and <tt>clang</tt> <em>must</em> be free of errors and warnings in Debug, Release+Asserts, and @@ -287,12 +285,10 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <tr align="left"><td>Release</td><td><tt>ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1</tt></td></tr> </table> -</div> - <!-- ======================================================================= --> <h4><a name="build">Build LLVM</a></h4> -<div class="doc_text"> +<div> <p>Build <tt>Debug</tt>, <tt>Release+Asserts</tt>, and <tt>Release</tt> versions of <tt>llvm</tt> on all supported platforms. Directions to build @@ -304,7 +300,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></h4> -<div class="doc_text"> +<div> <p>Creating the <tt>llvm-gcc</tt> binary distribution (Release/Optimized) requires performing the following steps for each supported platform:</p> @@ -331,7 +327,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="clangbin">Build Clang Binary Distribution</a></h4> -<div class="doc_text"> +<div> <p>Creating the <tt>clang</tt> binary distribution (Debug/Release+Asserts/Release) requires performing the following steps for @@ -352,7 +348,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="target-build">Target Specific Build Details</a></h4> -<div class="doc_text"> +<div> <p>The table below specifies which compilers are used for each Arch/OS combination when qualifying the build of <tt>llvm</tt>, <tt>llvm-gcc</tt>, @@ -371,10 +367,12 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g </div> +</div> + <!-- ======================================================================= --> <h3><a name="release-qualify">Building the Release</a></h3> -<div class="doc_text"> +<div> <p>A release is qualified when it has no regressions from the previous release (or baseline). Regressions are related to correctness first and performance @@ -390,12 +388,10 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g criteria, but these are the criteria which we found to be most important and which must be satisfied before a release can go out</b></p> -</div> - <!-- ======================================================================= --> <h4><a name="llvm-qualify">Qualify LLVM</a></h4> -<div class="doc_text"> +<div> <p>LLVM is qualified when it has a clean test run without a front-end. And it has no regressions when using either <tt>llvm-gcc</tt> or <tt>clang</tt> with @@ -406,7 +402,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="llvmgcc-qualify">Qualify LLVM-GCC</a></h4> -<div class="doc_text"> +<div> <p><tt>LLVM-GCC</tt> is qualified when front-end specific tests in the <tt>llvm</tt> regression test suite all pass and there are no regressions in @@ -419,7 +415,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="clang-qualify">Qualify Clang</a></h4> -<div class="doc_text"> +<div> <p><tt>Clang</tt> is qualified when front-end specific tests in the <tt>llvm</tt> dejagnu test suite all pass, clang's own test suite passes @@ -430,7 +426,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="targets">Specific Target Qualification Details</a></h4> -<div class="doc_text"> +<div> <table> <tr><th>Architecture</th><th>OS</th><th>llvm-gcc baseline</th><th>clang baseline</th><th>tests</th></tr> @@ -444,9 +440,11 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g </div> +</div> + <!-- ======================================================================= --> <h3><a name="commTest">Community Testing</a></h3> -<div class="doc_text"> +<div> <p>Once all testing has been completed and appropriate bugs filed, the release candidate tarballs are put on the website and the LLVM community is @@ -484,7 +482,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h3><a name="release-patch">Release Patch Rules</a></h3> -<div class="doc_text"> +<div> <p>Below are the rules regarding patching the release branch:</p> @@ -508,19 +506,16 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h3><a name="release-final">Release Final Tasks</a></h3> -<div class="doc_text"> +<div> <p>The final stages of the release process involves tagging the "final" release branch, updating documentation that refers to the release, and updating the demo page.</p> -</div> - - <!-- ======================================================================= --> <h4><a name="updocs">Update Documentation</a></h4> -<div class="doc_text"> +<div> <p>Review the documentation and ensure that it is up to date. The "Release Notes" must be updated to reflect new features, bug fixes, new known issues, @@ -534,7 +529,7 @@ $ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > clang-<i>X.Y</i>rc1.src.tar.g <!-- ======================================================================= --> <h4><a name="tag">Tag the LLVM Final Release</a></h4> -<div class="doc_text"> +<div> <p>Tag the final release sources using the following procedure:</p> @@ -556,20 +551,20 @@ $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \ </div> +</div> + <!-- ======================================================================= --> <h3><a name="updemo">Update the LLVM Demo Page</a></h3> -<div class="doc_text"> +<div> <p>The LLVM demo page must be updated to use the new release. This consists of using the new <tt>llvm-gcc</tt> binary and building LLVM.</p> -</div> - <!-- ======================================================================= --> <h4><a name="webupdates">Update the LLVM Website</a></h4> -<div class="doc_text"> +<div> <p>The website must be updated before the release announcement is sent out. Here is what to do:</p> @@ -605,12 +600,16 @@ $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \ <!-- ======================================================================= --> <h4><a name="announce">Announce the Release</a></h4> -<div class="doc_text"> +<div> <p>Have Chris send out the release announcement when everything is finished.</p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html index ca34384..0af273f 100644 --- a/docs/HowToSubmitABug.html +++ b/docs/HowToSubmitABug.html @@ -42,7 +42,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>If you're working with LLVM and run into a bug, we definitely want to know about it. This document describes what you can do to increase the odds of @@ -81,7 +81,7 @@ information:</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>More often than not, bugs in the compiler cause it to crash—often due to an assertion failure of some sort. The most important @@ -109,14 +109,12 @@ with the following extra command line options:</p> </ul> -</div> - <!-- ======================================================================= --> <h3> <a name="front-end">Front-end bugs</a> </h3> -<div class="doc_text"> +<div> <p>If the problem is in the front-end, you should re-run the same <tt>llvm-gcc</tt> command that resulted in the crash, but add the @@ -141,7 +139,7 @@ has instructions on the best way to use delta.</p> <a name="ct_optimizer">Compile-time optimization bugs</a> </h3> -<div class="doc_text"> +<div> <p>If you find that a bug crashes in the optimizer, compile your test-case to a <tt>.bc</tt> file by passing "<tt><b>-emit-llvm -O0 -c -o foo.bc</b></tt>". @@ -175,7 +173,7 @@ that bugpoint emits. If something goes wrong with bugpoint, please submit the <a name="ct_codegen">Code generator bugs</a> </h3> -<div class="doc_text"> +<div> <p>If you find a bug that crashes llvm-gcc in the code generator, compile your source file to a .bc file by passing "<tt><b>-emit-llvm -c -o foo.bc</b></tt>" @@ -207,13 +205,15 @@ that bugpoint emits. If something goes wrong with bugpoint, please submit the </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="miscompilations">Miscompilations</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>If llvm-gcc successfully produces an executable, but that executable doesn't run right, this is either a bug in the code or a bug in the @@ -246,7 +246,7 @@ error.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Similarly to debugging incorrect compilation by mis-behaving passes, you can debug incorrect code generation by either LLC or the JIT, using diff --git a/docs/LangRef.html b/docs/LangRef.html index 69e0a75..381fed5 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -324,7 +324,7 @@ <h2><a name="abstract">Abstract</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is a reference manual for the LLVM assembly language. LLVM is a Static Single Assignment (SSA) based representation that provides type @@ -338,7 +338,7 @@ <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable @@ -359,14 +359,12 @@ 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> - <!-- _______________________________________________________________________ --> <h4> <a name="wellformed">Well-Formedness</a> </h4> -<div class="doc_text"> +<div> <p>It is important to note that this document describes 'well formed' LLVM assembly language. There is a difference between what the parser accepts and @@ -386,13 +384,15 @@ </div> +</div> + <!-- Describe the typesetting conventions here. --> <!-- *********************************************************************** --> <h2><a name="identifiers">Identifiers</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM identifiers come in two basic types: global and local. Global identifiers (functions, global variables) begin with the <tt>'@'</tt> @@ -479,13 +479,13 @@ <!-- *********************************************************************** --> <h2><a name="highlevel">High Level Structure</a></h2> <!-- *********************************************************************** --> - +<div> <!-- ======================================================================= --> <h3> <a name="modulestructure">Module Structure</a> </h3> -<div class="doc_text"> +<div> <p>LLVM programs are composed of "Module"s, each of which is a translation unit of the input programs. Each module consists of functions, global variables, @@ -535,7 +535,7 @@ define i32 @main() { <i>; i32()* </i> <a name="linkage">Linkage Types</a> </h3> -<div class="doc_text"> +<div> <p>All Global Variables and Functions have one of the following types of linkage:</p> @@ -684,7 +684,7 @@ define i32 @main() { <i>; i32()* </i> <a name="callingconv">Calling Conventions</a> </h3> -<div class="doc_text"> +<div> <p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a> and <a href="#i_invoke">invokes</a> can all have an optional calling @@ -757,7 +757,7 @@ define i32 @main() { <i>; i32()* </i> <a name="visibility">Visibility Styles</a> </h3> -<div class="doc_text"> +<div> <p>All Global Variables and Functions have one of the following visibility styles:</p> @@ -791,7 +791,7 @@ define i32 @main() { <i>; i32()* </i> <a name="namedtypes">Named Types</a> </h3> -<div class="doc_text"> +<div> <p>LLVM IR allows you to specify name aliases for certain types. This can make it easier to read the IR and make the IR more condensed (particularly when @@ -822,7 +822,7 @@ define i32 @main() { <i>; i32()* </i> <a name="globalvars">Global Variables</a> </h3> -<div class="doc_text"> +<div> <p>Global variables define regions of memory allocated at compilation time instead of run-time. Global variables may optionally be initialized, may @@ -890,7 +890,7 @@ define i32 @main() { <i>; i32()* </i> <a name="functionstructure">Functions</a> </h3> -<div class="doc_text"> +<div> <p>LLVM function definitions consist of the "<tt>define</tt>" keyword, an optional <a href="#linkage">linkage type</a>, an optional @@ -953,7 +953,7 @@ define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>] <a name="aliasstructure">Aliases</a> </h3> -<div class="doc_text"> +<div> <p>Aliases act as "second name" for the aliasee value (which can be either function, global variable, another alias or bitcast of global value). Aliases @@ -972,7 +972,7 @@ define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>] <a name="namedmetadatastructure">Named Metadata</a> </h3> -<div class="doc_text"> +<div> <p>Named metadata is a collection of metadata. <a href="#metadata">Metadata nodes</a> (but not metadata strings) are the only valid operands for @@ -995,7 +995,7 @@ define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>] <a name="paramattrs">Parameter Attributes</a> </h3> -<div class="doc_text"> +<div> <p>The return type and each parameter of a function type may have a set of <i>parameter attributes</i> associated with them. Parameter attributes are @@ -1106,7 +1106,7 @@ declare signext i8 @returns_signed_char() <a name="gc">Garbage Collector Names</a> </h3> -<div class="doc_text"> +<div> <p>Each function may specify a garbage collector name, which is simply a string:</p> @@ -1126,7 +1126,7 @@ define void @f() gc "name" { ... } <a name="fnattrs">Function Attributes</a> </h3> -<div class="doc_text"> +<div> <p>Function attributes are set to communicate additional information about a function. Function attributes are considered to be part of the function, not @@ -1249,7 +1249,7 @@ define void @f() optsize { ... } <a name="moduleasm">Module-Level Inline Assembly</a> </h3> -<div class="doc_text"> +<div> <p>Modules may contain "module-level inline asm" blocks, which corresponds to the GCC "file scope inline asm" blocks. These blocks are internally @@ -1275,7 +1275,7 @@ module asm "more can go here" <a name="datalayout">Data Layout</a> </h3> -<div class="doc_text"> +<div> <p>A module may specify a target specific data layout string that specifies how data is to be laid out in memory. The syntax for the data layout is @@ -1387,7 +1387,7 @@ target datalayout = "<i>layout specification</i>" <a name="pointeraliasing">Pointer Aliasing Rules</a> </h3> -<div class="doc_text"> +<div> <p>Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior @@ -1451,7 +1451,7 @@ to implement type-based alias analysis.</p> <a name="volatile">Volatile Memory Accesses</a> </h3> -<div class="doc_text"> +<div> <p>Certain memory accesses, such as <a href="#i_load"><tt>load</tt></a>s, <a href="#i_store"><tt>store</tt></a>s, and <a @@ -1464,11 +1464,13 @@ synchronization behavior.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="typesystem">Type System</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM type system is one of the most important features of the intermediate representation. Being typed enables a number of optimizations @@ -1478,14 +1480,12 @@ synchronization behavior.</p> and transformations that are not feasible to perform on normal three address code representations.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="t_classifications">Type Classifications</a> </h3> -<div class="doc_text"> +<div> <p>The types fall into a few useful classifications:</p> @@ -1546,19 +1546,17 @@ synchronization behavior.</p> <a name="t_primitive">Primitive Types</a> </h3> -<div class="doc_text"> +<div> <p>The primitive types are the fundamental building blocks of the LLVM system.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="t_integer">Integer Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The integer type is a very simple type that simply specifies an arbitrary @@ -1596,7 +1594,7 @@ synchronization behavior.</p> <a name="t_floating">Floating Point Types</a> </h4> -<div class="doc_text"> +<div> <table> <tbody> @@ -1616,7 +1614,7 @@ synchronization behavior.</p> <a name="t_x86mmx">X86mmx Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.</p> @@ -1633,7 +1631,7 @@ synchronization behavior.</p> <a name="t_void">Void Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The void type does not represent any value and has no size.</p> @@ -1650,7 +1648,7 @@ synchronization behavior.</p> <a name="t_label">Label Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The label type represents code labels.</p> @@ -1667,7 +1665,7 @@ synchronization behavior.</p> <a name="t_metadata">Metadata Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The metadata type represents embedded metadata. No derived types may be @@ -1681,13 +1679,14 @@ synchronization behavior.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="t_derived">Derived Types</a> </h3> -<div class="doc_text"> +<div> <p>The real power in LLVM comes from the derived types in the system. This is what allows a programmer to represent arrays, functions, pointers, and other @@ -1697,14 +1696,12 @@ synchronization behavior.</p> of another array.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="t_aggregate">Aggregate Types</a> </h4> -<div class="doc_text"> +<div> <p>Aggregate Types are a subset of derived types that can contain multiple member types. <a href="#t_array">Arrays</a>, @@ -1718,7 +1715,7 @@ synchronization behavior.</p> <a name="t_array">Array Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The array type is a very simple derived type that arranges elements @@ -1778,7 +1775,7 @@ synchronization behavior.</p> <a name="t_function">Function Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The function type can be thought of as a function signature. It consists of @@ -1833,7 +1830,7 @@ synchronization behavior.</p> <a name="t_struct">Structure Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The structure type is used to represent a collection of data members together @@ -1873,7 +1870,7 @@ synchronization behavior.</p> <a name="t_pstruct">Packed Structure Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The packed structure type is used to represent a collection of data members @@ -1912,7 +1909,7 @@ synchronization behavior.</p> <a name="t_pointer">Pointer Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>The pointer type is used to specify memory locations. @@ -1958,7 +1955,7 @@ synchronization behavior.</p> <a name="t_vector">Vector Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>A vector type is a simple derived type that represents a vector of elements. @@ -1999,7 +1996,7 @@ synchronization behavior.</p> <a name="t_opaque">Opaque Type</a> </h4> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>Opaque types are used to represent unknown types in the system. This @@ -2022,12 +2019,14 @@ synchronization behavior.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="t_uprefs">Type Up-references</a> </h3> -<div class="doc_text"> +<div> <h5>Overview:</h5> <p>An "up reference" allows you to refer to a lexically enclosing type without @@ -2070,23 +2069,23 @@ synchronization behavior.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="constants">Constants</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM has several different basic types of constants. This section describes them all and their syntax.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="simpleconstants">Simple Constants</a> </h3> -<div class="doc_text"> +<div> <dl> <dt><b>Boolean constants</b></dt> @@ -2144,7 +2143,7 @@ synchronization behavior.</p> <a name="complexconstants">Complex Constants</a> </h3> -<div class="doc_text"> +<div> <p>Complex constants are a (potentially recursive) combination of simple constants and smaller complex constants.</p> @@ -2198,7 +2197,7 @@ synchronization behavior.</p> <a name="globalconstants">Global Variable and Function Addresses</a> </h3> -<div class="doc_text"> +<div> <p>The addresses of <a href="#globalvars">global variables</a> and <a href="#functionstructure">functions</a> are always implicitly valid @@ -2220,7 +2219,7 @@ synchronization behavior.</p> <a name="undefvalues">Undefined Values</a> </h3> -<div class="doc_text"> +<div> <p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. @@ -2363,7 +2362,7 @@ b: unreachable <a name="trapvalues">Trap Values</a> </h3> -<div class="doc_text"> +<div> <p>Trap values are similar to <a href="#undefvalues">undef values</a>, however instead of representing an unspecified bit pattern, they represent the @@ -2491,7 +2490,7 @@ second_end: <a name="blockaddress">Addresses of Basic Blocks</a> </h3> -<div class="doc_text"> +<div> <p><b><tt>blockaddress(@function, %block)</tt></b></p> @@ -2520,7 +2519,7 @@ second_end: <a name="constantexprs">Constant Expressions</a> </h3> -<div class="doc_text"> +<div> <p>Constant expressions are used to allow expressions involving other constants to be used as constants. Constant expressions may be of @@ -2646,16 +2645,18 @@ second_end: </div> +</div> + <!-- *********************************************************************** --> <h2><a name="othervalues">Other Values</a></h2> <!-- *********************************************************************** --> - +<div> <!-- ======================================================================= --> <h3> <a name="inlineasm">Inline Assembler Expressions</a> </h3> -<div class="doc_text"> +<div> <p>LLVM supports inline assembler expressions (as opposed to <a href="#moduleasm"> Module-Level Inline Assembly</a>) through the use of @@ -2704,13 +2705,12 @@ call void asm alignstack "eieio", ""() documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to another document that covers inline asm from a holistic perspective.</p> -</div> <h4> <a name="inlineasm_md">Inline Asm Metadata</a> </h4> -<div class="doc_text"> +<div> <p>The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode attached to it that contains a list of constant integers. If present, the @@ -2731,12 +2731,14 @@ call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="metadata">Metadata Nodes and Metadata Strings</a> </h3> -<div class="doc_text"> +<div> <p>LLVM IR allows metadata to be attached to instructions in the program that can convey extra information about the code to the optimizers and code @@ -2778,13 +2780,14 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) </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 @@ -2796,7 +2799,7 @@ by LLVM.</p> <a name="intg_used">The '<tt>llvm.used</tt>' Global Variable</a> </h3> -<div class="doc_text"> +<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 @@ -2833,7 +2836,7 @@ object file to prevent the assembler and linker from molesting the symbol.</p> </a> </h3> -<div class="doc_text"> +<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 @@ -2851,7 +2854,7 @@ should not be exposed to source languages.</p> <a name="intg_global_ctors">The '<tt>llvm.global_ctors</tt>' Global Variable</a> </h3> -<div class="doc_text"> +<div> <pre> %0 = type { i32, void ()* } @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }] @@ -2866,7 +2869,7 @@ should not be exposed to source languages.</p> <a name="intg_global_dtors">The '<tt>llvm.global_dtors</tt>' Global Variable</a> </h3> -<div class="doc_text"> +<div> <pre> %0 = type { i32, void ()* } @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }] @@ -2877,12 +2880,13 @@ should not be exposed to source languages.</p> </div> +</div> <!-- *********************************************************************** --> <h2><a name="instref">Instruction Reference</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM instruction set consists of several different classifications of instructions: <a href="#terminators">terminator @@ -2891,14 +2895,12 @@ should not be exposed to source languages.</p> <a href="#memoryops">memory instructions</a>, and <a href="#otherops">other instructions</a>.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="terminators">Terminator Instructions</a> </h3> -<div class="doc_text"> +<div> <p>As mentioned <a href="#functionstructure">previously</a>, every basic block in a program ends with a "Terminator" instruction, which indicates which @@ -2916,14 +2918,12 @@ should not be exposed to source languages.</p> '<a href="#i_unwind"><tt>unwind</tt></a>' instruction, and the '<a href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_ret">'<tt>ret</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -2973,7 +2973,7 @@ should not be exposed to source languages.</p> <a name="i_br">'<tt>br</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3016,7 +3016,7 @@ IfUnequal: <a name="i_switch">'<tt>switch</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3071,7 +3071,7 @@ IfUnequal: <a name="i_indirectbr">'<tt>indirectbr</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3119,7 +3119,7 @@ IfUnequal: <a name="i_invoke">'<tt>invoke</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3209,7 +3209,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_unwind">'<tt>unwind</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3241,7 +3241,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_unreachable">'<tt>unreachable</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3259,12 +3259,14 @@ that the invoke/unwind semantics are likely to change in future versions.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="binaryops">Binary Operations</a> </h3> -<div class="doc_text"> +<div> <p>Binary operators are used to do most of the computation in a program. They require two operands of the same type, execute an operation on them, and @@ -3274,14 +3276,12 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <p>There are several different binary operators:</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_add">'<tt>add</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3326,7 +3326,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_fadd">'<tt>fadd</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3356,7 +3356,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_sub">'<tt>sub</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3408,7 +3408,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_fsub">'<tt>fsub</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3444,7 +3444,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_mul">'<tt>mul</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3494,7 +3494,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_fmul">'<tt>fmul</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3524,7 +3524,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_udiv">'<tt>udiv</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3565,7 +3565,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_sdiv">'<tt>sdiv</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3608,7 +3608,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_fdiv">'<tt>fdiv</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3638,7 +3638,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_urem">'<tt>urem</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3676,7 +3676,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_srem">'<tt>srem</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3727,7 +3727,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_frem">'<tt>frem</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3754,12 +3754,14 @@ that the invoke/unwind semantics are likely to change in future versions.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="bitwiseops">Bitwise Binary Operations</a> </h3> -<div class="doc_text"> +<div> <p>Bitwise binary operators are used to do various forms of bit-twiddling in a program. They are generally very efficient instructions and can commonly be @@ -3767,14 +3769,12 @@ that the invoke/unwind semantics are likely to change in future versions.</p> same type, execute an operation on them, and produce a single value. The resulting value is the same type as its operands.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_shl">'<tt>shl</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3825,7 +3825,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_lshr">'<tt>lshr</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3872,7 +3872,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_ashr">'<tt>ashr</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3919,7 +3919,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_and">'<tt>and</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -3980,7 +3980,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_or">'<tt>or</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4043,7 +4043,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_xor">'<tt>xor</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4103,12 +4103,14 @@ that the invoke/unwind semantics are likely to change in future versions.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="vectorops">Vector Operations</a> </h3> -<div class="doc_text"> +<div> <p>LLVM supports several instructions to represent vector operations in a target-independent manner. These instructions cover the element-access and @@ -4117,14 +4119,12 @@ that the invoke/unwind semantics are likely to change in future versions.</p> will want to use target-specific intrinsics to take full advantage of a specific target.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4160,7 +4160,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4196,7 +4196,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4239,24 +4239,24 @@ that the invoke/unwind semantics are likely to change in future versions.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="aggregateops">Aggregate Operations</a> </h3> -<div class="doc_text"> +<div> <p>LLVM supports several instructions for working with <a href="#t_aggregate">aggregate</a> values.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_extractvalue">'<tt>extractvalue</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4298,7 +4298,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_insertvalue">'<tt>insertvalue</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4332,27 +4332,26 @@ that the invoke/unwind semantics are likely to change in future versions.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="memoryops">Memory Access and Addressing Operations</a> </h3> -<div class="doc_text"> +<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, and allocate memory in LLVM.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_alloca">'<tt>alloca</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4403,7 +4402,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_load">'<tt>load</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4462,7 +4461,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_store">'<tt>store</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4524,7 +4523,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4650,25 +4649,25 @@ entry: </div> +</div> + <!-- ======================================================================= --> <h3> <a name="convertops">Conversion Operations</a> </h3> -<div class="doc_text"> +<div> <p>The instructions in this category are the conversion instructions (casting) which all take a single operand and a type. They perform various bit conversions on the operand.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4708,7 +4707,7 @@ entry: <a name="i_zext">'<tt>zext .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4748,7 +4747,7 @@ entry: <a name="i_sext">'<tt>sext .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4787,7 +4786,7 @@ entry: <a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4825,7 +4824,7 @@ entry: <a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4862,7 +4861,7 @@ entry: <a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4900,7 +4899,7 @@ entry: <a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4939,7 +4938,7 @@ entry: <a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -4976,7 +4975,7 @@ entry: <a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5012,7 +5011,7 @@ entry: <a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5050,7 +5049,7 @@ entry: <a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5088,7 +5087,7 @@ entry: <a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5127,24 +5126,24 @@ entry: </div> +</div> + <!-- ======================================================================= --> <h3> <a name="otherops">Other Operations</a> </h3> -<div class="doc_text"> +<div> <p>The instructions in this category are the "miscellaneous" instructions, which defy better classification.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="i_icmp">'<tt>icmp</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5247,7 +5246,7 @@ entry: <a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5368,7 +5367,7 @@ entry: <a name="i_phi">'<tt>phi</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5416,7 +5415,7 @@ Loop: ; Infinite loop that counts from 0 on up... <a name="i_select">'<tt>select</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5459,7 +5458,7 @@ Loop: ; Infinite loop that counts from 0 on up... <a name="i_call">'<tt>call</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5568,7 +5567,7 @@ freestanding environments and non-C-based languages.</p> <a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5609,11 +5608,15 @@ freestanding environments and non-C-based languages.</p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2><a name="intrinsics">Intrinsic Functions</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM supports the notion of an "intrinsic function". These functions have well known names and semantics and are required to follow certain @@ -5656,14 +5659,12 @@ freestanding environments and non-C-based languages.</p> <p>To learn how to add an intrinsic function, please see the <a href="ExtendingLLVM.html">Extending LLVM Guide</a>.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="int_varargs">Variable Argument Handling Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>Variable argument support is defined in LLVM with the <a href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three @@ -5705,15 +5706,13 @@ declare void @llvm.va_copy(i8*, i8*) declare void @llvm.va_end(i8*) </pre> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5743,7 +5742,7 @@ declare void @llvm.va_end(i8*) <a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5774,7 +5773,7 @@ declare void @llvm.va_end(i8*) <a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5800,12 +5799,14 @@ declare void @llvm.va_end(i8*) </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_gc">Accurate Garbage Collection Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>LLVM support for <a href="GarbageCollection.html">Accurate Garbage Collection</a> (GC) requires the implementation and generation of these @@ -5820,14 +5821,12 @@ LLVM</a>.</p> <p>The garbage collection intrinsics only operate on objects in the generic address space (address space zero).</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5858,7 +5857,7 @@ LLVM</a>.</p> <a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5890,7 +5889,7 @@ LLVM</a>.</p> <a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5917,24 +5916,24 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_codegen">Code Generator Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>These intrinsics are provided by LLVM to expose special features that may only be implemented with code generator support.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -5969,7 +5968,7 @@ LLVM</a>.</p> <a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6003,7 +6002,7 @@ LLVM</a>.</p> <a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6033,7 +6032,7 @@ LLVM</a>.</p> <a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6058,7 +6057,7 @@ LLVM</a>.</p> <a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6091,7 +6090,7 @@ LLVM</a>.</p> <a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6122,7 +6121,7 @@ LLVM</a>.</p> <a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -6144,26 +6143,26 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_libc">Standard C Library Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>LLVM provides intrinsics for a few important standard C library functions. These intrinsics allow source-language front-ends to pass information about the alignment of the pointer arguments to the code generator, providing opportunity for more efficient code generation.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.memcpy</tt> on any @@ -6217,7 +6216,7 @@ LLVM</a>.</p> <a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use llvm.memmove on any integer bit @@ -6273,7 +6272,7 @@ LLVM</a>.</p> <a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use llvm.memset on any integer bit @@ -6323,7 +6322,7 @@ LLVM</a>.</p> <a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.sqrt</tt> on any @@ -6361,7 +6360,7 @@ LLVM</a>.</p> <a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.powi</tt> on any @@ -6397,7 +6396,7 @@ LLVM</a>.</p> <a name="int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.sin</tt> on any @@ -6431,7 +6430,7 @@ LLVM</a>.</p> <a name="int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.cos</tt> on any @@ -6465,7 +6464,7 @@ LLVM</a>.</p> <a name="int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.pow</tt> on any @@ -6495,24 +6494,24 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_manip">Bit Manipulation Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>LLVM provides intrinsics for a few important bit manipulation operations. These allow efficient code generation for some algorithms.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic function. You can use bswap on any integer @@ -6547,7 +6546,7 @@ LLVM</a>.</p> <a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit @@ -6579,7 +6578,7 @@ LLVM</a>.</p> <a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any @@ -6613,7 +6612,7 @@ LLVM</a>.</p> <a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any @@ -6642,17 +6641,17 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_overflow">Arithmetic with Overflow Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>LLVM provides intrinsics for some arithmetic with overflow operations.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_sadd_overflow"> @@ -6660,7 +6659,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.sadd.with.overflow</tt> @@ -6708,7 +6707,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.uadd.with.overflow</tt> @@ -6755,7 +6754,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.ssub.with.overflow</tt> @@ -6803,7 +6802,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.usub.with.overflow</tt> @@ -6851,7 +6850,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.smul.with.overflow</tt> @@ -6900,7 +6899,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.umul.with.overflow</tt> @@ -6941,12 +6940,14 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_fp16">Half Precision Floating Point Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>Half precision floating point is a storage-only format. This means that it is a dense encoding (in memory) but does not support computation in the @@ -6960,7 +6961,6 @@ LLVM</a>.</p> float if needed, then converted to i16 with <a href="#int_convert_to_fp16"><tt>llvm.convert.to.fp16</tt></a>, then storing as an i16 value.</p> -</div> <!-- _______________________________________________________________________ --> <h4> @@ -6969,7 +6969,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7006,7 +7006,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7036,12 +7036,14 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_debugger">Debugger Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix), are described in @@ -7055,7 +7057,7 @@ LLVM</a>.</p> <a name="int_eh">Exception Handling Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM exception handling intrinsics (which all start with <tt>llvm.eh.</tt> prefix), are described in @@ -7069,7 +7071,7 @@ LLVM</a>.</p> <a name="int_trampoline">Trampoline Intrinsic</a> </h3> -<div class="doc_text"> +<div> <p>This intrinsic makes it possible to excise one parameter, marked with the <a href="#nest"><tt>nest</tt></a> attribute, from a function. @@ -7095,8 +7097,6 @@ LLVM</a>.</p> <p>The call <tt>%val = call i32 %fp(i32 %x, i32 %y)</tt> is then equivalent to <tt>%val = call i32 %f(i8* %nval, i32 %x, i32 %y)</tt>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_it"> @@ -7104,7 +7104,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7141,12 +7141,14 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_atomics">Atomic Operations and Synchronization Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>These intrinsic functions expand the "universal IR" of LLVM to represent hardware constructs for atomic operations and memory synchronization. This @@ -7166,14 +7168,12 @@ LLVM</a>.</p> No one model or paradigm should be selected above others unless the hardware itself ubiquitously does so.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_memory_barrier">'<tt>llvm.memory.barrier</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>) @@ -7245,7 +7245,7 @@ LLVM</a>.</p> <a name="int_atomic_cmp_swap">'<tt>llvm.atomic.cmp.swap.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.cmp.swap</tt> on @@ -7305,7 +7305,7 @@ LLVM</a>.</p> <a name="int_atomic_swap">'<tt>llvm.atomic.swap.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.swap</tt> on any @@ -7362,7 +7362,7 @@ LLVM</a>.</p> <a name="int_atomic_load_add">'<tt>llvm.atomic.load.add.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.add</tt> on @@ -7411,7 +7411,7 @@ LLVM</a>.</p> <a name="int_atomic_load_sub">'<tt>llvm.atomic.load.sub.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.sub</tt> on @@ -7476,7 +7476,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>These are overloaded intrinsics. You can @@ -7567,7 +7567,7 @@ LLVM</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>These are overloaded intrinsics. You can use <tt>llvm.atomic.load_max</tt>, @@ -7638,25 +7638,24 @@ LLVM</a>.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="int_memorymarkers">Memory Use Markers</a> </h3> -<div class="doc_text"> +<div> <p>This class of intrinsics exists to information about the lifetime of memory objects and ranges where variables are immutable.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7686,7 +7685,7 @@ LLVM</a>.</p> <a name="int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7715,7 +7714,7 @@ LLVM</a>.</p> <a name="int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7743,7 +7742,7 @@ LLVM</a>.</p> <a name="int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7765,24 +7764,24 @@ LLVM</a>.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="int_general">General Intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>This class of intrinsics is designed to be generic and has no specific purpose.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7810,7 +7809,7 @@ LLVM</a>.</p> <a name="int_annotation">'<tt>llvm.annotation.*</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <p>This is an overloaded intrinsic. You can use '<tt>llvm.annotation</tt>' on @@ -7846,7 +7845,7 @@ LLVM</a>.</p> <a name="int_trap">'<tt>llvm.trap</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7871,7 +7870,7 @@ LLVM</a>.</p> <a name="int_stackprotector">'<tt>llvm.stackprotector</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7905,7 +7904,7 @@ LLVM</a>.</p> <a name="int_objectsize">'<tt>llvm.objectsize</tt>' Intrinsic</a> </h4> -<div class="doc_text"> +<div> <h5>Syntax:</h5> <pre> @@ -7935,6 +7934,10 @@ LLVM</a>.</p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/Lexicon.html b/docs/Lexicon.html index 458da80..b1c2638 100644 --- a/docs/Lexicon.html +++ b/docs/Lexicon.html @@ -14,7 +14,7 @@ <!-- *********************************************************************** --> <h2>Table Of Contents</h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <table> <tr><th colspan="8"><b>- <a href="#A">A</a> -</b></th></tr> <tr> @@ -85,9 +85,10 @@ <!-- *********************************************************************** --> <h2>Definitions</h2> <!-- *********************************************************************** --> +<div> <!-- _______________________________________________________________________ --> <h3><a name="A">- A -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="ADCE"><b>ADCE</b></a></dt> <dd>Aggressive Dead Code Elimination</dd> @@ -95,7 +96,7 @@ </div> <!-- _______________________________________________________________________ --> <h3><a name="B">- B -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="BURS"><b>BURS</b></a></dt> <dd>Bottom Up Rewriting System—A method of instruction selection for @@ -105,7 +106,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="C">- C -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="CSE"><b>CSE</b></a></dt> <dd>Common Subexpression Elimination. An optimization that removes common @@ -117,7 +118,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="D">- D -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="DAG"><b>DAG</b></a></dt> <dd>Directed Acyclic Graph</dd> @@ -137,7 +138,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="G">- G -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="GC"><b>GC</b></a></dt> <dd>Garbage Collection. The practice of using reachability analysis instead @@ -146,7 +147,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="H">- H -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="Heap"><b>Heap</b></a></dt> <dd>In garbage collection, the region of memory which is managed using @@ -155,7 +156,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="I">- I -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="IPA"><b>IPA</b></a></dt> <dd>Inter-Procedural Analysis. Refers to any variety of code analysis that @@ -170,7 +171,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="L">- L -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="LCSSA"><b>LCSSA</b></a></dt> <dd>Loop-Closed Static Single Assignment Form</dd> @@ -184,7 +185,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="M">- M -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="MC"><b>MC</b></a></dt> <dd>Machine Code</dd> @@ -192,7 +193,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> </div> <!-- _______________________________________________________________________ --> <h3><a name="O">- O -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="Object_Pointer"><b>Object Pointer</b></a></dt> <dd>A pointer to an object such that the garbage collector is able to trace @@ -203,7 +204,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> <!-- _______________________________________________________________________ --> <h3><a name="P">- P -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="PRE"><b>PRE</b></a></dt> <dd>Partial Redundancy Elimination</dd> @@ -212,7 +213,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> <!-- _______________________________________________________________________ --> <h3><a name="R">- R -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="RAUW"><b>RAUW</b></a></dt> <dd>An abbreviation for Replace All Uses With. The functions User::replaceUsesOfWith(), @@ -235,7 +236,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> <!-- _______________________________________________________________________ --> <h3><a name="S">- S -</a></h3> -<div class="doc_text"> +<div> <dl> <dt><a name="Safe_Point"><b>Safe Point</b></a></dt> <dd>In garbage collection, it is necessary to identify <a href="#Root">stack @@ -261,6 +262,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd> function.</dd> </dl> </div> + +</div> <!-- *********************************************************************** --> <hr> <address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 720a5e4..b3bc481 100644 --- a/docs/LinkTimeOptimization.html +++ b/docs/LinkTimeOptimization.html @@ -41,7 +41,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> LLVM features powerful intermodular optimizations which can be used at link time. Link Time Optimization (LTO) is another name for intermodular optimization @@ -55,7 +55,7 @@ and design between the LTO optimizer and the linker.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The LLVM Link Time Optimizer provides complete transparency, while doing intermodular optimization, in the compiler tool chain. Its main goal is to let @@ -69,14 +69,13 @@ the linker and LLVM optimizer helps to do optimizations that are not possible in other models. The linker input allows the optimizer to avoid relying on conservative escape analysis. </p> -</div> <!-- ======================================================================= --> <h3> <a name="example1">Example of link time optimization</a> </h3> -<div class="doc_text"> +<div> <p>The following example illustrates the advantages of LTO's integrated approach and clean interface. This example requires a system linker which supports LTO through the interface described in this document. Here, @@ -149,7 +148,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific <a name="alternative_approaches">Alternative Approaches</a> </h3> -<div class="doc_text"> +<div> <dl> <dt><b>Compiler driver invokes link time optimizer separately.</b></dt> <dd>In this model the link time optimizer is not able to take advantage of @@ -175,12 +174,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific </dl> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="multiphase">Multi-phase communication between libLTO and linker</a> </h2> -<div class="doc_text"> +<div> <p>The linker collects information about symbol defininitions and uses in various link objects which is more accurate than any information collected by other tools during typical build cycles. The linker collects this @@ -192,14 +193,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific Our goal is to take advantage of tight integration between the linker and the optimizer by sharing this information during various linking phases. </p> -</div> <!-- ======================================================================= --> <h3> <a name="phase1">Phase 1 : Read LLVM Bitcode Files</a> </h3> -<div class="doc_text"> +<div> <p>The linker first reads all object files in natural order and collects symbol information. This includes native object files as well as LLVM bitcode files. To minimize the cost to the linker in the case that all .o files @@ -223,7 +223,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific <a name="phase2">Phase 2 : Symbol Resolution</a> </h3> -<div class="doc_text"> +<div> <p>In this stage, the linker resolves symbols using global symbol table. It may report undefined symbol errors, read archive members, replace weak symbols, etc. The linker is able to do this seamlessly even though it @@ -236,7 +236,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific <h3> <a name="phase3">Phase 3 : Optimize Bitcode Files</a> </h3> -<div class="doc_text"> +<div> <p>After symbol resolution, the linker tells the LTO shared object which symbols are needed by native object files. In the example above, the linker reports that only <tt>foo1()</tt> is used by native object files using @@ -252,7 +252,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific <a name="phase4">Phase 4 : Symbol Resolution after optimization</a> </h3> -<div class="doc_text"> +<div> <p>In this phase, the linker reads optimized a native object file and updates the internal global symbol table to reflect any changes. The linker also collects information about any changes in use of external symbols by @@ -264,12 +264,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific bitcode files.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="lto">libLTO</a> </h2> -<div class="doc_text"> +<div> <p><tt>libLTO</tt> is a shared object that is part of the LLVM tools, and is intended for use by a linker. <tt>libLTO</tt> provides an abstract C interface to use the LLVM interprocedural optimizer without exposing details @@ -278,14 +280,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific be possible for a completely different compilation technology to provide a different libLTO that works with their object files and the standard linker tool.</p> -</div> <!-- ======================================================================= --> <h3> <a name="lto_module_t">lto_module_t</a> </h3> -<div class="doc_text"> +<div> <p>A non-native object file is handled via an <tt>lto_module_t</tt>. The following functions allow the linker to check if a file (on disk @@ -329,7 +330,7 @@ lto_module_get_symbol_attribute(lto_module_t, unsigned int) <a name="lto_code_gen_t">lto_code_gen_t</a> </h3> -<div class="doc_text"> +<div> <p>Once the linker has loaded each non-native object files into an <tt>lto_module_t</tt>, it can request libLTO to process them all and @@ -371,6 +372,8 @@ of the native object files.</p> </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index a85314a..ee0115d 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -80,7 +80,7 @@ <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document provides <em>usage</em> information about the LLVM makefile system. While loosely patterned after the BSD makefile system, LLVM has taken a departure from BSD in order to implement additional features needed by LLVM. @@ -102,17 +102,16 @@ <h2><a name="general">General Concepts</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM Makefile System is the component of LLVM that is responsible for building the software, testing it, generating distributions, checking those distributions, installing and uninstalling, etc. It consists of a several files throughout the source tree. These files and other general concepts are described in this section.</p> -</div> <!-- ======================================================================= --> <h3><a name="projects">Projects</a></h3> -<div class="doc_text"> +<div> <p>The LLVM Makefile System is quite generous. It not only builds its own software, but it can build yours too. Built into the system is knowledge of the <tt>llvm/projects</tt> directory. Any directory under <tt>projects</tt> @@ -130,7 +129,7 @@ <!-- ======================================================================= --> <h3><a name="varvalues">Variable Values</a></h3> -<div class="doc_text"> +<div> <p>To use the makefile system, you simply create a file named <tt>Makefile</tt> in your directory and declare values for certain variables. The variables and values that you select determine what the makefile system @@ -140,15 +139,14 @@ <!-- ======================================================================= --> <h3><a name="including">Including Makefiles</a></h3> -<div class="doc_text"> +<div> <p>Setting variables alone is not enough. You must include into your Makefile additional files that provide the rules of the LLVM Makefile system. The various files involved are described in the sections that follow.</p> -</div> <!-- ======================================================================= --> <h4><a name="Makefile">Makefile</a></h4> -<div class="doc_text"> +<div> <p>Each directory to participate in the build needs to have a file named <tt>Makefile</tt>. This is the file first read by <tt>make</tt>. It has three sections:</p> @@ -164,7 +162,7 @@ <!-- ======================================================================= --> <h4><a name="Makefile.common">Makefile.common</a></h4> -<div class="doc_text"> +<div> <p>Every project must have a <tt>Makefile.common</tt> file at its top source directory. This file serves three purposes:</p> <ol> @@ -182,7 +180,7 @@ <!-- ======================================================================= --> <h4><a name="Makefile.config">Makefile.config</a></h4> -<div class="doc_text"> +<div> <p>Every project must have a <tt>Makefile.config</tt> at the top of its <em>build</em> directory. This file is <b>generated</b> by the <tt>configure</tt> script from the pattern provided by the @@ -195,7 +193,7 @@ <!-- ======================================================================= --> <h4><a name="Makefile.rules">Makefile.rules</a></h4> -<div class="doc_text"> +<div> <p>This file, located at <tt>$(LLVM_SRC_ROOT)/Makefile.rules</tt> is the heart of the LLVM Makefile System. It provides all the logic, dependencies, and rules for building the targets supported by the system. What it does largely @@ -203,9 +201,11 @@ have been set <em>before</em> <tt>Makefile.rules</tt> is included. </div> +</div> + <!-- ======================================================================= --> <h3><a name="Comments">Comments</a></h3> -<div class="doc_text"> +<div> <p>User Makefiles need not have comments in them unless the construction is unusual or it does not strictly follow the rules and patterns of the LLVM makefile system. Makefile comments are invoked with the pound (#) character. @@ -213,19 +213,20 @@ by <tt>make</tt>.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="tutorial">Tutorial</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section provides some examples of the different kinds of modules you can build with the LLVM makefile system. In general, each directory you provide will build a single object although that object may be composed of additionally compiled components.</p> -</div> <!-- ======================================================================= --> <h3><a name="libraries">Libraries</a></h3> -<div class="doc_text"> +<div> <p>Only a few variable definitions are needed to build a regular library. Normally, the makefile system will build all the software into a single <tt>libname.o</tt> (pre-linked) object. This means the library is not @@ -254,11 +255,10 @@ <tt>-load</tt> option. See the <a href="WritingAnLLVMPass.html#makefile">WritingAnLLVMPass.html</a> document for an example of why you might want to do this. -</div> <!-- ======================================================================= --> <h4><a name="BCModules">Bitcode Modules</a></h4> -<div class="doc_text"> +<div> <p>In some situations, it is desirable to build a single bitcode module from a variety of sources, instead of an archive, shared library, or bitcode library. Bitcode modules can be specified in addition to any of the other @@ -281,7 +281,7 @@ <h4> <a name="LoadableModules">Loadable Modules</a> </h4> -<div class="doc_text"> +<div> <p>In some situations, you need to create a loadable module. Loadable modules can be loaded into programs like <tt>opt</tt> or <tt>llc</tt> to specify additional passes to run or targets to support. Loadable modules are also @@ -309,9 +309,11 @@ library which is part of <tt>lib/System</tt> implementation.</p> </div> +</div> + <!-- ======================================================================= --> <h3><a name="tools">Tools</a></h3> -<div class="doc_text"> +<div> <p>For building executable programs (tools), you must provide the name of the tool and the names of the libraries you wish to link with the tool. For example:</p> @@ -342,11 +344,10 @@ syntax is used. Note that in order to use the <tt>.a</tt> suffix, the library in question must have been built with the <tt>ARCHIVE_LIBRARY</tt> option set. </p> -</div> <!-- ======================================================================= --> <h4><a name="JIT">JIT Tools</a></h4> -<div class="doc_text"> +<div> <p>Many tools will want to use the JIT features of LLVM. To do this, you simply specify that you want an execution 'engine', and the makefiles will automatically link in the appropriate JIT for the host or an interpreter @@ -365,11 +366,15 @@ </tt></pre> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2><a name="targets">Targets Supported</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section describes each of the targets that can be built using the LLVM Makefile system. Any target can be invoked from any directory but not all are applicable to a given directory (e.g. "check", "dist" and "install" will @@ -424,11 +429,10 @@ <td>Remove built objects from installation directory. </td></tr> </table> -</div> <!-- ======================================================================= --> <h3><a name="all">all (default)</a></h3> -<div class="doc_text"> +<div> <p>When you invoke <tt>make</tt> with no arguments, you are implicitly instructing it to seek the "all" target (goal). This target is used for building the software recursively and will do different things in different @@ -439,14 +443,14 @@ <!-- ======================================================================= --> <h3><a name="all-local">all-local</a></h3> -<div class="doc_text"> +<div> <p>This target is the same as <a href="#all">all</a> but it operates only on the current directory instead of recursively.</p> </div> <!-- ======================================================================= --> <h3><a name="check">check</a></h3> -<div class="doc_text"> +<div> <p>This target can be invoked from anywhere within a project's directories but always invokes the <a href="#check-local"><tt>check-local</tt></a> target in the project's <tt>test</tt> directory, if it exists and has a @@ -463,7 +467,7 @@ <!-- ======================================================================= --> <h3><a name="check-local">check-local</a></h3> -<div class="doc_text"> +<div> <p>This target should be implemented by the <tt>Makefile</tt> in the project's <tt>test</tt> directory. It is invoked by the <tt>check</tt> target elsewhere. Each project is free to define the actions of <tt>check-local</tt> as @@ -474,7 +478,7 @@ <!-- ======================================================================= --> <h3><a name="clean">clean</a></h3> -<div class="doc_text"> +<div> <p>This target cleans the build directory, recursively removing all things that the Makefile builds. The cleaning rules have been made guarded so they shouldn't go awry (via <tt>rm -f $(UNSET_VARIABLE)/*</tt> which will attempt @@ -483,14 +487,14 @@ <!-- ======================================================================= --> <h3><a name="clean-local">clean-local</a></h3> -<div class="doc_text"> +<div> <p>This target does the same thing as <tt>clean</tt> but only for the current (local) directory.</p> </div> <!-- ======================================================================= --> <h3><a name="dist">dist</a></h3> -<div class="doc_text"> +<div> <p>This target builds a distribution tarball. It first builds the entire project using the <tt>all</tt> target and then tars up the necessary files and compresses it. The generated tarball is sufficient for a casual source @@ -499,7 +503,7 @@ <!-- ======================================================================= --> <h3><a name="dist-check">dist-check</a></h3> -<div class="doc_text"> +<div> <p>This target does the same thing as the <tt>dist</tt> target but also checks the distribution tarball. The check is made by unpacking the tarball to a new directory, configuring it, building it, installing it, and then verifying that @@ -511,7 +515,7 @@ <!-- ======================================================================= --> <h3><a name="dist-clean">dist-clean</a></h3> -<div class="doc_text"> +<div> <p>This is a special form of the <tt>clean</tt> clean target. It performs a normal <tt>clean</tt> but also removes things pertaining to building the distribution.</p> @@ -519,7 +523,7 @@ <!-- ======================================================================= --> <h3><a name="install">install</a></h3> -<div class="doc_text"> +<div> <p>This target finalizes shared objects and executables and copies all libraries, headers, executables and documentation to the directory given with the <tt>--prefix</tt> option to <tt>configure</tt>. When completed, @@ -537,7 +541,7 @@ <!-- ======================================================================= --> <h3><a name="preconditions">preconditions</a></h3> -<div class="doc_text"> +<div> <p>This utility target checks to see if the <tt>Makefile</tt> in the object directory is older than the <tt>Makefile</tt> in the source directory and copies it if so. It also reruns the <tt>configure</tt> script if that needs to @@ -548,14 +552,14 @@ <!-- ======================================================================= --> <h3><a name="printvars">printvars</a></h3> -<div class="doc_text"> +<div> <p>This utility target just causes the LLVM makefiles to print out some of the makefile variables so that you can double check how things are set. </p> </div> <!-- ======================================================================= --> <h3><a name="reconfigure">reconfigure</a></h3> -<div class="doc_text"> +<div> <p>This utility target will force a reconfigure of LLVM or your project. It simply runs <tt>$(PROJ_OBJ_ROOT)/config.status --recheck</tt> to rerun the configuration tests and rebuild the configured files. This isn't generally @@ -565,7 +569,7 @@ <!-- ======================================================================= --> <h3><a name="spotless">spotless</a></h3> -<div class="doc_text"> +<div> <p>This utility target, only available when <tt>$(PROJ_OBJ_ROOT)</tt> is not the same as <tt>$(PROJ_SRC_ROOT)</tt>, will completely clean the <tt>$(PROJ_OBJ_ROOT)</tt> directory by removing its content entirely and @@ -577,7 +581,7 @@ <!-- ======================================================================= --> <h3><a name="tags">tags</a></h3> -<div class="doc_text"> +<div> <p>This target will generate a <tt>TAGS</tt> file in the top-level source directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file provides an index of symbol definitions so that the editor can jump you to the @@ -586,17 +590,19 @@ <!-- ======================================================================= --> <h3><a name="uninstall">uninstall</a></h3> -<div class="doc_text"> +<div> <p>This target is the opposite of the <tt>install</tt> target. It removes the header, library and executable files from the installation directories. Note that the directories themselves are not removed because it is not guaranteed that LLVM is the only thing installing there (e.g. --prefix=/usr).</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="variables">Variables</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Variables are used to tell the LLVM Makefile System what to do and to obtain information from it. Variables are also used internally by the LLVM Makefile System. Variable names that contain only the upper case alphabetic @@ -604,11 +610,10 @@ variables are internal to the LLVM Makefile System and should not be relied upon nor modified. The sections below describe how to use the LLVM Makefile variables.</p> -</div> <!-- ======================================================================= --> <h3><a name="setvars">Control Variables</a></h3> -<div class="doc_text"> +<div> <p>Variables listed in the table below should be set <em>before</em> the inclusion of <a href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>. These variables provide input to the LLVM make system that tell it what to do @@ -761,7 +766,7 @@ <!-- ======================================================================= --> <h3><a name="overvars">Override Variables</a></h3> -<div class="doc_text"> +<div> <p>Override variables can be used to override the default values provided by the LLVM makefile system. These variables can be set in several ways:</p> @@ -867,7 +872,7 @@ <!-- ======================================================================= --> <h3><a name="getvars">Readable Variables</a></h3> -<div class="doc_text"> +<div> <p>Variables listed in the table below can be used by the user's Makefile but should not be changed. Changing the value will generally cause the build to go wrong, so don't do it.</p> @@ -938,7 +943,7 @@ <!-- ======================================================================= --> <h3><a name="intvars">Internal Variables</a></h3> -<div class="doc_text"> +<div> <p>Variables listed below are used by the LLVM Makefile System and considered internal. You should not use these variables under any circumstances.</p> @@ -1016,6 +1021,8 @@ </tt></p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/Packaging.html b/docs/Packaging.html index 86d6ca1..7261cc2 100644 --- a/docs/Packaging.html +++ b/docs/Packaging.html @@ -19,7 +19,7 @@ <!--=========================================================================--> <h2><a name="overview">Overview</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>LLVM sets certain default configure options to make sure our developers don't break things for constrained platforms. These settings are not optimal for most @@ -36,7 +36,7 @@ developed against each. <!--=========================================================================--> <h2><a name="compilation">Compile Flags</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>LLVM runs much more quickly when it's optimized and assertions are removed. However, such a build is currently incompatible with users who build without @@ -67,7 +67,7 @@ versions of LLVM in parallel. The following configure flags are relevant: <!--=========================================================================--> <h2><a name="cxx-features">C++ Features</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <dl> <dt>RTTI</dt><dd>LLVM disables RTTI by default. Add <tt>REQUIRES_RTTI=1</tt> @@ -80,7 +80,7 @@ versions of LLVM in parallel. The following configure flags are relevant: <!--=========================================================================--> <h2><a name="shared-library">Shared Library</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>Configure with <tt>--enable-shared</tt> to build <tt>libLLVM-<var>major</var>.<var>minor</var>.(so|dylib)</tt> and link the tools @@ -91,7 +91,7 @@ against it. This saves lots of binary size at the cost of some startup time. <!--=========================================================================--> <h2><a name="deps">Dependencies</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <dl> <dt><tt>--enable-libffi</tt></dt><dd>Depend on <a diff --git a/docs/Passes.html b/docs/Passes.html index 2e024be..b7f70b9 100644 --- a/docs/Passes.html +++ b/docs/Passes.html @@ -56,7 +56,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <!-- ======================================================================= --> <h2><a name="intro">Introduction</a></h2> -<div class="doc_text"> +<div> <p>This document serves as a high level summary of the optimization features that LLVM provides. Optimizations are implemented as Passes that traverse some portion of a program to either collect information or transform the program. @@ -69,8 +69,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! bitcode are neither analysis nor transform passes. <p>The table below provides a quick summary of each pass and links to the more complete pass description later in the document.</p> -</div> -<div class="doc_text" > + <table> <tr><th colspan="2"><b>ANALYSIS PASSES</b></th></tr> <tr><th>Option</th><th>Name</th></tr> @@ -201,19 +200,19 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <tr><td><a href="#view-postdom">-view-postdom</a></td><td>View postdominance tree of function</td></tr> <tr><td><a href="#view-postdom-only">-view-postdom-only</a></td><td>View postdominance tree of function (with no function bodies)</td></tr> </table> + </div> <!-- ======================================================================= --> <h2><a name="analyses">Analysis Passes</a></h2> -<div class="doc_text"> +<div> <p>This section describes the LLVM Analysis Passes.</p> -</div> <!-------------------------------------------------------------------------- --> <h3> <a name="aa-eval">-aa-eval: Exhaustive Alias Analysis Precision Evaluator</a> </h3> -<div class="doc_text"> +<div> <p>This is a simple N^2 alias analysis accuracy evaluator. Basically, for each function in the program, it simply queries to see how the alias analysis implementation answers alias queries between each pair of @@ -227,7 +226,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="basicaa">-basicaa: Basic Alias Analysis (stateless AA impl)</a> </h3> -<div class="doc_text"> +<div> <p> This is the default implementation of the Alias Analysis interface that simply implements a few identities (two different globals cannot alias, @@ -239,7 +238,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="basiccg">-basiccg: Basic CallGraph Construction</a> </h3> -<div class="doc_text"> +<div> <p>Yet to be written.</p> </div> @@ -247,7 +246,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="count-aa">-count-aa: Count Alias Analysis Query Responses</a> </h3> -<div class="doc_text"> +<div> <p> A pass which can be used to count how many alias queries are being made and how the alias analysis implementation being used responds. @@ -258,7 +257,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="debug-aa">-debug-aa: AA use debugger</a> </h3> -<div class="doc_text"> +<div> <p> This simple pass checks alias analysis users to ensure that if they create a new value, they do not query AA without informing it of the value. @@ -275,7 +274,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="domfrontier">-domfrontier: Dominance Frontier Construction</a> </h3> -<div class="doc_text"> +<div> <p> This pass is a simple dominator construction algorithm for finding forward dominator frontiers. @@ -286,7 +285,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="domtree">-domtree: Dominator Tree Construction</a> </h3> -<div class="doc_text"> +<div> <p> This pass is a simple dominator construction algorithm for finding forward dominators. @@ -297,7 +296,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-callgraph">-dot-callgraph: Print Call Graph to 'dot' file</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the call graph into a <code>.dot</code> graph. This graph can then be processed with the "dot" tool @@ -309,7 +308,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-cfg">-dot-cfg: Print CFG of function to 'dot' file</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the control flow graph into a <code>.dot</code> graph. This graph can then be processed with the @@ -321,7 +320,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-cfg-only">-dot-cfg-only: Print CFG of function to 'dot' file (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the control flow graph into a <code>.dot</code> graph, omitting the function bodies. This graph can @@ -334,7 +333,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-dom">-dot-dom: Print dominance tree of function to 'dot' file</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the dominator tree into a <code>.dot</code> graph. This graph can then be processed with the @@ -346,7 +345,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-dom-only">-dot-dom-only: Print dominance tree of function to 'dot' file (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the dominator tree into a <code>.dot</code> graph, omitting the function bodies. This graph can @@ -359,7 +358,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-postdom">-dot-postdom: Print postdominance tree of function to 'dot' file</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the post dominator tree into a <code>.dot</code> graph. This graph can then be processed with the @@ -371,7 +370,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dot-postdom-only">-dot-postdom-only: Print postdominance tree of function to 'dot' file (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the post dominator tree into a <code>.dot</code> graph, omitting the function bodies. This graph can @@ -384,7 +383,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="globalsmodref-aa">-globalsmodref-aa: Simple mod/ref analysis for globals</a> </h3> -<div class="doc_text"> +<div> <p> This simple pass provides alias and mod/ref information for global values that do not have their address taken, and keeps track of whether functions @@ -397,7 +396,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="instcount">-instcount: Counts the various types of Instructions</a> </h3> -<div class="doc_text"> +<div> <p> This pass collects the count of all instructions and reports them </p> @@ -407,7 +406,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="intervals">-intervals: Interval Partition Construction</a> </h3> -<div class="doc_text"> +<div> <p> This analysis calculates and represents the interval partition of a function, or a preexisting interval partition. @@ -423,7 +422,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="iv-users">-iv-users: Induction Variable Users</a> </h3> -<div class="doc_text"> +<div> <p>Bookkeeping for "interesting" users of expressions computed from induction variables.</p> </div> @@ -432,7 +431,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="lazy-value-info">-lazy-value-info: Lazy Value Information Analysis</a> </h3> -<div class="doc_text"> +<div> <p>Interface for lazy computation of value constraint information.</p> </div> @@ -440,7 +439,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="lda">-lda: Loop Dependence Analysis</a> </h3> -<div class="doc_text"> +<div> <p>Loop dependence analysis framework, which is used to detect dependences in memory accesses in loops.</p> </div> @@ -449,7 +448,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="libcall-aa">-libcall-aa: LibCall Alias Analysis</a> </h3> -<div class="doc_text"> +<div> <p>LibCall Alias Analysis.</p> </div> @@ -457,7 +456,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="lint">-lint: Statically lint-checks LLVM IR</a> </h3> -<div class="doc_text"> +<div> <p>This pass statically checks for common and easily-identified constructs which produce undefined or likely unintended behavior in LLVM IR.</p> @@ -488,7 +487,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="loops">-loops: Natural Loop Information</a> </h3> -<div class="doc_text"> +<div> <p> This analysis is used to identify natural loops and determine the loop depth of various nodes of the CFG. Note that the loops identified may actually be @@ -501,7 +500,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="memdep">-memdep: Memory Dependence Analysis</a> </h3> -<div class="doc_text"> +<div> <p> An analysis that determines, for a given memory operation, what preceding memory operations it depends on. It builds on alias analysis information, and @@ -514,7 +513,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="module-debuginfo">-module-debuginfo: Decodes module-level debug info</a> </h3> -<div class="doc_text"> +<div> <p>This pass decodes the debug info metadata in a module and prints in a (sufficiently-prepared-) human-readable form. @@ -527,7 +526,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="no-aa">-no-aa: No Alias Analysis (always returns 'may' alias)</a> </h3> -<div class="doc_text"> +<div> <p> Always returns "I don't know" for alias queries. NoAA is unlike other alias analysis implementations, in that it does not chain to a previous analysis. As @@ -539,7 +538,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="no-profile">-no-profile: No Profile Information</a> </h3> -<div class="doc_text"> +<div> <p> The default "no profile" implementation of the abstract <code>ProfileInfo</code> interface. @@ -550,7 +549,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="postdomfrontier">-postdomfrontier: Post-Dominance Frontier Construction</a> </h3> -<div class="doc_text"> +<div> <p> This pass is a simple post-dominator construction algorithm for finding post-dominator frontiers. @@ -561,7 +560,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="postdomtree">-postdomtree: Post-Dominator Tree Construction</a> </h3> -<div class="doc_text"> +<div> <p> This pass is a simple post-dominator construction algorithm for finding post-dominators. @@ -572,7 +571,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-alias-sets">-print-alias-sets: Alias Set Printer</a> </h3> -<div class="doc_text"> +<div> <p>Yet to be written.</p> </div> @@ -580,7 +579,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-callgraph">-print-callgraph: Print a call graph</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the call graph to standard error in a human-readable form. @@ -591,7 +590,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-callgraph-sccs">-print-callgraph-sccs: Print SCCs of the Call Graph</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the SCCs of the call graph to standard error in a human-readable form. @@ -602,7 +601,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-cfg-sccs">-print-cfg-sccs: Print SCCs of each function CFG</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints the SCCs of each function CFG to standard error in a human-readable form. @@ -613,7 +612,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-dbginfo">-print-dbginfo: Print debug info in human readable form</a> </h3> -<div class="doc_text"> +<div> <p>Pass that prints instructions, and associated debug info:</p> <ul> @@ -627,7 +626,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-dom-info">-print-dom-info: Dominator Info Printer</a> </h3> -<div class="doc_text"> +<div> <p>Dominator Info Printer.</p> </div> @@ -635,7 +634,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-externalfnconstants">-print-externalfnconstants: Print external fn callsites passed constants</a> </h3> -<div class="doc_text"> +<div> <p> This pass, only available in <code>opt</code>, prints out call sites to external functions that are called with constant arguments. This can be @@ -648,7 +647,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-function">-print-function: Print function to stderr</a> </h3> -<div class="doc_text"> +<div> <p> The <code>PrintFunctionPass</code> class is designed to be pipelined with other <code>FunctionPass</code>es, and prints out the functions of the module @@ -660,7 +659,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-module">-print-module: Print module to stderr</a> </h3> -<div class="doc_text"> +<div> <p> This pass simply prints out the entire module when it is executed. </p> @@ -670,7 +669,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="print-used-types">-print-used-types: Find Used Types</a> </h3> -<div class="doc_text"> +<div> <p> This pass is used to seek out all of the types in use by the program. Note that this analysis explicitly does not include types only used by the symbol @@ -681,7 +680,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="profile-estimator">-profile-estimator: Estimate profiling information</a> </h3> -<div class="doc_text"> +<div> <p>Profiling information that estimates the profiling information in a very crude and unimaginative way. </p> @@ -691,7 +690,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="profile-loader">-profile-loader: Load profile information from llvmprof.out</a> </h3> -<div class="doc_text"> +<div> <p> A concrete implementation of profiling information that loads the information from a profile dump file. @@ -702,13 +701,13 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="profile-verifier">-profile-verifier: Verify profiling information</a> </h3> -<div class="doc_text"> +<div> <p>Pass that checks profiling information for plausibility.</p> </div> <h3> <a name="regions">-regions: Detect single entry single exit regions</a> </h3> -<div class="doc_text"> +<div> <p> The <code>RegionInfo</code> pass detects single entry single exit regions in a function, where a region is defined as any subgraph that is connected to the @@ -721,7 +720,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="scalar-evolution">-scalar-evolution: Scalar Evolution Analysis</a> </h3> -<div class="doc_text"> +<div> <p> The <code>ScalarEvolution</code> analysis can be used to analyze and catagorize scalar expressions in loops. It specializes in recognizing general @@ -740,7 +739,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="scev-aa">-scev-aa: ScalarEvolution-based Alias Analysis</a> </h3> -<div class="doc_text"> +<div> <p>Simple alias analysis implemented in terms of ScalarEvolution queries. This differs from traditional loop dependence analysis in that it tests @@ -756,22 +755,23 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="targetdata">-targetdata: Target Data Layout</a> </h3> -<div class="doc_text"> +<div> <p>Provides other passes access to information on how the size and alignment required by the the target ABI for various data types.</p> </div> +</div> + <!-- ======================================================================= --> <h2><a name="transforms">Transform Passes</a></h2> -<div class="doc_text"> +<div> <p>This section describes the LLVM Transform Passes.</p> -</div> <!-------------------------------------------------------------------------- --> <h3> <a name="adce">-adce: Aggressive Dead Code Elimination</a> </h3> -<div class="doc_text"> +<div> <p>ADCE aggressively tries to eliminate code. This pass is similar to <a href="#dce">DCE</a> but it assumes that values are dead until proven otherwise. This is similar to <a href="#sccp">SCCP</a>, except applied to @@ -782,7 +782,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="always-inline">-always-inline: Inliner for always_inline functions</a> </h3> -<div class="doc_text"> +<div> <p>A custom inliner that handles only functions that are marked as "always inline".</p> </div> @@ -791,7 +791,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="argpromotion">-argpromotion: Promote 'by reference' arguments to scalars</a> </h3> -<div class="doc_text"> +<div> <p> This pass promotes "by reference" arguments to be "by value" arguments. In practice, this means looking for internal functions that have pointer @@ -822,7 +822,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="block-placement">-block-placement: Profile Guided Basic Block Placement</a> </h3> -<div class="doc_text"> +<div> <p>This pass is a very simple profile guided basic block placement algorithm. The idea is to put frequently executed blocks together at the start of the function and hopefully increase the number of fall-through conditional @@ -834,7 +834,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="break-crit-edges">-break-crit-edges: Break critical edges in CFG</a> </h3> -<div class="doc_text"> +<div> <p> Break all of the critical edges in the CFG by inserting a dummy basic block. It may be "required" by passes that cannot deal with critical edges. This @@ -847,7 +847,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="codegenprepare">-codegenprepare: Optimize for code generation</a> </h3> -<div class="doc_text"> +<div> This pass munges the code in the input function to better prepare it for SelectionDAG-based code generation. This works around limitations in it's basic-block-at-a-time approach. It should eventually be removed. @@ -857,7 +857,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="constmerge">-constmerge: Merge Duplicate Global Constants</a> </h3> -<div class="doc_text"> +<div> <p> Merges duplicate global constants together into a single constant that is shared. This is useful because some passes (ie TraceValues) insert a lot of @@ -870,7 +870,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="constprop">-constprop: Simple constant propagation</a> </h3> -<div class="doc_text"> +<div> <p>This file implements constant propagation and merging. It looks for instructions involving only constant operands and replaces them with a constant value instead of an instruction. For example:</p> @@ -886,7 +886,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dce">-dce: Dead Code Elimination</a> </h3> -<div class="doc_text"> +<div> <p> Dead code elimination is similar to <a href="#die">dead instruction elimination</a>, but it rechecks instructions that were used by removed @@ -898,7 +898,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="deadargelim">-deadargelim: Dead Argument Elimination</a> </h3> -<div class="doc_text"> +<div> <p> This pass deletes dead arguments from internal functions. Dead argument elimination removes arguments which are directly dead, as well as arguments @@ -916,7 +916,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="deadtypeelim">-deadtypeelim: Dead Type Elimination</a> </h3> -<div class="doc_text"> +<div> <p> This pass is used to cleanup the output of GCC. It eliminate names for types that are unused in the entire translation unit, using the <a @@ -928,7 +928,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="die">-die: Dead Instruction Elimination</a> </h3> -<div class="doc_text"> +<div> <p> Dead instruction elimination performs a single pass over the function, removing instructions that are obviously dead. @@ -939,7 +939,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="dse">-dse: Dead Store Elimination</a> </h3> -<div class="doc_text"> +<div> <p> A trivial dead store elimination that only considers basic-block local redundant stores. @@ -950,7 +950,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="functionattrs">-functionattrs: Deduce function attributes</a> </h3> -<div class="doc_text"> +<div> <p>A simple interprocedural pass which walks the call-graph, looking for functions which do not access or only read non-local memory, and marking them readnone/readonly. In addition, it marks function arguments (of pointer type) @@ -965,7 +965,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="globaldce">-globaldce: Dead Global Elimination</a> </h3> -<div class="doc_text"> +<div> <p> This transform is designed to eliminate unreachable internal globals from the program. It uses an aggressive algorithm, searching out globals that are @@ -979,7 +979,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="globalopt">-globalopt: Global Variable Optimizer</a> </h3> -<div class="doc_text"> +<div> <p> This pass transforms simple global variables that never have their address taken. If obviously true, it marks read/write globals as constant, deletes @@ -991,7 +991,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="gvn">-gvn: Global Value Numbering</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs global value numbering to eliminate fully and partially redundant instructions. It also performs redundant load elimination. @@ -1002,7 +1002,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="indvars">-indvars: Canonicalize Induction Variables</a> </h3> -<div class="doc_text"> +<div> <p> This transformation analyzes and transforms the induction variables (and computations derived from them) into simpler forms suitable for subsequent @@ -1053,7 +1053,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="inline">-inline: Function Integration/Inlining</a> </h3> -<div class="doc_text"> +<div> <p> Bottom-up inlining of functions into callees. </p> @@ -1063,7 +1063,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="insert-edge-profiling">-insert-edge-profiling: Insert instrumentation for edge profiling</a> </h3> -<div class="doc_text"> +<div> <p> This pass instruments the specified program with counters for edge profiling. Edge profiling can give a reasonable approximation of the hot paths through a @@ -1081,7 +1081,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="insert-optimal-edge-profiling">-insert-optimal-edge-profiling: Insert optimal instrumentation for edge profiling</a> </h3> -<div class="doc_text"> +<div> <p>This pass instruments the specified program with counters for edge profiling. Edge profiling can give a reasonable approximation of the hot paths through a program, and is used for a wide variety of program transformations. @@ -1092,7 +1092,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="instcombine">-instcombine: Combine redundant instructions</a> </h3> -<div class="doc_text"> +<div> <p> Combine instructions to form fewer, simple instructions. This pass does not modify the CFG This pass is where algebraic @@ -1146,7 +1146,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="internalize">-internalize: Internalize Global Symbols</a> </h3> -<div class="doc_text"> +<div> <p> This pass loops over all of the functions in the input module, looking for a main function. If a main function is found, all other functions and all @@ -1158,7 +1158,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="ipconstprop">-ipconstprop: Interprocedural constant propagation</a> </h3> -<div class="doc_text"> +<div> <p> This pass implements an <em>extremely</em> simple interprocedural constant propagation pass. It could certainly be improved in many different ways, @@ -1172,7 +1172,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="ipsccp">-ipsccp: Interprocedural Sparse Conditional Constant Propagation</a> </h3> -<div class="doc_text"> +<div> <p> An interprocedural variant of <a href="#sccp">Sparse Conditional Constant Propagation</a>. @@ -1183,7 +1183,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if ! <h3> <a name="jump-threading">-jump-threading: Jump Threading</a> </h3> -<div class="doc_text"> +<div> <p> Jump threading tries to find distinct threads of control flow running through a basic block. This pass looks at blocks that have multiple predecessors and @@ -1212,7 +1212,7 @@ if (X < 3) {</pre> <h3> <a name="lcssa">-lcssa: Loop-Closed SSA Form Pass</a> </h3> -<div class="doc_text"> +<div> <p> This pass transforms loops by placing phi nodes at the end of the loops for all values that are live across the loop boundary. For example, it turns @@ -1241,7 +1241,7 @@ if (X < 3) {</pre> <h3> <a name="licm">-licm: Loop Invariant Code Motion</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs loop invariant code motion, attempting to remove as much code from the body of a loop as possible. It does this by either hoisting @@ -1278,7 +1278,7 @@ if (X < 3) {</pre> <h3> <a name="loop-deletion">-loop-deletion: Delete dead loops</a> </h3> -<div class="doc_text"> +<div> <p> This file implements the Dead Loop Deletion Pass. This pass is responsible for eliminating loops with non-infinite computable trip counts that have no @@ -1291,7 +1291,7 @@ if (X < 3) {</pre> <h3> <a name="loop-extract">-loop-extract: Extract loops into new functions</a> </h3> -<div class="doc_text"> +<div> <p> A pass wrapper around the <code>ExtractLoop()</code> scalar transformation to extract each top-level loop into its own new function. If the loop is the @@ -1304,7 +1304,7 @@ if (X < 3) {</pre> <h3> <a name="loop-extract-single">-loop-extract-single: Extract at most one loop into a new function</a> </h3> -<div class="doc_text"> +<div> <p> Similar to <a href="#loop-extract">Extract loops into new functions</a>, this pass extracts one natural loop from the program into a function if it @@ -1316,7 +1316,7 @@ if (X < 3) {</pre> <h3> <a name="loop-reduce">-loop-reduce: Loop Strength Reduction</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs a strength reduction on array references inside loops that have as one or more of their components the loop induction variable. This is @@ -1330,7 +1330,7 @@ if (X < 3) {</pre> <h3> <a name="loop-rotate">-loop-rotate: Rotate Loops</a> </h3> -<div class="doc_text"> +<div> <p>A simple loop rotation transformation.</p> </div> @@ -1338,7 +1338,7 @@ if (X < 3) {</pre> <h3> <a name="loop-simplify">-loop-simplify: Canonicalize natural loops</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs several transformations to transform natural loops into a simpler form, which makes subsequent analyses and transformations simpler and @@ -1379,7 +1379,7 @@ if (X < 3) {</pre> <h3> <a name="loop-unroll">-loop-unroll: Unroll loops</a> </h3> -<div class="doc_text"> +<div> <p> This pass implements a simple loop unroller. It works best when loops have been canonicalized by the <a href="#indvars"><tt>-indvars</tt></a> pass, @@ -1391,7 +1391,7 @@ if (X < 3) {</pre> <h3> <a name="loop-unswitch">-loop-unswitch: Unswitch loops</a> </h3> -<div class="doc_text"> +<div> <p> This pass transforms loops that contain branches on loop-invariant conditions to have multiple loops. For example, it turns the left into the right code: @@ -1421,7 +1421,7 @@ if (X < 3) {</pre> <h3> <a name="loweratomic">-loweratomic: Lower atomic intrinsics to non-atomic form</a> </h3> -<div class="doc_text"> +<div> <p> This pass lowers atomic intrinsics to non-atomic form for use in a known non-preemptible environment. @@ -1439,7 +1439,7 @@ if (X < 3) {</pre> <h3> <a name="lowerinvoke">-lowerinvoke: Lower invoke and unwind, for unwindless code generators</a> </h3> -<div class="doc_text"> +<div> <p> This transformation is designed for use by code generators which do not yet support stack unwinding. This pass supports two models of exception handling @@ -1480,7 +1480,7 @@ if (X < 3) {</pre> <h3> <a name="lowersetjmp">-lowersetjmp: Lower Set Jump</a> </h3> -<div class="doc_text"> +<div> <p> Lowers <tt>setjmp</tt> and <tt>longjmp</tt> to use the LLVM invoke and unwind instructions as necessary. @@ -1509,7 +1509,7 @@ if (X < 3) {</pre> <h3> <a name="lowerswitch">-lowerswitch: Lower SwitchInst's to branches</a> </h3> -<div class="doc_text"> +<div> <p> Rewrites <tt>switch</tt> instructions with a sequence of branches, which allows targets to get away with not implementing the switch instruction until @@ -1521,7 +1521,7 @@ if (X < 3) {</pre> <h3> <a name="mem2reg">-mem2reg: Promote Memory to Register</a> </h3> -<div class="doc_text"> +<div> <p> This file promotes memory references to be register references. It promotes <tt>alloca</tt> instructions which only have <tt>load</tt>s and @@ -1537,7 +1537,7 @@ if (X < 3) {</pre> <h3> <a name="memcpyopt">-memcpyopt: MemCpy Optimization</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs various transformations related to eliminating memcpy calls, or transforming sets of stores into memset's. @@ -1548,7 +1548,7 @@ if (X < 3) {</pre> <h3> <a name="mergefunc">-mergefunc: Merge Functions</a> </h3> -<div class="doc_text"> +<div> <p>This pass looks for equivalent functions that are mergable and folds them. A hash is computed from the function, based on its type and number of @@ -1569,7 +1569,7 @@ if (X < 3) {</pre> <h3> <a name="mergereturn">-mergereturn: Unify function exit nodes</a> </h3> -<div class="doc_text"> +<div> <p> Ensure that functions have at most one <tt>ret</tt> instruction in them. Additionally, it keeps track of which node is the new exit node of the CFG. @@ -1580,7 +1580,7 @@ if (X < 3) {</pre> <h3> <a name="partial-inliner">-partial-inliner: Partial Inliner</a> </h3> -<div class="doc_text"> +<div> <p>This pass performs partial inlining, typically by inlining an if statement that surrounds the body of the function. </p> @@ -1590,7 +1590,7 @@ if (X < 3) {</pre> <h3> <a name="prune-eh">-prune-eh: Remove unused exception handling info</a> </h3> -<div class="doc_text"> +<div> <p> This file implements a simple interprocedural pass which walks the call-graph, turning <tt>invoke</tt> instructions into <tt>call</tt> instructions if and @@ -1603,7 +1603,7 @@ if (X < 3) {</pre> <h3> <a name="reassociate">-reassociate: Reassociate expressions</a> </h3> -<div class="doc_text"> +<div> <p> This pass reassociates commutative expressions in an order that is designed to promote better constant propagation, GCSE, LICM, PRE, etc. @@ -1626,7 +1626,7 @@ if (X < 3) {</pre> <h3> <a name="reg2mem">-reg2mem: Demote all values to stack slots</a> </h3> -<div class="doc_text"> +<div> <p> This file demotes all registers to memory references. It is intented to be the inverse of <a href="#mem2reg"><tt>-mem2reg</tt></a>. By converting to @@ -1643,7 +1643,7 @@ if (X < 3) {</pre> <h3> <a name="scalarrepl">-scalarrepl: Scalar Replacement of Aggregates (DT)</a> </h3> -<div class="doc_text"> +<div> <p> The well-known scalar replacement of aggregates transformation. This transform breaks up <tt>alloca</tt> instructions of aggregate type (structure @@ -1665,7 +1665,7 @@ if (X < 3) {</pre> <h3> <a name="sccp">-sccp: Sparse Conditional Constant Propagation</a> </h3> -<div class="doc_text"> +<div> <p> Sparse conditional constant propagation and merging, which can be summarized as: @@ -1688,7 +1688,7 @@ if (X < 3) {</pre> <h3> <a name="simplify-libcalls">-simplify-libcalls: Simplify well-known library calls</a> </h3> -<div class="doc_text"> +<div> <p> Applies a variety of small optimizations for calls to specific well-known function calls (e.g. runtime library functions). For example, a call @@ -1701,7 +1701,7 @@ if (X < 3) {</pre> <h3> <a name="simplifycfg">-simplifycfg: Simplify the CFG</a> </h3> -<div class="doc_text"> +<div> <p> Performs dead code elimination and basic block merging. Specifically: </p> @@ -1720,7 +1720,7 @@ if (X < 3) {</pre> <h3> <a name="sink">-sink: Code sinking</a> </h3> -<div class="doc_text"> +<div> <p>This pass moves instructions into successor blocks, when possible, so that they aren't executed on paths where their results aren't needed. </p> @@ -1730,7 +1730,7 @@ if (X < 3) {</pre> <h3> <a name="sretpromotion">-sretpromotion: Promote sret arguments to multiple ret values</a> </h3> -<div class="doc_text"> +<div> <p> This pass finds functions that return a struct (using a pointer to the struct as the first argument of the function, marked with the '<tt>sret</tt>' attribute) and @@ -1753,7 +1753,7 @@ if (X < 3) {</pre> <h3> <a name="strip">-strip: Strip all symbols from a module</a> </h3> -<div class="doc_text"> +<div> <p> performs code stripping. this transformation can delete: </p> @@ -1775,7 +1775,7 @@ if (X < 3) {</pre> <h3> <a name="strip-dead-debug-info">-strip-dead-debug-info: Strip debug info for unused symbols</a> </h3> -<div class="doc_text"> +<div> <p> performs code stripping. this transformation can delete: </p> @@ -1797,7 +1797,7 @@ if (X < 3) {</pre> <h3> <a name="strip-dead-prototypes">-strip-dead-prototypes: Strip Unused Function Prototypes</a> </h3> -<div class="doc_text"> +<div> <p> This pass loops over all of the functions in the input module, looking for dead declarations and removes them. Dead declarations are declarations of @@ -1810,7 +1810,7 @@ if (X < 3) {</pre> <h3> <a name="strip-debug-declare">-strip-debug-declare: Strip all llvm.dbg.declare intrinsics</a> </h3> -<div class="doc_text"> +<div> <p>This pass implements code stripping. Specifically, it can delete:</p> <ul> <li>names for virtual registers</li> @@ -1828,7 +1828,7 @@ if (X < 3) {</pre> <h3> <a name="strip-nondebug">-strip-nondebug: Strip all symbols, except dbg symbols, from a module</a> </h3> -<div class="doc_text"> +<div> <p>This pass implements code stripping. Specifically, it can delete:</p> <ul> <li>names for virtual registers</li> @@ -1846,7 +1846,7 @@ if (X < 3) {</pre> <h3> <a name="tailcallelim">-tailcallelim: Tail Call Elimination</a> </h3> -<div class="doc_text"> +<div> <p> This file transforms calls of the current function (self recursion) followed by a return instruction with a branch to the entry of the function, creating @@ -1878,7 +1878,7 @@ if (X < 3) {</pre> <h3> <a name="tailduplicate">-tailduplicate: Tail Duplication</a> </h3> -<div class="doc_text"> +<div> <p> This pass performs a limited form of tail duplication, intended to simplify CFGs by removing some unconditional branches. This pass is necessary to @@ -1888,17 +1888,18 @@ if (X < 3) {</pre> </p> </div> +</div> + <!-- ======================================================================= --> <h2><a name="utilities">Utility Passes</a></h2> -<div class="doc_text"> +<div> <p>This section describes the LLVM Utility Passes.</p> -</div> <!-------------------------------------------------------------------------- --> <h3> <a name="deadarghaX0r">-deadarghaX0r: Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</a> </h3> -<div class="doc_text"> +<div> <p> Same as dead argument elimination, but deletes arguments to functions which are external. This is only for use by <a @@ -1909,7 +1910,7 @@ if (X < 3) {</pre> <h3> <a name="extract-blocks">-extract-blocks: Extract Basic Blocks From Module (for bugpoint use)</a> </h3> -<div class="doc_text"> +<div> <p> This pass is used by bugpoint to extract all blocks from the module into their own functions.</p> @@ -1919,7 +1920,7 @@ if (X < 3) {</pre> <h3> <a name="instnamer">-instnamer: Assign names to anonymous instructions</a> </h3> -<div class="doc_text"> +<div> <p>This is a little utility pass that gives instructions names, this is mostly useful when diffing the effect of an optimization because deleting an unnamed instruction can change all other instruction numbering, making the @@ -1931,7 +1932,7 @@ if (X < 3) {</pre> <h3> <a name="preverify">-preverify: Preliminary module verification</a> </h3> -<div class="doc_text"> +<div> <p> Ensures that the module is in the form required by the <a href="#verifier">Module Verifier</a> pass. @@ -1947,7 +1948,7 @@ if (X < 3) {</pre> <h3> <a name="verify">-verify: Module Verifier</a> </h3> -<div class="doc_text"> +<div> <p> Verifies an LLVM IR code. This is useful to run after an optimization which is undergoing testing. Note that <tt>llvm-as</tt> verifies its input before @@ -1998,7 +1999,7 @@ if (X < 3) {</pre> <h3> <a name="view-cfg">-view-cfg: View CFG of function</a> </h3> -<div class="doc_text"> +<div> <p> Displays the control flow graph using the GraphViz tool. </p> @@ -2008,7 +2009,7 @@ if (X < 3) {</pre> <h3> <a name="view-cfg-only">-view-cfg-only: View CFG of function (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> Displays the control flow graph using the GraphViz tool, but omitting function bodies. @@ -2019,7 +2020,7 @@ if (X < 3) {</pre> <h3> <a name="view-dom">-view-dom: View dominance tree of function</a> </h3> -<div class="doc_text"> +<div> <p> Displays the dominator tree using the GraphViz tool. </p> @@ -2029,7 +2030,7 @@ if (X < 3) {</pre> <h3> <a name="view-dom-only">-view-dom-only: View dominance tree of function (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> Displays the dominator tree using the GraphViz tool, but omitting function bodies. @@ -2040,7 +2041,7 @@ if (X < 3) {</pre> <h3> <a name="view-postdom">-view-postdom: View postdominance tree of function</a> </h3> -<div class="doc_text"> +<div> <p> Displays the post dominator tree using the GraphViz tool. </p> @@ -2050,13 +2051,15 @@ if (X < 3) {</pre> <h3> <a name="view-postdom-only">-view-postdom-only: View postdominance tree of function (with no function bodies)</a> </h3> -<div class="doc_text"> +<div> <p> Displays the post dominator tree using the GraphViz tool, but omitting function bodies. </p> </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index b29c582..060bbb6 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -215,7 +215,7 @@ with another <tt>Value</tt></a> </li> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is meant to highlight some of the important classes and interfaces available in the LLVM source-base. This manual is not @@ -247,19 +247,17 @@ href="/doxygen/InstVisitor_8h-source.html">InstVisitor</a></tt> template.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section contains general information that is useful if you are working in the LLVM source-base, but that isn't specific to any particular API.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="stl">The C++ Standard Template Library</a> </h3> -<div class="doc_text"> +<div> <p>LLVM makes heavy use of the C++ Standard Template Library (STL), perhaps much more than you are used to, or have seen before. Because of @@ -309,7 +307,7 @@ to write maintainable code more than where to put your curly braces.</p> <a name="stl">Other useful references</a> </h3> -<div class="doc_text"> +<div> <ol> <li><a href="http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html">Using @@ -318,26 +316,26 @@ static and shared libraries across platforms</a></li> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="apis">Important and useful LLVM APIs</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Here we highlight some LLVM APIs that are generally useful and good to know about when writing transformations.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="isa">The <tt>isa<></tt>, <tt>cast<></tt> and <tt>dyn_cast<></tt> templates</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM source-base makes extensive use of a custom form of RTTI. These templates have many similarities to the C++ <tt>dynamic_cast<></tt> @@ -447,7 +445,7 @@ are lots of examples in the LLVM source base.</p> and <tt>Twine</tt> classes)</a> </h3> -<div class="doc_text"> +<div> <p>Although LLVM generally does not do much string manipulation, we do have several important APIs which take strings. Two important examples are the @@ -461,14 +459,12 @@ clients to perform a heap allocation which is usually unnecessary. Instead, many LLVM APIs use a <tt>StringRef</tt> or a <tt>const Twine&</tt> for passing strings efficiently.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="StringRef">The <tt>StringRef</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>StringRef</tt> data type represents a reference to a constant string (a character array and a length) and supports the common operations available @@ -508,7 +504,7 @@ small and pervasive enough in LLVM that it should always be passed by value.</p> <a name="Twine">The <tt>Twine</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>Twine</tt> class is an efficient way for APIs to accept concatenated strings. For example, a common LLVM paradigm is to name one instruction based on @@ -539,13 +535,14 @@ accept concatenated strings.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt> option</a> </h3> -<div class="doc_text"> +<div> <p>Often when working on your pass you will put a bunch of debugging printouts and other code into your pass. After you get it working, you want to remove @@ -591,15 +588,13 @@ enable or disable it directly in gdb. Just use "<tt>set DebugFlag=0</tt>" or program hasn't been started yet, you can always just run it with <tt>-debug</tt>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and the <tt>-debug-only</tt> option</a> </h4> -<div class="doc_text"> +<div> <p>Sometimes you may find yourself in a situation where enabling <tt>-debug</tt> just turns on <b>too much</b> information (such as when working on the code @@ -667,13 +662,15 @@ DEBUG_WITH_TYPE("", errs() << "No debug type (2)\n"); </div> +</div> + <!-- ======================================================================= --> <h3> <a name="Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt> option</a> </h3> -<div class="doc_text"> +<div> <p>The "<tt><a href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file @@ -772,7 +769,7 @@ maintainable and useful.</p> <a name="ViewGraph">Viewing graphs while debugging code</a> </h3> -<div class="doc_text"> +<div> <p>Several of the important data structures in LLVM are graphs: for example CFGs made out of LLVM <a href="#BasicBlock">BasicBlock</a>s, CFGs made out of @@ -816,13 +813,15 @@ attributes, then you can <tt>call DAG.clearGraphAttrs()</tt>. </p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="datastructure">Picking the Right Data Structure for a Task</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM has a plethora of data structures in the <tt>llvm/ADT/</tt> directory, and we commonly use STL data structures. This section describes the trade-offs @@ -878,24 +877,21 @@ elements (but could contain many), for example, it's much better to use . Doing so avoids (relatively) expensive malloc/free calls, which dwarf the cost of adding the elements to the container. </p> -</div> - <!-- ======================================================================= --> <h3> <a name="ds_sequential">Sequential Containers (std::vector, std::list, etc)</a> </h3> -<div class="doc_text"> +<div> There are a variety of sequential containers available for you, based on your needs. Pick the first in this section that will do what you want. -</div> <!-- _______________________________________________________________________ --> <h4> <a name="dss_arrayref">llvm/ADT/ArrayRef.h</a> </h4> -<div class="doc_text"> +<div> <p>The llvm::ArrayRef class is the preferred class to use in an interface that accepts a sequential list of elements in memory and just reads from them. By taking an ArrayRef, the API can be passed a fixed size array, an std::vector, @@ -910,7 +906,7 @@ needs. Pick the first in this section that will do what you want. <a name="dss_fixedarrays">Fixed Size Arrays</a> </h4> -<div class="doc_text"> +<div> <p>Fixed size arrays are very simple and very fast. They are good if you know exactly how many elements you have, or you have a (low) upper bound on how many you have.</p> @@ -921,7 +917,7 @@ you have.</p> <a name="dss_heaparrays">Heap Allocated Arrays</a> </h4> -<div class="doc_text"> +<div> <p>Heap allocated arrays (new[] + delete[]) are also simple. They are good if the number of elements is variable, if you know how many elements you will need before the array is allocated, and if the array is usually large (if not, @@ -937,7 +933,7 @@ construct those elements actually used).</p> <a name="dss_smallvector">"llvm/ADT/SmallVector.h"</a> </h4> -<div class="doc_text"> +<div> <p><tt>SmallVector<Type, N></tt> is a simple class that looks and smells just like <tt>vector<Type></tt>: it supports efficient iteration, lays out elements in memory order (so you can @@ -966,7 +962,7 @@ SmallVectors are most useful when on the stack.</p> <a name="dss_vector"><vector></a> </h4> -<div class="doc_text"> +<div> <p> std::vector is well loved and respected. It is useful when SmallVector isn't: when the size of the vector is often large (thus the small optimization will @@ -1008,7 +1004,7 @@ the loop.</p> <a name="dss_deque"><deque></a> </h4> -<div class="doc_text"> +<div> <p>std::deque is, in some senses, a generalized version of std::vector. Like std::vector, it provides constant time random access and other similar properties, but it also provides efficient access to the front of the list. It @@ -1024,7 +1020,7 @@ something cheaper.</p> <a name="dss_list"><list></a> </h4> -<div class="doc_text"> +<div> <p>std::list is an extremely inefficient class that is rarely useful. It performs a heap allocation for every element inserted into it, thus having an extremely high constant factor, particularly for small data types. std::list @@ -1042,7 +1038,7 @@ not invalidate iterator or pointers to other elements in the list.</p> <a name="dss_ilist">llvm/ADT/ilist.h</a> </h4> -<div class="doc_text"> +<div> <p><tt>ilist<T></tt> implements an 'intrusive' doubly-linked list. It is intrusive, because it requires the element to store and provide access to the prev/next pointers for the list.</p> @@ -1072,7 +1068,7 @@ Related classes of interest are explained in the following subsections: <a name="dss_ilist_traits">ilist_traits</a> </h4> -<div class="doc_text"> +<div> <p><tt>ilist_traits<T></tt> is <tt>ilist<T></tt>'s customization mechanism. <tt>iplist<T></tt> (and consequently <tt>ilist<T></tt>) publicly derive from this traits class.</p> @@ -1083,7 +1079,7 @@ publicly derive from this traits class.</p> <a name="dss_iplist">iplist</a> </h4> -<div class="doc_text"> +<div> <p><tt>iplist<T></tt> is <tt>ilist<T></tt>'s base and as such supports a slightly narrower interface. Notably, inserters from <tt>T&</tt> are absent.</p> @@ -1097,7 +1093,7 @@ used for a wide variety of customizations.</p> <a name="dss_ilist_node">llvm/ADT/ilist_node.h</a> </h4> -<div class="doc_text"> +<div> <p><tt>ilist_node<T></tt> implements a the forward and backward links that are expected by the <tt>ilist<T></tt> (and analogous containers) in the default manner.</p> @@ -1112,7 +1108,7 @@ in the default manner.</p> <a name="dss_ilist_sentinel">Sentinels</a> </h4> -<div class="doc_text"> +<div> <p><tt>ilist</tt>s have another specialty that must be considered. To be a good citizen in the C++ ecosystem, it needs to support the standard container operations, such as <tt>begin</tt> and <tt>end</tt> iterators, etc. Also, the @@ -1150,7 +1146,7 @@ field in the ghostly sentinel which can be legally accessed.</p> <a name="dss_other">Other Sequential Container options</a> </h4> -<div class="doc_text"> +<div> <p>Other STL containers are available, such as std::string.</p> <p>There are also various STL adapter classes such as std::queue, @@ -1159,27 +1155,25 @@ underlying container but don't affect the cost of the container itself.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a> </h3> -<div class="doc_text"> +<div> <p>Set-like containers are useful when you need to canonicalize multiple values into a single representation. There are several different choices for how to do this, providing various trade-offs.</p> -</div> - - <!-- _______________________________________________________________________ --> <h4> <a name="dss_sortedvectorset">A sorted 'vector'</a> </h4> -<div class="doc_text"> +<div> <p>If you intend to insert a lot of elements, then do a lot of queries, a great approach is to use a vector (or other sequential container) with @@ -1201,7 +1195,7 @@ efficiently queried with a standard binary or radix search.</p> <a name="dss_smallset">"llvm/ADT/SmallSet.h"</a> </h4> -<div class="doc_text"> +<div> <p>If you have a set-like data structure that is usually small and whose elements are reasonably small, a <tt>SmallSet<Type, N></tt> is a good choice. This set @@ -1224,7 +1218,7 @@ and erasing, but does not support iteration.</p> <a name="dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a> </h4> -<div class="doc_text"> +<div> <p>SmallPtrSet has all the advantages of <tt>SmallSet</tt> (and a <tt>SmallSet</tt> of pointers is transparently implemented with a <tt>SmallPtrSet</tt>), but also supports iterators. If @@ -1244,7 +1238,7 @@ visited in sorted order.</p> <a name="dss_denseset">"llvm/ADT/DenseSet.h"</a> </h4> -<div class="doc_text"> +<div> <p> DenseSet is a simple quadratically probed hash table. It excels at supporting @@ -1263,7 +1257,7 @@ href="#dss_densemap">DenseMap</a> has. <a name="dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a> </h4> -<div class="doc_text"> +<div> <p> FoldingSet is an aggregate class that is really good at uniquing @@ -1300,7 +1294,7 @@ elements. <a name="dss_set"><set></a> </h4> -<div class="doc_text"> +<div> <p><tt>std::set</tt> is a reasonable all-around set class, which is decent at many things but great at nothing. std::set allocates memory for each element @@ -1325,7 +1319,7 @@ std::set is almost never a good choice.</p> <a name="dss_setvector">"llvm/ADT/SetVector.h"</a> </h4> -<div class="doc_text"> +<div> <p>LLVM's SetVector<Type> is an adapter class that combines your choice of a set-like container along with a <a href="#ds_sequential">Sequential Container</a>. The important property @@ -1365,7 +1359,7 @@ heap traffic.</p> <a name="dss_uniquevector">"llvm/ADT/UniqueVector.h"</a> </h4> -<div class="doc_text"> +<div> <p> UniqueVector is similar to <a href="#dss_setvector">SetVector</a>, but it @@ -1385,7 +1379,7 @@ factors, and produces a lot of malloc traffic. It should be avoided.</p> <a name="dss_otherset">Other Set-Like Container Options</a> </h4> -<div class="doc_text"> +<div> <p> The STL provides several other options, such as std::multiset and the various @@ -1401,22 +1395,23 @@ better.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="ds_map">Map-Like Containers (std::map, DenseMap, etc)</a> </h3> -<div class="doc_text"> +<div> Map-like containers are useful when you want to associate data to a key. As usual, there are a lot of different ways to do this. :) -</div> <!-- _______________________________________________________________________ --> <h4> <a name="dss_sortedvectormap">A sorted 'vector'</a> </h4> -<div class="doc_text"> +<div> <p> If your usage pattern follows a strict insert-then-query approach, you can @@ -1433,7 +1428,7 @@ vectors for sets. <a name="dss_stringmap">"llvm/ADT/StringMap.h"</a> </h4> -<div class="doc_text"> +<div> <p> Strings are commonly used as keys in maps, and they are difficult to support @@ -1467,7 +1462,7 @@ copies a string if a value is inserted into the table.</p> <a name="dss_indexedmap">"llvm/ADT/IndexedMap.h"</a> </h4> -<div class="doc_text"> +<div> <p> IndexedMap is a specialized container for mapping small dense integers (or values that can be mapped to small dense integers) to some other type. It is @@ -1487,7 +1482,7 @@ virtual register ID).</p> <a name="dss_densemap">"llvm/ADT/DenseMap.h"</a> </h4> -<div class="doc_text"> +<div> <p> DenseMap is a simple quadratically probed hash table. It excels at supporting @@ -1513,7 +1508,7 @@ inserted into the map) that it needs internally.</p> <a name="dss_valuemap">"llvm/ADT/ValueMap.h"</a> </h4> -<div class="doc_text"> +<div> <p> ValueMap is a wrapper around a <a href="#dss_densemap">DenseMap</a> mapping @@ -1530,7 +1525,7 @@ a <code>Config</code> parameter to the ValueMap template.</p> <a name="dss_intervalmap">"llvm/ADT/IntervalMap.h"</a> </h4> -<div class="doc_text"> +<div> <p> IntervalMap is a compact map for small keys and values. It maps key intervals instead of single keys, and it will automatically coalesce adjacent @@ -1547,7 +1542,7 @@ as STL iterators. The heavyweight iterators allow a smaller data structure.</p> <a name="dss_map"><map></a> </h4> -<div class="doc_text"> +<div> <p> std::map has similar characteristics to <a href="#dss_set">std::set</a>: it uses @@ -1567,7 +1562,7 @@ another element takes place).</p> <a name="dss_inteqclasses">"llvm/ADT/IntEqClasses.h"</a> </h4> -<div class="doc_text"> +<div> <p>IntEqClasses provides a compact representation of equivalence classes of small integers. Initially, each integer in the range 0..n-1 has its own @@ -1587,7 +1582,7 @@ it can be edited again.</p> <a name="dss_othermap">Other Map-Like Container Options</a> </h4> -<div class="doc_text"> +<div> <p> The STL provides several other options, such as std::multimap and the various @@ -1601,12 +1596,14 @@ always better.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="ds_string">String-like containers</a> </h3> -<div class="doc_text"> +<div> <p> TODO: const char* vs stringref vs smallstring vs std::string. Describe twine, @@ -1620,7 +1617,7 @@ xref to #string_apis. <a name="ds_bit">Bit storage containers (BitVector, SparseBitVector)</a> </h3> -<div class="doc_text"> +<div> <p>Unlike the other containers, there are only two bit storage containers, and choosing when to use each is relatively straightforward.</p> @@ -1630,14 +1627,13 @@ implementation in many common compilers (e.g. commonly available versions of GCC) is extremely inefficient and 2) the C++ standards committee is likely to deprecate this container and/or change it significantly somehow. In any case, please don't use it.</p> -</div> <!-- _______________________________________________________________________ --> <h4> <a name="dss_bitvector">BitVector</a> </h4> -<div class="doc_text"> +<div> <p> The BitVector container provides a dynamic size set of bits for manipulation. It supports individual bit setting/testing, as well as set operations. The set operations take time O(size of bitvector), but operations are performed one word @@ -1652,7 +1648,7 @@ the number of set bits to be high (IE a dense set). <a name="dss_smallbitvector">SmallBitVector</a> </h4> -<div class="doc_text"> +<div> <p> The SmallBitVector container provides the same interface as BitVector, but it is optimized for the case where only a small number of bits, less than 25 or so, are needed. It also transparently supports larger bit counts, but @@ -1671,7 +1667,7 @@ and its operator[] does not provide an assignable lvalue. <a name="dss_sparsebitvector">SparseBitVector</a> </h4> -<div class="doc_text"> +<div> <p> The SparseBitVector container is much like BitVector, with one major difference: Only the bits that are set, are stored. This makes the SparseBitVector much more space efficient than BitVector when the set is sparse, @@ -1681,13 +1677,17 @@ universe). The downside to the SparseBitVector is that setting and testing of r </p> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2> <a name="common">Helpful Hints for Common Operations</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This section describes how to perform some very simple transformations of LLVM code. This is meant to give examples of common idioms used, showing the @@ -1696,15 +1696,13 @@ you should also read about the main classes that you will be working with. The <a href="#coreclasses">Core LLVM Class Hierarchy Reference</a> contains details and descriptions of the main classes that you should know about.</p> -</div> - <!-- NOTE: this section should be heavy on example code --> <!-- ======================================================================= --> <h3> <a name="inspection">Basic Inspection and Traversal Routines</a> </h3> -<div class="doc_text"> +<div> <p>The LLVM compiler infrastructure have many different data structures that may be traversed. Following the example of the C++ standard template library, the @@ -1721,8 +1719,6 @@ on them, and it is easier to remember how to iterate. First we show a few common examples of the data structures that need to be traversed. Other data structures are traversed in very similar ways.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="iterate_function">Iterating over the </a><a @@ -1730,7 +1726,7 @@ structures are traversed in very similar ways.</p> href="#Function"><tt>Function</tt></a> </h4> -<div class="doc_text"> +<div> <p>It's quite common to have a <tt>Function</tt> instance that you'd like to transform in some way; in particular, you'd like to manipulate its @@ -1765,7 +1761,7 @@ exactly equivalent to <tt>(*i).size()</tt> just like you'd expect.</p> href="#BasicBlock"><tt>BasicBlock</tt></a> </h4> -<div class="doc_text"> +<div> <p>Just like when dealing with <tt>BasicBlock</tt>s in <tt>Function</tt>s, it's easy to iterate over the individual instructions that make up @@ -1796,7 +1792,7 @@ basic block itself: <tt>errs() << *blk << "\n";</tt>.</p> href="#Function"><tt>Function</tt></a> </h4> -<div class="doc_text"> +<div> <p>If you're finding that you commonly iterate over a <tt>Function</tt>'s <tt>BasicBlock</tt>s and then that <tt>BasicBlock</tt>'s <tt>Instruction</tt>s, @@ -1841,7 +1837,7 @@ for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) vice-versa)</a> </h4> -<div class="doc_text"> +<div> <p>Sometimes, it'll be useful to grab a reference (or pointer) to a class instance when all you've got at hand is an iterator. Well, extracting @@ -1918,7 +1914,7 @@ and <tt>operator*</tt> changed to return a pointer instead of a reference.</p> example</a> </h4> -<div class="doc_text"> +<div> <p>Say that you're writing a FunctionPass and would like to count all the locations in the entire module (that is, across every <tt>Function</tt>) where a @@ -1979,7 +1975,7 @@ class OurFunctionPass : public FunctionPass { <a name="calls_and_invokes">Treating calls and invokes the same way</a> </h4> -<div class="doc_text"> +<div> <p>You may have noticed that the previous example was a bit oversimplified in that it did not deal with call sites generated by 'invoke' instructions. In @@ -2006,7 +2002,7 @@ If you look at its definition, it has only a single pointer member.</p> <a name="iterate_chains">Iterating over def-use & use-def chains</a> </h4> -<div class="doc_text"> +<div> <p>Frequently, we might have an instance of the <a href="/doxygen/classllvm_1_1Value.html">Value Class</a> and we want to @@ -2068,7 +2064,7 @@ calling <tt>use/op_begin()</tt> on <tt>const Value*</tt>s or successors of blocks</a> </h4> -<div class="doc_text"> +<div> <p>Iterating over the predecessors and successors of a block is quite easy with the routines defined in <tt>"llvm/Support/CFG.h"</tt>. Just use code like @@ -2091,13 +2087,14 @@ succ_iterator/succ_begin/succ_end.</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="simplechanges">Making simple changes</a> </h3> -<div class="doc_text"> +<div> <p>There are some primitive transformation operations present in the LLVM infrastructure that are worth knowing about. When performing @@ -2105,15 +2102,13 @@ transformations, it's fairly common to manipulate the contents of basic blocks. This section describes some of the common methods for doing so and gives example code.</p> -</div> - <!--_______________________________________________________________________--> <h4> <a name="schanges_creating">Creating and inserting new <tt>Instruction</tt>s</a> </h4> -<div class="doc_text"> +<div> <p><i>Instantiating Instructions</i></p> @@ -2253,7 +2248,7 @@ Instruction* newInst = new Instruction(..., pi); <a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a> </h4> -<div class="doc_text"> +<div> <p>Deleting an instruction from an existing sequence of instructions that form a <a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward: just @@ -2278,7 +2273,7 @@ block but not delete it, you can use the <tt>removeFromParent()</tt> method.</p> <tt>Value</tt></a> </h4> -<div class="doc_text"> +<div> <p><i>Replacing individual instructions</i></p> @@ -2343,7 +2338,7 @@ ReplaceInstWithValue, ReplaceInstWithInst --> <a name="schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a> </h4> -<div class="doc_text"> +<div> <p>Deleting a global variable from a module is just as easy as deleting an Instruction. First, you must have a pointer to the global variable that you wish @@ -2360,12 +2355,14 @@ GV->eraseFromParent(); </div> +</div> + <!-- ======================================================================= --> <h3> <a name="create_types">How to Create Types</a> </h3> -<div class="doc_text"> +<div> <p>In generating IR, you may need some complex types. If you know these types statically, you can use <tt>TypeBuilder<...>::get()</tt>, defined @@ -2400,13 +2397,15 @@ comment</a> for more details.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="threading">Threads and LLVM</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> This section describes the interaction of the LLVM APIs with multithreading, both on the part of client applications, and in the JIT, in the hosted @@ -2429,14 +2428,13 @@ compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and using the resultant compiler to build a copy of LLVM with multithreading support. </p> -</div> <!-- ======================================================================= --> <h3> <a name="startmultithreaded">Entering and Exiting Multithreaded Mode</a> </h3> -<div class="doc_text"> +<div> <p> In order to properly protect its internal data structures while avoiding @@ -2473,7 +2471,7 @@ result in concurrent LLVM API calls. <a name="shutdown">Ending Execution with <tt>llvm_shutdown()</tt></a> </h3> -<div class="doc_text"> +<div> <p> When you are done using the LLVM APIs, you should call <tt>llvm_shutdown()</tt> to deallocate memory used for internal structures. This will also invoke @@ -2493,7 +2491,7 @@ destructor. <a name="managedstatic">Lazy Initialization with <tt>ManagedStatic</tt></a> </h3> -<div class="doc_text"> +<div> <p> <tt>ManagedStatic</tt> is a utility class in LLVM used to implement static initialization of static resources, such as the global type tables. Before the @@ -2522,7 +2520,7 @@ and only if you know what you're doing! <a name="llvmcontext">Achieving Isolation with <tt>LLVMContext</tt></a> </h3> -<div class="doc_text"> +<div> <p> <tt>LLVMContext</tt> is an opaque class in the LLVM API which clients can use to operate multiple, isolated instances of LLVM concurrently within the same @@ -2566,7 +2564,7 @@ isolation is not a concern. <a name="jitthreading">Threads and the JIT</a> </h3> -<div class="doc_text"> +<div> <p> LLVM's "eager" JIT compiler is safe to use in threaded programs. Multiple threads can call <tt>ExecutionEngine::getPointerToFunction()</tt> or @@ -2589,26 +2587,27 @@ access, but we suggest using only the eager JIT in threaded programs. </p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="advanced">Advanced Topics</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> This section describes some of the advanced or obscure API's that most clients do not need to be aware of. These API's tend manage the inner workings of the LLVM system, and only need to be accessed in unusual circumstances. </p> -</div> <!-- ======================================================================= --> <h3> <a name="TypeResolve">LLVM Type Resolution</a> </h3> -<div class="doc_text"> +<div> <p> The LLVM type system has a very simple goal: allow clients to compare types for @@ -2637,14 +2636,12 @@ Third, a concrete type is a type that is not an abstract type (e.g. "<tt>{ i32, float }</tt>"). </p> -</div> - <!-- ______________________________________________________________________ --> <h4> <a name="BuildRecType">Basic Recursive Type Construction</a> </h4> -<div class="doc_text"> +<div> <p> Because the most common question is "how do I build a recursive type with LLVM", @@ -2700,7 +2697,7 @@ href="#PATypeHolder">PATypeHolder class</a>. <a name="refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a> </h4> -<div class="doc_text"> +<div> <p> The <tt>refineAbstractTypeTo</tt> method starts the type unification process. While this method is actually a member of the DerivedType class, it is most @@ -2730,7 +2727,7 @@ complex datastructures. <a name="PATypeHolder">The PATypeHolder Class</a> </h4> -<div class="doc_text"> +<div> <p> PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore happily goes about nuking types that become isomorphic to existing types, it @@ -2752,7 +2749,7 @@ Type is maintained by PATypeHolder objects. <a name="AbstractTypeUser">The AbstractTypeUser Class</a> </h4> -<div class="doc_text"> +<div> <p> Some data structures need more to perform more complex updates when types get @@ -2766,6 +2763,7 @@ objects) can never be refined. </p> </div> +</div> <!-- ======================================================================= --> <h3> @@ -2773,7 +2771,7 @@ objects) can never be refined. <tt>TypeSymbolTable</tt> classes</a> </h3> -<div class="doc_text"> +<div> <p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1ValueSymbolTable.html"> ValueSymbolTable</a></tt> class provides a symbol table that the <a href="#Function"><tt>Function</tt></a> and <a href="#Module"> @@ -2808,7 +2806,7 @@ insert entries into the symbol table.</p> <a name="UserLayout">The <tt>User</tt> and owned <tt>Use</tt> classes' memory layout</a> </h3> -<div class="doc_text"> +<div> <p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1User.html"> User</a></tt> class provides a basis for expressing the ownership of <tt>User</tt> towards other <tt><a href="http://llvm.org/doxygen/classllvm_1_1Value.html"> @@ -2823,14 +2821,13 @@ addition and removal.</p> </a> </h4> -<div class="doc_text"> +<div> <p> A subclass of <tt>User</tt> can choose between incorporating its <tt>Use</tt> objects or refer to them out-of-line by means of a pointer. A mixed variant (some <tt>Use</tt>s inline others hung off) is impractical and breaks the invariant that the <tt>Use</tt> objects belonging to the same <tt>User</tt> form a contiguous array. </p> -</div> <p> We have 2 different layouts in the <tt>User</tt> (sub)classes: @@ -2879,17 +2876,18 @@ enforce the following memory layouts:</p> <i>(In the above figures '<tt>P</tt>' stands for the <tt>Use**</tt> that is stored in each <tt>Use</tt> object in the member <tt>Use::Prev</tt>)</i> +</div> + <!-- ______________________________________________________________________ --> <h4> <a name="Waymarking">The waymarking algorithm</a> </h4> -<div class="doc_text"> +<div> <p> Since the <tt>Use</tt> objects are deprived of the direct (back)pointer to their <tt>User</tt> objects, there must be a fast and exact method to recover it. This is accomplished by the following scheme:</p> -</div> A bit-encoding in the 2 LSBits (least significant bits) of the <tt>Use::Prev</tt> allows to find the start of the <tt>User</tt> object: @@ -2920,15 +2918,16 @@ Only the significant number of bits need to be stored between the stops, so that the <i>worst case is 20 memory accesses</i> when there are 1000 <tt>Use</tt> objects associated with a <tt>User</tt>.</p> +</div> + <!-- ______________________________________________________________________ --> <h4> <a name="ReferenceImpl">Reference implementation</a> </h4> -<div class="doc_text"> +<div> <p> The following literate Haskell fragment demonstrates the concept:</p> -</div> <div class="doc_code"> <pre> @@ -3010,11 +3009,15 @@ And here is the result of <deepCheck identityProp>:</p> OK, passed 500 tests. </pre> +</div> + <!-- ______________________________________________________________________ --> <h4> <a name="Tagging">Tagging considerations</a> </h4> +<div> + <p> To maintain the invariant that the 2 LSBits of each <tt>Use**</tt> in <tt>Use</tt> never change after being set up, setters of <tt>Use::Prev</tt> must re-tag the @@ -3029,13 +3032,17 @@ the LSBit set. (Portability is relying on the fact that all known compilers plac </div> - <!-- *********************************************************************** --> +</div> + +</div> + +<!-- *********************************************************************** --> <h2> <a name="coreclasses">The Core LLVM Class Hierarchy Reference </a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/Type_8h-source.html">llvm/Type.h</a>"</tt> <br>doxygen info: <a href="/doxygen/classllvm_1_1Type.html">Type Class</a></p> @@ -3044,14 +3051,12 @@ being inspected or transformed. The core LLVM classes are defined in header files in the <tt>include/llvm/</tt> directory, and implemented in the <tt>lib/VMCore</tt> directory.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="Type">The <tt>Type</tt> class and Derived Types</a> </h3> -<div class="doc_text"> +<div> <p><tt>Type</tt> is a superclass of all type classes. Every <tt>Value</tt> has a <tt>Type</tt>. <tt>Type</tt> cannot be instantiated directly but only @@ -3066,14 +3071,13 @@ the <tt>lib/VMCore</tt> directory.</p> be performed with address equality of the Type Instance. That is, given two <tt>Type*</tt> values, the types are identical if the pointers are identical. </p> -</div> <!-- _______________________________________________________________________ --> <h4> <a name="m_Type">Important Public Methods</a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>bool isIntegerTy() const</tt>: Returns true for any integer type.</li> @@ -3094,7 +3098,7 @@ the <tt>lib/VMCore</tt> directory.</p> <h4> <a name="derivedtypes">Important Derived Types</a> </h4> -<div class="doc_text"> +<div> <dl> <dt><tt>IntegerType</tt></dt> <dd>Subclass of DerivedType that represents integer types of any bit width. @@ -3156,14 +3160,14 @@ the <tt>lib/VMCore</tt> directory.</p> </dl> </div> - +</div> <!-- ======================================================================= --> <h3> <a name="Module">The <tt>Module</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/Module_8h-source.html">llvm/Module.h</a>"</tt><br> doxygen info: @@ -3178,14 +3182,12 @@ href="#GlobalVariable"><tt>GlobalVariable</tt></a>s, and a <a href="#SymbolTable"><tt>SymbolTable</tt></a>. Additionally, it contains a few helpful member functions that try to make common operations easy.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="m_Module">Important Public Members of the <tt>Module</tt> class</a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>Module::Module(std::string name = "")</tt></li> @@ -3284,13 +3286,14 @@ provide a name for it (probably based on the name of the translation unit).</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="Value">The <tt>Value</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/Value_8h-source.html">llvm/Value.h</a>"</tt> <br> @@ -3341,14 +3344,12 @@ the class that represents this value. Although this may take some getting used to, it simplifies the representation and makes it easier to manipulate.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="m_Value">Important Public Members of the <tt>Value</tt> class</a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>Value::use_iterator</tt> - Typedef for iterator over the @@ -3395,12 +3396,14 @@ Inst->replaceAllUsesWith(ConstVal); </div> +</div> + <!-- ======================================================================= --> <h3> <a name="User">The <tt>User</tt> class</a> </h3> -<div class="doc_text"> +<div> <p> <tt>#include "<a href="/doxygen/User_8h-source.html">llvm/User.h</a>"</tt><br> @@ -3419,14 +3422,12 @@ Single Assignment (SSA) form, there can only be one definition referred to, allowing this direct connection. This connection provides the use-def information in LLVM.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="m_User">Important Public Members of the <tt>User</tt> class</a> </h4> -<div class="doc_text"> +<div> <p>The <tt>User</tt> class exposes the operand list in two ways: through an index access interface and through an iterator based interface.</p> @@ -3449,12 +3450,14 @@ the operands of a <tt>User</tt>.</p></li> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="Instruction">The <tt>Instruction</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "</tt><tt><a href="/doxygen/Instruction_8h-source.html">llvm/Instruction.h</a>"</tt><br> @@ -3485,15 +3488,13 @@ href="#CmpInst">CmpInst</a></tt>). Unfortunately, the use of macros in this file confuses doxygen, so these enum values don't show up correctly in the <a href="/doxygen/classllvm_1_1Instruction.html">doxygen output</a>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="s_Instruction"> Important Subclasses of the <tt>Instruction</tt> class </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt><a name="BinaryOperator">BinaryOperator</a></tt> <p>This subclasses represents all two operand instructions whose operands @@ -3518,7 +3519,7 @@ this file confuses doxygen, so these enum values don't show up correctly in the </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt><a href="#BasicBlock">BasicBlock</a> *getParent()</tt> @@ -3538,12 +3539,14 @@ and it has no name</p></li> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="Constant">The <tt>Constant</tt> class and subclasses</a> </h3> -<div class="doc_text"> +<div> <p>Constant represents a base class for different types of constants. It is subclassed by ConstantInt, ConstantArray, etc. for representing @@ -3551,11 +3554,9 @@ the various types of Constants. <a href="#GlobalValue">GlobalValue</a> is also a subclass, which represents the address of a global variable or function. </p> -</div> - <!-- _______________________________________________________________________ --> <h4>Important Subclasses of Constant</h4> -<div class="doc_text"> +<div> <ul> <li>ConstantInt : This subclass of Constant represents an integer constant of any width. @@ -3603,13 +3604,14 @@ a subclass, which represents the address of a global variable or function. </ul> </div> +</div> <!-- ======================================================================= --> <h3> <a name="GlobalValue">The <tt>GlobalValue</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/GlobalValue_8h-source.html">llvm/GlobalValue.h</a>"</tt><br> @@ -3649,8 +3651,6 @@ dereference the pointer with <tt>GetElementPtrInst</tt> first, then its elements can be accessed. This is explained in the <a href="LangRef.html#globalvars">LLVM Language Reference Manual</a>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="m_GlobalValue"> @@ -3658,7 +3658,7 @@ Language Reference Manual</a>.</p> </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>bool hasInternalLinkage() const</tt><br> @@ -3674,12 +3674,14 @@ GlobalValue is currently embedded into.</p></li> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="Function">The <tt>Function</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/Function_8h-source.html">llvm/Function.h</a>"</tt><br> doxygen @@ -3726,7 +3728,6 @@ href="#Argument"><tt>Argument</tt></a>s in the function body.</p> <p>Note that <tt>Function</tt> is a <a href="#GlobalValue">GlobalValue</a> and therefore also a <a href="#Constant">Constant</a>. The value of the function is its address (after linking) which is guaranteed to be constant.</p> -</div> <!-- _______________________________________________________________________ --> <h4> @@ -3735,7 +3736,7 @@ is its address (after linking) which is guaranteed to be constant.</p> </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>Function(const </tt><tt><a href="#FunctionType">FunctionType</a> @@ -3813,12 +3814,14 @@ iterator<br> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="GlobalVariable">The <tt>GlobalVariable</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/GlobalVariable_8h-source.html">llvm/GlobalVariable.h</a>"</tt> @@ -3840,7 +3843,6 @@ variables may have an initial value (which must be a <a href="#Constant"><tt>Constant</tt></a>), and if they have an initializer, they may be marked as "constant" themselves (indicating that their contents never change at runtime).</p> -</div> <!-- _______________________________________________________________________ --> <h4> @@ -3849,7 +3851,7 @@ never change at runtime).</p> </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>GlobalVariable(const </tt><tt><a href="#Type">Type</a> *Ty, bool @@ -3887,13 +3889,14 @@ never change at runtime).</p> </div> +</div> <!-- ======================================================================= --> <h3> <a name="BasicBlock">The <tt>BasicBlock</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>#include "<a href="/doxygen/BasicBlock_8h-source.html">llvm/BasicBlock.h</a>"</tt><br> @@ -3918,8 +3921,6 @@ href="#Value"><tt>Value</tt></a>s, because they are referenced by instructions like branches and can go in the switch tables. <tt>BasicBlock</tt>s have type <tt>label</tt>.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="m_BasicBlock"> @@ -3927,7 +3928,7 @@ like branches and can go in the switch tables. <tt>BasicBlock</tt>s have type </a> </h4> -<div class="doc_text"> +<div> <ul> <li><tt>BasicBlock(const std::string &Name = "", </tt><tt><a @@ -3979,13 +3980,14 @@ returned.</p></li> </div> +</div> <!-- ======================================================================= --> <h3> <a name="Argument">The <tt>Argument</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>This subclass of Value defines the interface for incoming formal arguments to a function. A Function maintains a list of its formal @@ -3993,6 +3995,8 @@ arguments. An argument has a pointer to the parent Function.</p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/Projects.html b/docs/Projects.html index 8ba8783..1ee53c0 100644 --- a/docs/Projects.html +++ b/docs/Projects.html @@ -33,7 +33,7 @@ <h2><a name="overview">Overview</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM build system is designed to facilitate the building of third party projects that use LLVM header files, libraries, and tools. In order to use @@ -78,7 +78,7 @@ provide enough information on how to write your own Makefiles.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Follow these simple steps to start your project:</p> @@ -150,7 +150,7 @@ project should build.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>In order to use the LLVM build system, you will want to organize your source code so that it can benefit from the build system's features. @@ -235,21 +235,19 @@ your <b>tools</b> directory.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM build system provides a convenient way to build libraries and executables. Most of your project Makefiles will only need to define a few variables. Below is a list of the variables one can set and what they can do:</p> -</div> - <!-- ======================================================================= --> <h3> <a name="reqVars">Required Variables</a> </h3> -<div class="doc_text"> +<div> <dl> <dt>LEVEL @@ -267,7 +265,7 @@ do:</p> <a name="varsBuildDir">Variables for Building Subdirectories</a> </h3> -<div class="doc_text"> +<div> <dl> <dt>DIRS @@ -298,7 +296,7 @@ do:</p> <a name="varsBuildLib">Variables for Building Libraries</a> </h3> -<div class="doc_text"> +<div> <dl> <dt>LIBRARYNAME @@ -329,7 +327,7 @@ do:</p> <a name="varsBuildProg">Variables for Building Programs</a> </h3> -<div class="doc_text"> +<div> <dl> <dt>TOOLNAME @@ -372,7 +370,7 @@ do:</p> <a name="miscVars">Miscellaneous Variables</a> </h3> -<div class="doc_text"> +<div> <dl> <dt>ExtraSource @@ -398,13 +396,15 @@ do:</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="objcode">Placement of Object Code</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The final location of built libraries and executables will depend upon whether you do a Debug, Release, or Profile build.</p> @@ -432,7 +432,7 @@ whether you do a Debug, Release, or Profile build.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>If you have any questions or need any help creating an LLVM project, the LLVM team would be more than happy to help. You can always post your diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html index e456617..c9ae020 100644 --- a/docs/SourceLevelDebugging.html +++ b/docs/SourceLevelDebugging.html @@ -71,7 +71,7 @@ height="369"> <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This document is the central repository for all information pertaining to debug information in LLVM. It describes the <a href="#format">actual format @@ -80,14 +80,12 @@ height="369"> Further, this document provides specific examples of what debug information for C/C++ looks like.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="phil">Philosophy behind LLVM debugging information</a> </h3> -<div class="doc_text"> +<div> <p>The idea of the LLVM debugging information is to capture how the important pieces of the source-language's Abstract Syntax Tree map onto LLVM code. @@ -137,7 +135,7 @@ height="369"> <a name="consumers">Debug information consumers</a> </h3> -<div class="doc_text"> +<div> <p>The role of debug information is to provide meta information normally stripped away during the compilation process. This meta information provides @@ -161,7 +159,7 @@ height="369"> <a name="debugopt">Debugging optimized code</a> </h3> -<div class="doc_text"> +<div> <p>An extremely high priority of LLVM debugging information is to make it interact well with optimizations and analysis. In particular, the LLVM debug @@ -226,13 +224,15 @@ height="369"> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="format">Debugging information format</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM debugging information has been carefully designed to make it possible for the optimizer to optimize the program and debugging information without @@ -265,14 +265,12 @@ height="369"> common to any source-language. The <a href="#ccxx_frontend">next section</a> describes the data layout conventions used by the C and C++ front-ends.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="debug_info_descriptors">Debug information descriptors</a> </h3> -<div class="doc_text"> +<div> <p>In consideration of the complexity and volume of debug information, LLVM provides a specification for well formed debug descriptors. </p> @@ -312,14 +310,12 @@ height="369"> <p>The details of the various descriptors follow.</p> -</div> - <!-- ======================================================================= --> <h4> <a name="format_compile_units">Compile unit descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -355,7 +351,7 @@ height="369"> <a name="format_files">File descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -384,7 +380,7 @@ height="369"> <a name="format_global_variables">Global variable descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -417,7 +413,7 @@ global variables are collected by named metadata <tt>!llvm.dbg.gv</tt>.</p> <a name="format_subprograms">Subprogram descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -461,7 +457,7 @@ global variables are collected by named metadata <tt>!llvm.dbg.gv</tt>.</p> <a name="format_blocks">Block descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -487,7 +483,7 @@ global variables are collected by named metadata <tt>!llvm.dbg.gv</tt>.</p> <a name="format_basic_type">Basic type descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -539,7 +535,7 @@ DW_ATE_unsigned_char = 8 <a name="format_derived_type">Derived type descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -611,7 +607,7 @@ DW_TAG_restrict_type = 55 <a name="format_composite_type">Composite type descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -698,7 +694,7 @@ DW_TAG_inheritance = 28 <a name="format_subrange">Subrange descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -724,7 +720,7 @@ DW_TAG_inheritance = 28 <a name="format_enumeration">Enumerator descriptors</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -748,7 +744,7 @@ DW_TAG_inheritance = 28 <a name="format_variables">Local variables</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -787,24 +783,24 @@ DW_TAG_return_variable = 258 </div> +</div> + <!-- ======================================================================= --> <h3> <a name="format_common_intrinsics">Debugger intrinsic functions</a> </h3> -<div class="doc_text"> +<div> <p>LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to provide debug information at various points in generated code.</p> -</div> - <!-- ======================================================================= --> <h4> <a name="format_common_declare">llvm.dbg.declare</a> </h4> -<div class="doc_text"> +<div> <pre> void %<a href="#format_common_declare">llvm.dbg.declare</a>(metadata, metadata) </pre> @@ -819,7 +815,7 @@ DW_TAG_return_variable = 258 <a name="format_common_value">llvm.dbg.value</a> </h4> -<div class="doc_text"> +<div> <pre> void %<a href="#format_common_value">llvm.dbg.value</a>(metadata, i64, metadata) </pre> @@ -831,12 +827,14 @@ DW_TAG_return_variable = 258 user source variable. </p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="format_common_lifetime">Object lifetimes and scoping</a> </h3> -<div class="doc_text"> +<div> <p>In many languages, the local variables in functions can have their lifetimes or scopes limited to a subset of a function. In the C family of languages, for example, variables are only live (readable and writable) within the @@ -994,13 +992,15 @@ call void @llvm.dbg.declare(metadata, metadata !12), !dbg !14 </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="ccxx_frontend">C/C++ front-end specific debug information</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The C and C++ front-ends represent information about the program in a format that is effectively identical @@ -1021,14 +1021,12 @@ call void @llvm.dbg.declare(metadata, metadata !12), !dbg !14 <p>The following sections provide examples of various C/C++ constructs and the debug information that would best describe those constructs.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="ccxx_compile_units">C/C++ source file information</a> </h3> -<div class="doc_text"> +<div> <p>Given the source files <tt>MySource.cpp</tt> and <tt>MyHeader.h</tt> located in the directory <tt>/Users/mine/sources</tt>, the following code:</p> @@ -1106,7 +1104,7 @@ using <tt>Instruction::getMetadata()</tt> and <a name="ccxx_global_variable">C/C++ global variable information</a> </h3> -<div class="doc_text"> +<div> <p>Given an integer global variable declared as follows:</p> @@ -1176,7 +1174,7 @@ int MyGlobal = 100; <a name="ccxx_subprogram">C/C++ function information</a> </h3> -<div class="doc_text"> +<div> <p>Given a function declared as follows:</p> @@ -1233,18 +1231,16 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_types">C/C++ basic types</a> </h3> -<div class="doc_text"> +<div> <p>The following are the basic type descriptors for C/C++ core types:</p> -</div> - <!-- ======================================================================= --> <h4> <a name="ccxx_basic_type_bool">bool</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1270,7 +1266,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_char">char</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1296,7 +1292,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_unsigned_char">unsigned char</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1322,7 +1318,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_short">short</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1348,7 +1344,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_unsigned_short">unsigned short</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1374,7 +1370,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_int">int</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1399,7 +1395,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_unsigned_int">unsigned int</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1425,7 +1421,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_long_long">long long</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1451,7 +1447,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_unsigned_long_long">unsigned long long</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1477,7 +1473,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_float">float</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1503,7 +1499,7 @@ define i32 @main(i32 %argc, i8** %argv) { <a name="ccxx_basic_double">double</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"> <pre> @@ -1524,12 +1520,14 @@ define i32 @main(i32 %argc, i8** %argv) { </div> +</div> + <!-- ======================================================================= --> <h3> <a name="ccxx_derived_types">C/C++ derived types</a> </h3> -<div class="doc_text"> +<div> <p>Given the following as an example of C/C++ derived type:</p> @@ -1614,7 +1612,7 @@ typedef const int *IntPtr; <a name="ccxx_composite_types">C/C++ struct/union types</a> </h3> -<div class="doc_text"> +<div> <p>Given the following as an example of C/C++ struct type:</p> @@ -1727,7 +1725,7 @@ struct Color { <a name="ccxx_enumeration_types">C/C++ enumeration types</a> </h3> -<div class="doc_text"> +<div> <p>Given the following as an example of C/C++ enumeration type:</p> @@ -1788,6 +1786,8 @@ enum Trees { </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/SystemLibrary.html b/docs/SystemLibrary.html index db60a47..614737e 100644 --- a/docs/SystemLibrary.html +++ b/docs/SystemLibrary.html @@ -37,7 +37,7 @@ <!-- *********************************************************************** --> <h2><a name="abstract">Abstract</a></h2> -<div class="doc_text"> +<div> <p>This document provides some details on LLVM's System Library, located in the source at <tt>lib/System</tt> and <tt>include/llvm/System</tt>. The library's purpose is to shield LLVM from the differences between operating @@ -66,17 +66,16 @@ <h2> <a name="requirements">Keeping LLVM Portable</a> </h2> -<div class="doc_text"> +<div> <p>In order to keep LLVM portable, LLVM developers should adhere to a set of portability rules associated with the System Library. Adherence to these rules should help the System Library achieve its goal of shielding LLVM from the variations in operating system interfaces and doing so efficiently. The following sections define the rules needed to fulfill this objective.</p> -</div> <!-- ======================================================================= --> <h3><a name="headers">Don't Include System Headers</a></h3> -<div class="doc_text"> +<div> <p>Except in <tt>lib/System</tt>, no LLVM source code should directly <tt>#include</tt> a system header. Care has been taken to remove all such <tt>#includes</tt> from LLVM while <tt>lib/System</tt> was being @@ -91,7 +90,7 @@ <!-- ======================================================================= --> <h3><a name="expose">Don't Expose System Headers</a></h3> -<div class="doc_text"> +<div> <p>The System Library must shield LLVM from <em>all</em> system headers. To obtain system level functionality, LLVM source must <tt>#include "llvm/System/Thing.h"</tt> and nothing else. This means that @@ -102,7 +101,7 @@ <!-- ======================================================================= --> <h3><a name="c_headers">Use Standard C Headers</a></h3> -<div class="doc_text"> +<div> <p>The <em>standard</em> C headers (the ones beginning with "c") are allowed to be exposed through the <tt>lib/System</tt> interface. These headers and the things they declare are considered to be platform agnostic. LLVM source @@ -112,7 +111,7 @@ <!-- ======================================================================= --> <h3><a name="cpp_headers">Use Standard C++ Headers</a></h3> -<div class="doc_text"> +<div> <p>The <em>standard</em> C++ headers from the standard C++ library and standard template library may be exposed through the <tt>lib/System</tt> interface. These headers and the things they declare are considered to be @@ -122,7 +121,7 @@ <!-- ======================================================================= --> <h3><a name="highlev">High Level Interface</a></h3> -<div class="doc_text"> +<div> <p>The entry points specified in the interface of lib/System must be aimed at completing some reasonably high level task needed by LLVM. We do not want to simply wrap each operating system call. It would be preferable to wrap several @@ -141,7 +140,7 @@ <!-- ======================================================================= --> <h3><a name="nounused">No Unused Functionality</a></h3> -<div class="doc_text"> +<div> <p>There must be no functionality specified in the interface of lib/System that isn't actually used by LLVM. We're not writing a general purpose operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM @@ -151,7 +150,7 @@ <!-- ======================================================================= --> <h3><a name="nodupl">No Duplicate Implementations</a></h3> -<div class="doc_text"> +<div> <p>The implementation of a function for a given platform must be written exactly once. This implies that it must be possible to apply a function's implementation to multiple operating systems if those operating systems can @@ -162,7 +161,7 @@ <!-- ======================================================================= --> <h3><a name="virtuals">No Virtual Methods</a></h3> -<div class="doc_text"> +<div> <p>The System Library interfaces can be called quite frequently by LLVM. In order to make those calls as efficient as possible, we discourage the use of virtual methods. There is no need to use inheritance for implementation @@ -172,7 +171,7 @@ <!-- ======================================================================= --> <h3><a name="nofunc">No Exposed Functions</a></h3> -<div class="doc_text"> +<div> <p>Any functions defined by system libraries (i.e. not defined by lib/System) must not be exposed through the lib/System interface, even if the header file for that function is not exposed. This prevents inadvertent use of system @@ -188,7 +187,7 @@ <!-- ======================================================================= --> <h3><a name="nodata">No Exposed Data</a></h3> -<div class="doc_text"> +<div> <p>Any data defined by system libraries (i.e. not defined by lib/System) must not be exposed through the lib/System interface, even if the header file for that function is not exposed. As with functions, this prevents inadvertent use @@ -197,7 +196,7 @@ <!-- ======================================================================= --> <h3><a name="softerrors">Minimize Soft Errors</a></h3> -<div class="doc_text"> +<div> <p>Operating system interfaces will generally provide error results for every little thing that could go wrong. In almost all cases, you can divide these error results into two groups: normal/good/soft and abnormal/bad/hard. That @@ -236,7 +235,7 @@ <!-- ======================================================================= --> <h3><a name="throw_spec">No throw Specifications</a></h3> -<div class="doc_text"> +<div> <p>None of the lib/System interface functions may be declared with C++ <tt>throw()</tt> specifications on them. This requirement makes sure that the compiler does not insert additional exception handling code into the interface @@ -248,7 +247,7 @@ <!-- ======================================================================= --> <h3><a name="organization">Code Organization</a></h3> -<div class="doc_text"> +<div> <p>Implementations of the System Library interface are separated by their general class of operating system. Currently only Unix and Win32 classes are defined but more could be added for other operating system classifications. @@ -277,7 +276,7 @@ <!-- ======================================================================= --> <h3><a name="semantics">Consistent Semantics</a></h3> -<div class="doc_text"> +<div> <p>The implementation of a lib/System interface can vary drastically between platforms. That's okay as long as the end result of the interface function is the same. For example, a function to create a directory is pretty straight @@ -292,11 +291,13 @@ <!-- ======================================================================= --> <h3><a name="bug">Bug 351</a></h3> -<div class="doc_text"> +<div> <p>See <a href="http://llvm.org/PR351">bug 351</a> for further details on the progress of this work</p> </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/TableGenFundamentals.html b/docs/TableGenFundamentals.html index 7efdfbb..e8fca32 100644 --- a/docs/TableGenFundamentals.html +++ b/docs/TableGenFundamentals.html @@ -9,7 +9,7 @@ <h1>TableGen Fundamentals</h1> -<div class="doc_text"> +<div> <ul> <li><a href="#introduction">Introduction</a> <ol> @@ -53,7 +53,7 @@ <h2><a name="introduction">Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>TableGen's purpose is to help a human develop and maintain records of domain-specific information. Because there may be a large number of these @@ -72,12 +72,10 @@ find an emacs "TableGen mode" and a vim language file in the <tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directories of your LLVM distribution, respectively.</p> -</div> - <!-- ======================================================================= --> <h3><a name="concepts">Basic concepts</a></h3> -<div class="doc_text"> +<div> <p>TableGen files consist of two key parts: 'classes' and 'definitions', both of which are considered 'records'.</p> @@ -114,7 +112,7 @@ multiclass, as if they were declared in the current multiclass.</p> <!-- ======================================================================= --> <h3><a name="example">An example record</a></h3> -<div class="doc_text"> +<div> <p>With no other arguments, TableGen parses the specified file and prints out all of the classes, then all of the definitions. This is a good way to see what @@ -214,7 +212,7 @@ abstractions they prefer to use when describing their information.</p> <!-- ======================================================================= --> <h3><a name="running">Running TableGen</a></h3> -<div class="doc_text"> +<div> <p>TableGen runs just like any other LLVM tool. The first (optional) argument specifies the file to read. If a filename is not specified, <tt>tblgen</tt> @@ -256,27 +254,28 @@ what you need and formats it in the appropriate way.</p> </div> +</div> <!-- *********************************************************************** --> <h2><a name="syntax">TableGen syntax</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>TableGen doesn't care about the meaning of data (that is up to the backend to define), but it does care about syntax, and it enforces a simple type system. This section describes the syntax and the constructs allowed in a TableGen file. </p> -</div> - <!-- ======================================================================= --> <h3><a name="primitives">TableGen primitives</a></h3> +<div> + <!-- --------------------------------------------------------------------------> <h4><a name="comments">TableGen comments</a></h4> -<div class="doc_text"> +<div> <p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p> @@ -288,7 +287,7 @@ the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p> <a name="types">The TableGen type system</a> </h4> -<div class="doc_text"> +<div> <p>TableGen files are strongly typed, in a simple (but complete) type-system. These types are used to perform automatic conversions, check for errors, and to @@ -348,7 +347,7 @@ needed.</p> <a name="values">TableGen values and expressions</a> </h4> -<div class="doc_text"> +<div> <p>TableGen allows for a pretty reasonable number of different expression forms when building up values. These forms allow the TableGen file to be written in a @@ -433,12 +432,14 @@ to a "<tt>bits<4></tt>" value, for example.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="classesdefs">Classes and definitions</a> </h3> -<div class="doc_text"> +<div> <p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions (collectively known as 'records') in TableGen are the main high-level unit of @@ -473,14 +474,12 @@ between a group of records and isolating it in a single place. Also, classes permit the specification of default values for their subclasses, allowing the subclasses to override them as they wish.</p> -</div> - <!----------------------------------------------------------------------------> <h4> <a name="valuedef">Value definitions</a> </h4> -<div class="doc_text"> +<div> <p>Value definitions define named entries in records. A value must be defined before it can be referred to as the operand for another value definition or @@ -496,7 +495,7 @@ equal sign. Value definitions require terminating semicolons.</p> <a name="recordlet">'let' expressions</a> </h4> -<div class="doc_text"> +<div> <p>A record-level let expression is used to change the value of a value definition in a record. This is primarily useful when a superclass defines a @@ -523,7 +522,7 @@ because the <tt>D</tt> class overrode its value.</p> <a name="templateargs">Class template arguments</a> </h4> -<div class="doc_text"> +<div> <p>TableGen permits the definition of parameterized classes as well as normal concrete classes. Parameterized TableGen classes specify a list of variable @@ -614,7 +613,7 @@ X86 backend.</p> <a name="multiclass">Multiclass definitions and instances</a> </h4> -<div class="doc_text"> +<div> <p> While classes with template arguments are a good way to factor commonality @@ -772,17 +771,21 @@ before them. </div> +</div> + <!-- ======================================================================= --> <h3> <a name="filescope">File scope entities</a> </h3> +<div> + <!-- --------------------------------------------------------------------------> <h4> <a name="include">File inclusion</a> </h4> -<div class="doc_text"> +<div> <p>TableGen supports the '<tt>include</tt>' token, which textually substitutes the specified file in place of the include directive. The filename should be specified as a double quoted string immediately after the '<tt>include</tt>' @@ -801,7 +804,7 @@ keyword. Example:</p> <a name="globallet">'let' expressions</a> </h4> -<div class="doc_text"> +<div> <p>"Let" expressions at file scope are similar to <a href="#recordlet">"let" expressions within a record</a>, except they can specify a value binding for @@ -864,11 +867,15 @@ several levels of multiclass instanciations. This also avoids the need of using </pre> </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2><a name="codegen">Code Generator backend info</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Expressions used by code generator to describe instructions and isel patterns:</p> @@ -885,7 +892,7 @@ patterns:</p> <h2><a name="backends">TableGen backends</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>TODO: How they work, how to write one. This section should not contain details about any particular backend, except maybe -print-enums as an example. diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html index 3d6aa92..12b29c9 100644 --- a/docs/TestingGuide.html +++ b/docs/TestingGuide.html @@ -55,7 +55,7 @@ <h2><a name="overview">Overview</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>This document is the reference manual for the LLVM testing infrastructure. It documents the structure of the LLVM testing infrastructure, the tools needed to @@ -67,7 +67,7 @@ use it, and how to add and run tests.</p> <h2><a name="requirements">Requirements</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>In order to use the LLVM testing infrastructure, you will need all of the software required to build LLVM, as well @@ -79,7 +79,7 @@ as <a href="http://python.org">Python</a> 2.4 or later.</p> <h2><a name="org">LLVM testing infrastructure organization</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>The LLVM testing infrastructure contains two major categories of tests: regression tests and whole programs. The regression tests are contained inside @@ -89,13 +89,11 @@ referred to as the "LLVM test suite" and are in the <tt>test-suite</tt> module in subversion. </p> -</div> - <!-- _______________________________________________________________________ --> <h3><a name="regressiontests">Regression tests</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>The regression tests are small pieces of code that test a specific feature of LLVM or trigger a specific bug in LLVM. They are usually written in LLVM @@ -122,7 +120,7 @@ application or benchmark.</p> <h3><a name="testsuite">Test suite</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>The test suite contains whole programs, which are pieces of code which can be compiled and linked into a stand-alone program that can be @@ -147,7 +145,7 @@ generates code.</p> <h3><a name="debuginfotests">Debugging Information tests</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>The test suite contains tests to check quality of debugging information. The test are written in C based languages or in LLVM assembly language. </p> @@ -159,11 +157,13 @@ test suite for more information . This test suite is located in the </div> +</div> + <!--=========================================================================--> <h2><a name="quick">Quick start</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>The tests are located in two separate Subversion modules. The regressions tests are in the main "llvm" module under the directory @@ -179,6 +179,7 @@ Alternatively, you can configure the <tt>test-suite</tt> module manually.</p> <!-- _______________________________________________________________________ --> <h3><a name="quickregressiontests">Regression tests</a></h3> +<div> <!-- _______________________________________________________________________ --> <p>To run all of the LLVM regression tests, use master Makefile in the <tt>llvm/test</tt> directory:</p> @@ -238,10 +239,14 @@ script which is built as part of LLVM. For example, to run the <p>For more information on using the 'lit' tool, see 'llvm-lit --help' or the 'lit' man page.</p> +</div> + <!-- _______________________________________________________________________ --> <h3><a name="quicktestsuite">Test suite</a></h3> <!-- _______________________________________________________________________ --> +<div> + <p>To run the comprehensive test suite (tests that compile and execute whole programs), first checkout and setup the <tt>test-suite</tt> module:</p> @@ -292,8 +297,9 @@ that subdirectory.</p> <!-- _______________________________________________________________________ --> <h3><a name="quickdebuginfotests">Debugging Information tests</a></h3> +<div> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p> To run debugging information tests simply checkout the tests inside clang/test directory. </p> @@ -309,10 +315,14 @@ clang/test directory. </p> </div> +</div> + +</div> + <!--=========================================================================--> <h2><a name="rtstructure">Regression test structure</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>The LLVM regression tests are driven by 'lit' and are located in the <tt>llvm/test</tt> directory. @@ -334,12 +344,10 @@ clang/test directory. </p> <li><tt>Verifier</tt>: tests the IR verifier.</li> </ul> -</div> - <!-- _______________________________________________________________________ --> <h3><a name="rtcustom">Writing new regression tests</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>The regression test structure is very simple, but does require some information to be set. This information is gathered via <tt>configure</tt> and is written to a file, <tt>lit.site.cfg</tt> @@ -494,7 +502,7 @@ negatives).</p> <h3><a name="FileCheck">The FileCheck utility</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>A powerful feature of the RUN: lines is that it allows any arbitrary commands to be executed as part of the test harness. While standard (portable) unix @@ -560,14 +568,12 @@ is a "subl" in between those labels. If it existed somewhere else in the file, that would not count: "grep subl" matches if subl exists anywhere in the file.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="FileCheck-check-prefix">The FileCheck -check-prefix option</a> </h4> -<div class="doc_text"> +<div> <p>The FileCheck -check-prefix option allows multiple test configurations to be driven from one .ll file. This is useful in many circumstances, for example, @@ -602,7 +608,7 @@ both 32-bit and 64-bit code generation.</p> <a name="FileCheck-CHECK-NEXT">The "CHECK-NEXT:" directive</a> </h4> -<div class="doc_text"> +<div> <p>Sometimes you want to match lines and would like to verify that matches happen on exactly consecutive lines with no other lines in between them. In @@ -643,7 +649,7 @@ directive in a file.</p> <a name="FileCheck-CHECK-NOT">The "CHECK-NOT:" directive</a> </h4> -<div class="doc_text"> +<div> <p>The CHECK-NOT: directive is used to verify that a string doesn't occur between two matches (or the first match and the beginning of the file). For @@ -674,7 +680,7 @@ define i8 @coerce_offset0(i32 %V, i32* %P) { <a name="FileCheck-Matching">FileCheck Pattern Matching Syntax</a> </h4> -<div class="doc_text"> +<div> <p>The CHECK: and CHECK-NOT: directives both take a pattern to match. For most uses of FileCheck, fixed string matching is perfectly sufficient. For some @@ -707,7 +713,7 @@ braces explicitly from the input, you can use something ugly like <a name="FileCheck-Variables">FileCheck Variables</a> </h4> -<div class="doc_text"> +<div> <p>It is often useful to match a pattern and then verify that it occurs again later in the file. For codegen tests, this can be useful to allow any register, @@ -742,10 +748,12 @@ define two separate CHECK lines that match on the same line. </div> +</div> + <!-- _______________________________________________________________________ --> <h3><a name="rtvars">Variables and substitutions</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>With a RUN line there are a number of substitutions that are permitted. In general, any Tcl variable that is available in the <tt>substitute</tt> function (in <tt>test/lib/llvm.exp</tt>) can be substituted into a RUN line. @@ -840,7 +848,7 @@ define two separate CHECK lines that match on the same line. <!-- _______________________________________________________________________ --> <h3><a name="rtfeatures">Other Features</a></h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>To make RUN line writing easier, there are several shell scripts located in the <tt>llvm/test/Scripts</tt> directory. This directory is in the PATH when running tests, so you can just call these scripts using their name. For @@ -895,11 +903,13 @@ define two separate CHECK lines that match on the same line. </div> +</div> + <!--=========================================================================--> <h2><a name="testsuitestructure">Test suite Structure</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>The <tt>test-suite</tt> module contains a number of programs that can be compiled with LLVM and executed. These programs are compiled using the native compiler @@ -967,7 +977,7 @@ will help you separate benign warnings from actual test failures.</p> <h2><a name="testsuiterun">Running the test suite</a></h2> <!--=========================================================================--> -<div class="doc_text"> +<div> <p>First, all tests are executed within the LLVM object directory tree. They <i>are not</i> executed inside of the LLVM source tree. This is because the @@ -1022,15 +1032,13 @@ test suite creates temporary files during execution.</p> have the suite checked out and configured, you don't need to do it again (unless the test code or configure script changes).</p> -</div> - <!-- _______________________________________________________________________ --> <h3> <a name="testsuiteexternal">Configuring External Tests</a> </h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>In order to run the External tests in the <tt>test-suite</tt> module, you must specify <i>--with-externals</i>. This must be done during the <em>re-configuration</em> step (see above), @@ -1062,7 +1070,7 @@ the test code or configure script changes).</p> <a name="testsuitetests">Running different tests</a> </h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>In addition to the regular "whole program" tests, the <tt>test-suite</tt> module also provides a mechanism for compiling the programs in different ways. If the variable TEST is defined on the <tt>gmake</tt> command line, the test system will @@ -1086,7 +1094,7 @@ LLVM.</p> <a name="testsuiteoutput">Generating test output</a> </h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>There are a number of ways to run the tests and generate output. The most simple one is simply running <tt>gmake</tt> with no arguments. This will compile and run all programs in the tree using a number of different methods @@ -1119,7 +1127,7 @@ LLVM.</p> </h3> <!-- _______________________________________________________________________ --> -<div class="doc_text"> +<div> <p>Assuming you can run the test suite, (e.g. "<tt>gmake TEST=nightly report</tt>" should work), it is really easy to run optimizations or code generator @@ -1185,6 +1193,8 @@ example reports that can do fancy stuff.</p> </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/UsingLibraries.html b/docs/UsingLibraries.html index e8067ed..2973452 100644 --- a/docs/UsingLibraries.html +++ b/docs/UsingLibraries.html @@ -31,7 +31,7 @@ <!-- ======================================================================= --> <h2><a name="abstract">Abstract</a></h2> -<div class="doc_text"> +<div> <p>Amongst other things, LLVM is a toolkit for building compilers, linkers, runtime executives, virtual machines, and other program execution related tools. In addition to the LLVM tool set, the functionality of LLVM is @@ -46,7 +46,7 @@ <!-- ======================================================================= --> <h2><a name="introduction">Introduction</a></h2> -<div class="doc_text"> +<div> <p>If you're writing a compiler, virtual machine, or any other utility based on LLVM, you'll need to figure out which of the many libraries files you will need to link with to be successful. An understanding of the contents of these @@ -75,7 +75,7 @@ </div> <!-- ======================================================================= --> <h2><a name="descriptions">Library Descriptions</a></h2> -<div class="doc_text"> +<div> <p>The table below categorizes each library <table style="text-align:left"> <tr><th>Library</th><th>Forms</th><th>Description</th></tr> @@ -153,7 +153,7 @@ <!-- ======================================================================= --> <h2><a name="dependencies">Using llvm-config</a></h2> -<div class="doc_text"> +<div> <p>The <tt>llvm-config</tt> tool is a perl script that produces on its output various kinds of information. For example, the source or object directories used to build LLVM can be accessed by passing options to <tt>llvm-config</tt>. @@ -402,15 +402,14 @@ <!-- ======================================================================= --> <h2><a name="rot">Linkage Rules Of Thumb</a></h2> -<div class="doc_text"> +<div> <p>This section contains various "rules of thumb" about what files you should link into your programs.</p> -</div> <!-- ======================================================================= --> <h3> <a name="always">Always Link LLVMCore, LLVMSupport, and LLVMSystem</a> </h3> -<div class="doc_text"> +<div> <p>No matter what you do with LLVM, the last three entries in the value of your LLVMLIBS make variable should always be: <tt>LLVMCore LLVMSupport.a LLVMSystem.a</tt>. There are no <tt>LLVM</tt> @@ -420,13 +419,16 @@ <h3> <a name="onlyone">Never link both archive and re-linked library</a> </h3> -<div class="doc_text"> +<div> <p>There is never any point to linking both the re-linked (<tt>.o</tt>) and the archive (<tt>.a</tt>) versions of a library. Since the re-linked version includes the entire library, the archive version will not resolve any symbols. You could even end up with link error if you place the archive version before the re-linked version on the linker's command line.</p> </div> + +</div> + <!-- ======================================================================= --> <hr> <div class="doc_footer"> diff --git a/docs/WritingAnLLVMBackend.html b/docs/WritingAnLLVMBackend.html index c8dcb8a..39ac34b 100644 --- a/docs/WritingAnLLVMBackend.html +++ b/docs/WritingAnLLVMBackend.html @@ -66,7 +66,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> This document describes techniques for writing compiler backends that convert @@ -91,13 +91,11 @@ characteristics, such as a RISC instruction set and straightforward calling conventions. </p> -</div> - <h3> <a name="Audience">Audience</a> </h3> -<div class="doc_text"> +<div> <p> The audience for this document is anyone who needs to write an LLVM backend to @@ -110,7 +108,7 @@ generate code for a specific hardware or software target. <a name="Prerequisite">Prerequisite Reading</a> </h3> -<div class="doc_text"> +<div> <p> These essential documents must be read before reading this document: @@ -159,7 +157,7 @@ machine dependent features. <a name="Basic">Basic Steps</a> </h3> -<div class="doc_text"> +<div> <p> To write a compiler backend for LLVM that converts the LLVM IR to code for a @@ -224,7 +222,7 @@ that the class will need and which components will need to be subclassed. <a name="Preliminaries">Preliminaries</a> </h3> -<div class="doc_text"> +<div> <p> To actually create your compiler backend, you need to create and modify a few @@ -281,13 +279,15 @@ regenerate configure by running <tt>./autoconf/AutoRegen.sh</tt>. </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="TargetMachine">Target Machine</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> <tt>LLVMTargetMachine</tt> is designed as a base class for targets implemented @@ -360,11 +360,6 @@ public: </pre> </div> -</div> - - -<div class="doc_text"> - <ul> <li><tt>getInstrInfo()</tt></li> <li><tt>getRegisterInfo()</tt></li> @@ -398,10 +393,6 @@ SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &a </pre> </div> -</div> - -<div class="doc_text"> - <p>Hyphens separate portions of the <tt>TargetDescription</tt> string.</p> <ul> @@ -429,7 +420,7 @@ SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &a </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> You must also register your target with the <tt>TargetRegistry</tt>, which is @@ -485,7 +476,7 @@ For more information, see </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> You should describe a concrete target-specific class that represents the @@ -514,14 +505,12 @@ input files and placed in <tt>XXXGenRegisterInfo.h.inc</tt> and implementation of <tt>XXXRegisterInfo</tt> requires hand-coding. </p> -</div> - <!-- ======================================================================= --> <h3> <a name="RegisterDef">Defining a Register</a> </h3> -<div class="doc_text"> +<div> <p> The <tt>XXXRegisterInfo.td</tt> file typically starts with register definitions @@ -704,7 +693,7 @@ fields of a register's TargetRegisterDesc. <a name="RegisterClassDef">Defining a Register Class</a> </h3> -<div class="doc_text"> +<div> <p> The <tt>RegisterClass</tt> class (specified in <tt>Target.td</tt>) is used to @@ -899,7 +888,7 @@ namespace SP { // Register class instances <a href="CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a> </h3> -<div class="doc_text"> +<div> <p> The final step is to hand code portions of <tt>XXXRegisterInfo</tt>, which @@ -933,13 +922,15 @@ implementation in <tt>SparcRegisterInfo.cpp</tt>: </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="InstructionSet">Instruction Set</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> During the early stages of code generation, the LLVM IR code is converted to a @@ -1188,14 +1179,12 @@ correspond to the values in <tt>SparcInstrInfo.td</tt>. I.e., <tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.) </p> -</div> - <!-- ======================================================================= --> <h3> <a name="operandMapping">Instruction Operand Mapping</a> </h3> -<div class="doc_text"> +<div> <p> The code generator backend maps instruction operands to fields in the @@ -1288,7 +1277,7 @@ the <tt>rd</tt>, <tt>rs1</tt>, and <tt>rs2</tt> fields respectively. <a href="CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a> </h3> -<div class="doc_text"> +<div> <p> The final step is to hand code portions of <tt>XXXInstrInfo</tt>, which @@ -1330,7 +1319,7 @@ implementation in <tt>SparcInstrInfo.cpp</tt>: <h3> <a name="branchFolding">Branch Folding and If Conversion</a> </h3> -<div class="doc_text"> +<div> <p> Performance can be improved by combining instructions or by eliminating @@ -1485,13 +1474,15 @@ branch. </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="InstructionSelector">Instruction Selector</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> LLVM uses a <tt>SelectionDAG</tt> to represent LLVM IR instructions, and nodes @@ -1642,14 +1633,12 @@ SDNode *Select_ISD_STORE(const SDValue &N) { </pre> </div> -</div> - <!-- ======================================================================= --> <h3> <a name="LegalizePhase">The SelectionDAG Legalize Phase</a> </h3> -<div class="doc_text"> +<div> <p> The Legalize phase converts a DAG to use types and operations that are natively @@ -1716,14 +1705,12 @@ a <tt>LegalAction</tt> type enum value: <tt>Promote</tt>, <tt>Expand</tt>, contains examples of all four <tt>LegalAction</tt> values. </p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="promote">Promote</a> </h4> -<div class="doc_text"> +<div> <p> For an operation without native support for a given type, the specified type may @@ -1746,7 +1733,7 @@ setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote); <a name="expand">Expand</a> </h4> -<div class="doc_text"> +<div> <p> For a type without native support, a value may need to be broken down further, @@ -1771,7 +1758,7 @@ setOperationAction(ISD::FCOS, MVT::f32, Expand); <a name="custom">Custom</a> </h4> -<div class="doc_text"> +<div> <p> For some operations, simple type promotion or operation expansion may be @@ -1837,7 +1824,7 @@ static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) { <a name="legal">Legal</a> </h4> -<div class="doc_text"> +<div> <p> The <tt>Legal</tt> LegalizeAction enum value simply indicates that an @@ -1865,12 +1852,14 @@ if (TM.getSubtarget<SparcSubtarget>().isV9()) </div> +</div> + <!-- ======================================================================= --> <h3> <a name="callingConventions">Calling Conventions</a> </h3> -<div class="doc_text"> +<div> <p> To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt> @@ -2015,13 +2004,15 @@ def RetCC_X86_32 : CallingConv<[ </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="assemblyPrinter">Assembly Printer</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> During the code emission stage, the code generator may utilize an LLVM pass to @@ -2176,7 +2167,7 @@ output. </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Subtarget support is used to inform the code generation process of instruction @@ -2294,7 +2285,7 @@ XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) { </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The implementation of a target machine optionally includes a Just-In-Time (JIT) @@ -2333,14 +2324,12 @@ Both <tt>XXXJITInfo.cpp</tt> and <tt>XXXCodeEmitter.cpp</tt> must include the that write data (in bytes, words, strings, etc.) to the output stream. </p> -</div> - <!-- ======================================================================= --> <h3> <a name="mce">Machine Code Emitter</a> </h3> -<div class="doc_text"> +<div> <p> In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the <tt>Emitter</tt> class @@ -2482,7 +2471,7 @@ enum RelocationType { <a name="targetJITInfo">Target JIT Info</a> </h3> -<div class="doc_text"> +<div> <p> <tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific @@ -2537,6 +2526,8 @@ with assembler. </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index 3316179..136f8fb 100644 --- a/docs/WritingAnLLVMPass.html +++ b/docs/WritingAnLLVMPass.html @@ -126,7 +126,7 @@ </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The LLVM Pass Framework is an important part of the LLVM system, because LLVM passes are where most of the interesting parts of the compiler exist. Passes @@ -161,7 +161,7 @@ more advanced features are discussed.</p> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Here we describe how to write the "hello world" of passes. The "Hello" pass is designed to simply print out the name of non-external functions that exist in @@ -169,14 +169,12 @@ the program being compiled. It does not modify the program at all, it just inspects it. The source code and files for this pass are available in the LLVM source tree in the <tt>lib/Transforms/Hello</tt> directory.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="makefile">Setting up the build environment</a> </h3> -<div class="doc_text"> +<div> <p>First, configure and build LLVM. This needs to be done directly inside the LLVM source tree rather than in a separate objects directory. @@ -224,7 +222,7 @@ the pass itself.</p> <a name="basiccode">Basic code required</a> </h3> -<div class="doc_text"> +<div> <p>Now that we have a way to compile our new pass, we just have to write it. Start out with:</p> @@ -360,7 +358,7 @@ them) to be useful.</p> <a name="running">Running a pass with <tt>opt</tt></a> </h3> -<div class="doc_text"> +<div> <p>Now that you have a brand new shiny shared object file, we can use the <tt>opt</tt> command to run an LLVM program through your pass. Because you @@ -446,13 +444,15 @@ about some more details of how they work and how to use them.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="passtype">Pass classes and requirements</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>One of the first things that you should do when designing a new pass is to decide what class you should subclass for your pass. The <a @@ -467,14 +467,12 @@ listed. This gives the LLVM Pass Infrastructure information necessary to optimize how passes are run, so that the resultant compiler isn't unnecessarily slow.</p> -</div> - <!-- ======================================================================= --> <h3> <a name="ImmutablePass">The <tt>ImmutablePass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The most plain and boring type of pass is the "<tt><a href="http://llvm.org/doxygen/classllvm_1_1ImmutablePass.html">ImmutablePass</a></tt>" @@ -497,7 +495,7 @@ invalidated, and are never "run".</p> <a name="ModulePass">The <tt>ModulePass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The "<tt><a href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass</a></tt>" @@ -519,14 +517,12 @@ DominatorTree for function definitions, not declarations.</p> <tt>ModulePass</tt> and overload the <tt>runOnModule</tt> method with the following signature:</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="runOnModule">The <tt>runOnModule</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnModule(Module &M) = 0; @@ -538,12 +534,14 @@ false otherwise.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>The "<tt><a href="http://llvm.org/doxygen/classllvm_1_1CallGraphSCCPass.html">CallGraphSCCPass</a></tt>" @@ -584,8 +582,6 @@ because it has to handle SCCs with more than one node in it. All of the virtual methods described below should return true if they modified the program, or false if they didn't.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="doInitialization_scc"> @@ -593,7 +589,7 @@ false if they didn't.</p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doInitialization(CallGraph &CG); @@ -614,7 +610,7 @@ fast).</p> <a name="runOnSCC">The <tt>runOnSCC</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnSCC(CallGraphSCC &SCC) = 0; @@ -633,7 +629,7 @@ otherwise.</p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doFinalization(CallGraph &CG); @@ -646,12 +642,14 @@ program being compiled.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="FunctionPass">The <tt>FunctionPass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>In contrast to <tt>ModulePass</tt> subclasses, <tt><a href="http://llvm.org/doxygen/classllvm_1_1Pass.html">FunctionPass</a></tt> @@ -676,8 +674,6 @@ href="#basiccode">Hello World</a> pass for example). <tt>FunctionPass</tt>'s may overload three virtual methods to do their work. All of these methods should return true if they modified the program, or false if they didn't.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="doInitialization_mod"> @@ -685,7 +681,7 @@ should return true if they modified the program, or false if they didn't.</p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doInitialization(Module &M); @@ -713,7 +709,7 @@ free functions that it needs, adding prototypes to the module if necessary.</p> <a name="runOnFunction">The <tt>runOnFunction</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnFunction(Function &F) = 0; @@ -732,7 +728,7 @@ be returned if the function is modified.</p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doFinalization(Module &M); @@ -745,12 +741,14 @@ program being compiled.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="LoopPass">The <tt>LoopPass</tt> class </a> </h3> -<div class="doc_text"> +<div> <p> All <tt>LoopPass</tt> execute on each loop in the function independent of all of the other loops in the function. <tt>LoopPass</tt> processes loops in @@ -761,7 +759,6 @@ loop nest order such that outer most loop is processed last. </p> straightforward. <tt>LoopPass</tt>'s may overload three virtual methods to do their work. All these methods should return true if they modified the program, or false if they didn't. </p> -</div> <!-- _______________________________________________________________________ --> <h4> @@ -770,7 +767,7 @@ program, or false if they didn't. </p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM); @@ -791,7 +788,7 @@ information.</p> <a name="runOnLoop">The <tt>runOnLoop</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnLoop(Loop *, LPPassManager &LPM) = 0; @@ -809,7 +806,7 @@ should be used to update loop nest.</p> <a name="doFinalization_loop">The <tt>doFinalization()</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doFinalization(); @@ -822,12 +819,14 @@ program being compiled. </p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="RegionPass">The <tt>RegionPass</tt> class </a> </h3> -<div class="doc_text"> +<div> <p> <tt>RegionPass</tt> is similar to <a href="#LoopPass"><tt>LoopPass</tt></a>, but executes on each single entry single exit region in the function. @@ -839,7 +838,6 @@ the <tt>RGPassManager</tt> interface. You may overload three virtual methods of <tt>RegionPass</tt> to implement your own region pass. All these methods should return true if they modified the program, or false if they didn not. </p> -</div> <!-- _______________________________________________________________________ --> <h4> @@ -848,7 +846,7 @@ methods should return true if they modified the program, or false if they didn n </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doInitialization(Region *, RGPassManager &RGM); @@ -869,7 +867,7 @@ information.</p> <a name="runOnRegion">The <tt>runOnRegion</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnRegion(Region *, RGPassManager &RGM) = 0; @@ -887,7 +885,7 @@ should be used to update region tree.</p> <a name="doFinalization_region">The <tt>doFinalization()</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doFinalization(); @@ -900,14 +898,14 @@ program being compiled. </p> </div> - +</div> <!-- ======================================================================= --> <h3> <a name="BasicBlockPass">The <tt>BasicBlockPass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p><tt>BasicBlockPass</tt>'s are just like <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s, except that they must limit @@ -929,8 +927,6 @@ href="#doInitialization_mod"><tt>doInitialization(Module &)</tt></a> and <a href="#doFinalization_mod"><tt>doFinalization(Module &)</tt></a> methods that <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s have, but also have the following virtual methods that may also be implemented:</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="doInitialization_fn"> @@ -938,7 +934,7 @@ href="#FunctionPass"><tt>FunctionPass</tt></a>'s have, but also have the followi </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doInitialization(Function &F); @@ -959,7 +955,7 @@ fast).</p> <a name="runOnBasicBlock">The <tt>runOnBasicBlock</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnBasicBlock(BasicBlock &BB) = 0; @@ -979,7 +975,7 @@ if the basic block is modified.</p> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> doFinalization(Function &F); @@ -993,12 +989,14 @@ finalization.</p> </div> +</div> + <!-- ======================================================================= --> <h3> <a name="MachineFunctionPass">The <tt>MachineFunctionPass</tt> class</a> </h3> -<div class="doc_text"> +<div> <p>A <tt>MachineFunctionPass</tt> is a part of the LLVM code generator that executes on the machine-dependent representation of each LLVM function in the @@ -1023,8 +1021,6 @@ href="#runOnMachineFunction"><tt>runOnMachineFunction</tt></a> (including global data)</li> </ol> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="runOnMachineFunction"> @@ -1032,7 +1028,7 @@ data)</li> </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual bool</b> runOnMachineFunction(MachineFunction &MF) = 0; @@ -1053,13 +1049,17 @@ remember, you may not modify the LLVM <tt>Function</tt> or its contents from a </div> +</div> + +</div> + <!-- *********************************************************************** --> <h2> <a name="registration">Pass registration</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>In the <a href="#basiccode">Hello World</a> example pass we illustrated how pass registration works, and discussed some of the reasons that it is used and @@ -1076,14 +1076,12 @@ well as for debug output generated by the <tt>--debug-pass</tt> option.</p> <p>If you want your pass to be easily dumpable, you should implement the virtual <tt>print</tt> method:</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="print">The <tt>print</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>; @@ -1103,13 +1101,15 @@ depended on.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="interaction">Specifying interactions between passes</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>One of the main responsibilities of the <tt>PassManager</tt> is to make sure that passes interact with each other correctly. Because <tt>PassManager</tt> @@ -1126,14 +1126,12 @@ specifies. If a pass does not implement the <tt><a href="#getAnalysisUsage">getAnalysisUsage</a></tt> method, it defaults to not having any prerequisite passes, and invalidating <b>all</b> other passes.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="getAnalysisUsage">The <tt>getAnalysisUsage</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual void</b> getAnalysisUsage(AnalysisUsage &Info) <b>const</b>; @@ -1156,7 +1154,7 @@ object:</p> </a> </h4> -<div class="doc_text"> +<div> <p> If your pass requires a previous pass to be executed (an analysis for example), it can use one of these methods to arrange for it to be run before your pass. @@ -1184,7 +1182,7 @@ pass is. </a> </h4> -<div class="doc_text"> +<div> <p> One of the jobs of the PassManager is to optimize how and when analyses are run. In particular, it attempts to avoid recomputing data unless it needs to. For @@ -1221,7 +1219,7 @@ the fact that it hacks on the CFG. </a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <i>// This example modifies the program, but does not modify the CFG</i> @@ -1241,7 +1239,7 @@ the fact that it hacks on the CFG. </a> </h4> -<div class="doc_text"> +<div> <p>The <tt>Pass::getAnalysis<></tt> method is automatically inherited by your class, providing you with access to the passes that you declared that you @@ -1293,13 +1291,15 @@ if it is active. For example:</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="analysisgroup">Implementing Analysis Groups</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we understand the basics of how passes are defined, how they are used, and how they are required from other passes, it's time to get a little bit @@ -1318,14 +1318,12 @@ between these two extremes for other implementations). To cleanly support situations like this, the LLVM Pass Infrastructure supports the notion of Analysis Groups.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="agconcepts">Analysis Group Concepts</a> </h4> -<div class="doc_text"> +<div> <p>An Analysis Group is a single simple interface that may be implemented by multiple different passes. Analysis Groups can be given human readable names @@ -1376,7 +1374,7 @@ hypothetical example) instead.</p> <a name="registerag">Using <tt>RegisterAnalysisGroup</tt></a> </h4> -<div class="doc_text"> +<div> <p>The <tt>RegisterAnalysisGroup</tt> template is used to register the analysis group itself, while the <tt>INITIALIZE_AG_PASS</tt> is used to add pass @@ -1433,13 +1431,15 @@ pass is the default implementation for the interface.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="passStatistics">Pass Statistics</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The <a href="http://llvm.org/doxygen/Statistic_8h-source.html"><tt>Statistic</tt></a> class is designed to be an easy way to expose various success @@ -1456,7 +1456,7 @@ line. See the <a href="http://llvm.org/docs/ProgrammersManual.html#Statistic">St </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The <a href="http://llvm.org/doxygen/PassManager_8h-source.html"><tt>PassManager</tt></a> @@ -1623,14 +1623,12 @@ Hello: main <p>Which shows that we don't accidentally invalidate dominator information anymore, and therefore do not have to compute it twice.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="releaseMemory">The <tt>releaseMemory</tt> method</a> </h4> -<div class="doc_text"> +<div> <div class="doc_code"><pre> <b>virtual void</b> releaseMemory(); @@ -1651,13 +1649,15 @@ class, before the next call of <tt>run*</tt> in your pass.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="registering">Registering dynamically loaded passes</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><i>Size matters</i> when constructing production quality tools using llvm, both for the purposes of distribution, and for regulating the resident code size @@ -1684,14 +1684,12 @@ the static destructor <i>unregisters</i>. Thus a pass that is statically linked in the tool will be registered at start up. A dynamically loaded pass will register on load and unregister at unload.</p> -</div> - <!-- _______________________________________________________________________ --> <h3> <a name="registering_existing">Using existing registries</a> </h3> -<div class="doc_text"> +<div> <p>There are predefined registries to track instruction scheduling (<tt>RegisterScheduler</tt>) and register allocation (<tt>RegisterRegAlloc</tt>) @@ -1756,7 +1754,7 @@ call line to <tt>llvm/Codegen/LinkAllCodegenComponents.h</tt>.</p> <a name="registering_new">Creating new registries</a> </h3> -<div class="doc_text"> +<div> <p>The easiest way to get started is to clone one of the existing registries; we recommend <tt>llvm/CodeGen/RegAllocRegistry.h</tt>. The key things to modify @@ -1784,13 +1782,15 @@ creator.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="debughints">Using GDB with dynamically loaded passes</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Unfortunately, using GDB with dynamically loaded passes is not as easy as it should be. First of all, you can't set a breakpoint in a shared object that has @@ -1802,14 +1802,12 @@ GDB.</p> transformation invoked by <tt>opt</tt>, although nothing described here depends on that.</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="breakpoint">Setting a breakpoint in your pass</a> </h4> -<div class="doc_text"> +<div> <p>First thing you do is start <tt>gdb</tt> on the <tt>opt</tt> process:</p> @@ -1854,7 +1852,7 @@ or do other standard debugging stuff.</p> <a name="debugmisc">Miscellaneous Problems</a> </h4> -<div class="doc_text"> +<div> <p>Once you have the basics down, there are a couple of problems that GDB has, some with solutions, some without.</p> @@ -1882,26 +1880,26 @@ href="mailto:sabre@nondot.org">Chris</a>.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="future">Future extensions planned</a> </h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Although the LLVM Pass Infrastructure is very capable as it stands, and does some nifty stuff, there are things we'd like to add in the future. Here is where we are going:</p> -</div> - <!-- _______________________________________________________________________ --> <h4> <a name="SMP">Multithreaded LLVM</a> </h4> -<div class="doc_text"> +<div> <p>Multiple CPU machines are becoming more common and compilation can never be fast enough: obviously we should allow for a multithreaded compiler. Because of @@ -1919,6 +1917,8 @@ Despite that, we have kept the LLVM passes SMP ready, and you should too.</p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/index.html b/docs/index.html index e40877c..e8b5a44 100644 --- a/docs/index.html +++ b/docs/index.html @@ -13,7 +13,6 @@ see <a href="http://llvm.org/releases/">the download page</a> to find your documentation.</p> -<div class="doc_text"> <table class="layout" width="95%"><tr class="layout"><td class="left"> <ul> <li><a href="#llvmdesign">LLVM Design</a></li> @@ -32,7 +31,6 @@ your documentation.</p> </p> </form> </td></tr></table> -</div> <div class="doc_author"> <p>Written by <a href="http://llvm.org/">The LLVM Team</a></p> diff --git a/docs/tutorial/LangImpl1.html b/docs/tutorial/LangImpl1.html index cc2fa97..2e1746f 100644 --- a/docs/tutorial/LangImpl1.html +++ b/docs/tutorial/LangImpl1.html @@ -33,7 +33,7 @@ <h2><a name="intro">Tutorial Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to the "Implementing a language with LLVM" tutorial. This tutorial runs through the implementation of a simple language, showing how fun and @@ -126,7 +126,7 @@ languages!</p> <h2><a name="language">The Basic Language</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This tutorial will be illustrated with a toy language that we'll call "<a href="http://en.wikipedia.org/wiki/Kaleidoscope">Kaleidoscope</a>" (derived @@ -184,7 +184,7 @@ a Mandelbrot Set</a> at various levels of magnification.</p> <h2><a name="lexer">The Lexer</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>When it comes to implementing a language, the first thing needed is the ability to process a text file and recognize what it says. The traditional diff --git a/docs/tutorial/LangImpl2.html b/docs/tutorial/LangImpl2.html index bfe8d3f..acccd20 100644 --- a/docs/tutorial/LangImpl2.html +++ b/docs/tutorial/LangImpl2.html @@ -39,7 +39,7 @@ <h2><a name="intro">Chapter 2 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 2 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. This chapter shows you how to use the lexer, built in @@ -64,7 +64,7 @@ Tree.</p> <h2><a name="ast">The Abstract Syntax Tree (AST)</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The AST for a program captures its behavior in such a way that it is easy for later stages of the compiler (e.g. code generation) to interpret. We basically @@ -181,7 +181,7 @@ bodies in Kaleidoscope.</p> <h2><a name="parserbasics">Parser Basics</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we have an AST to build, we need to define the parser code to build it. The idea here is that we want to parse something like "x+y" (which is @@ -242,7 +242,7 @@ piece of our grammar: numeric literals.</p> <h2><a name="parserprimexprs">Basic Expression Parsing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>We start with numeric literals, because they are the simplest to process. For each production in our grammar, we'll define a function which parses that @@ -396,7 +396,7 @@ They are a bit more complex.</p> <h2><a name="parserbinops">Binary Expression Parsing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Binary expressions are significantly harder to parse because they are often ambiguous. For example, when given the string "x+y*z", the parser can choose @@ -618,7 +618,7 @@ handle function definitions, etc.</p> <h2><a name="parsertop">Parsing the Rest</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The next thing missing is handling of function prototypes. In Kaleidoscope, @@ -715,7 +715,7 @@ actually <em>execute</em> this code we've built!</p> <h2><a name="driver">The Driver</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The driver for this simply invokes all of the parsing pieces with a top-level dispatch loop. There isn't much interesting here, so I'll just include the @@ -754,7 +754,7 @@ type "4+5;", and the parser will know you are done.</p> <h2><a name="conclusions">Conclusions</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>With just under 400 lines of commented code (240 lines of non-comment, non-blank code), we fully defined our minimal language, including a lexer, @@ -791,7 +791,7 @@ Representation (IR) from the AST.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for this and the previous chapter. diff --git a/docs/tutorial/LangImpl3.html b/docs/tutorial/LangImpl3.html index 468a1bf..c9f4cee 100644 --- a/docs/tutorial/LangImpl3.html +++ b/docs/tutorial/LangImpl3.html @@ -37,7 +37,7 @@ Support</li> <h2><a name="intro">Chapter 3 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 3 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. This chapter shows you how to transform the <a @@ -60,7 +60,7 @@ releases page</a>.</p> <h2><a name="basics">Code Generation Setup</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> In order to generate LLVM IR, we want some simple setup to get started. First @@ -150,7 +150,7 @@ has already been done, and we'll just use it to emit code. <h2><a name="exprs">Expression Code Generation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Generating LLVM code for expression nodes is very straightforward: less than 45 lines of commented code for all four of our expression nodes. First @@ -296,7 +296,7 @@ basic framework.</p> <h2><a name="funcs">Function Code Generation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Code generation for prototypes and functions must handle a number of details, which make their code less beautiful than expression code @@ -518,7 +518,7 @@ def bar() foo(1, 2); # error, unknown function "foo" <h2><a name="driver">Driver Changes and Closing Thoughts</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> For now, code generation to LLVM doesn't really get us much, except that we can @@ -659,7 +659,7 @@ support</a> to this so we can actually start running code!</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/LangImpl4.html b/docs/tutorial/LangImpl4.html index d73f8a3..fe54fb5 100644 --- a/docs/tutorial/LangImpl4.html +++ b/docs/tutorial/LangImpl4.html @@ -36,7 +36,7 @@ Flow</li> <h2><a name="intro">Chapter 4 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 4 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. Chapters 1-3 described the implementation of a simple @@ -51,7 +51,7 @@ for the Kaleidoscope language.</p> <h2><a name="trivialconstfold">Trivial Constant Folding</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Our demonstration for Chapter 3 is elegant and easy to extend. Unfortunately, @@ -136,7 +136,7 @@ range of optimizations that you can use, in the form of "passes".</p> <h2><a name="optimizerpasses">LLVM Optimization Passes</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM provides many optimization passes, which do many different sorts of things and have different tradeoffs. Unlike other systems, LLVM doesn't hold @@ -267,7 +267,7 @@ executing it!</p> <h2><a name="jit">Adding a JIT Compiler</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Code that is available in LLVM IR can have a wide variety of tools applied to it. For example, you can run optimizations on it (as we did above), @@ -475,7 +475,7 @@ tackling some interesting LLVM IR issues along the way.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/LangImpl5.html b/docs/tutorial/LangImpl5.html index 4fbf7be..e46ded1 100644 --- a/docs/tutorial/LangImpl5.html +++ b/docs/tutorial/LangImpl5.html @@ -51,7 +51,7 @@ User-defined Operators</li> <h2><a name="intro">Chapter 5 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 5 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. Parts 1-4 described the implementation of the simple @@ -68,7 +68,7 @@ have an if/then/else expression plus a simple 'for' loop.</p> <h2><a name="ifthen">If/Then/Else</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Extending Kaleidoscope to support if/then/else is quite straightforward. It @@ -108,14 +108,12 @@ Since Kaleidoscope allows side-effects, this behavior is important to nail down. <p>Now that we know what we "want", lets break this down into its constituent pieces.</p> -</div> - <!-- ======================================================================= --> <h4><a name="iflexer">Lexer Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The lexer extensions are straightforward. First we add new enum values for the relevant tokens:</p> @@ -148,7 +146,7 @@ stuff:</p> <h4><a name="ifast">AST Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>To represent the new expression we add a new AST node for it:</p> @@ -173,7 +171,7 @@ public: <h4><a name="ifparser">Parser Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now that we have the relevant tokens coming from the lexer and we have the AST node to build, our parsing logic is relatively straightforward. First we @@ -231,7 +229,7 @@ static ExprAST *ParsePrimary() { <h4><a name="ifir">LLVM IR for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now that we have it parsing and building the AST, the final piece is adding LLVM code generation support. This is the most interesting part of the @@ -347,7 +345,7 @@ directly.</p> <h4><a name="ifcodegen">Code Generation for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>In order to generate code for this, we implement the <tt>Codegen</tt> method for <tt>IfExprAST</tt>:</p> @@ -496,11 +494,13 @@ another useful expression that is familiar from non-functional languages...</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="for">'for' Loop Expression</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we know how to add basic control flow constructs to the language, we have the tools to add more powerful things. Lets add something more @@ -529,13 +529,11 @@ variables, it will get more useful.</p> <p>As before, lets talk about the changes that we need to Kaleidoscope to support this.</p> -</div> - <!-- ======================================================================= --> <h4><a name="forlexer">Lexer Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The lexer extensions are the same sort of thing as for if/then/else:</p> @@ -564,7 +562,7 @@ support this.</p> <h4><a name="forast">AST Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The AST node is just as simple. It basically boils down to capturing the variable name and the constituent expressions in the node.</p> @@ -590,7 +588,7 @@ public: <h4><a name="forparser">Parser Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The parser code is also fairly standard. The only interesting thing here is handling of the optional step value. The parser code handles it by checking to @@ -649,7 +647,7 @@ static ExprAST *ParseForExpr() { <h4><a name="forir">LLVM IR for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now we get to the good part: the LLVM IR we want to generate for this thing. With the simple example above, we get this LLVM IR (note that this dump is @@ -694,7 +692,7 @@ expressions, and some basic blocks. Lets see how this fits together.</p> <h4><a name="forcodegen">Code Generation for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The first part of Codegen is very simple: we just output the start expression for the loop value:</p> @@ -867,11 +865,13 @@ language.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/LangImpl6.html b/docs/tutorial/LangImpl6.html index 510d9dd..39264cf 100644 --- a/docs/tutorial/LangImpl6.html +++ b/docs/tutorial/LangImpl6.html @@ -37,7 +37,7 @@ Variables / SSA Construction</li> <h2><a name="intro">Chapter 6 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 6 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. At this point in our tutorial, we now have a fully @@ -63,7 +63,7 @@ an example of what you can build with Kaleidoscope and its feature set.</p> <h2><a name="idea">User-defined Operators: the Idea</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The "operator overloading" that we will add to Kaleidoscope is more general than @@ -128,7 +128,7 @@ operators.</p> <h2><a name="binary">User-defined Binary Operators</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Adding support for user-defined binary operators is pretty simple with our current framework. We'll first add support for the unary/binary keywords:</p> @@ -345,7 +345,7 @@ see what it takes.</p> <h2><a name="unary">User-defined Unary Operators</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Since we don't currently support unary operators in the Kaleidoscope language, we'll need to add everything to support them. Above, we added simple @@ -494,7 +494,7 @@ is simpler primarily because it doesn't need to handle any predefined operators. <h2><a name="example">Kicking the Tires</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>It is somewhat hard to believe, but with a few simple extensions we've covered in the last chapters, we have grown a real-ish language. With this, we @@ -799,7 +799,7 @@ add variable mutation without building SSA in your front-end.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/LangImpl7.html b/docs/tutorial/LangImpl7.html index fc49d07..b2b26bd 100644 --- a/docs/tutorial/LangImpl7.html +++ b/docs/tutorial/LangImpl7.html @@ -41,7 +41,7 @@ <h2><a name="intro">Chapter 7 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 7 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. In chapters 1 through 6, we've built a very @@ -69,7 +69,7 @@ support for this, though the way it works is a bit unexpected for some.</p> <h2><a name="why">Why is this a hard problem?</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> To understand why mutable variables cause complexities in SSA construction, @@ -143,7 +143,7 @@ logic.</p> <h2><a name="memory">Memory in LLVM</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The 'trick' here is that while LLVM does require all register values to be in SSA form, it does not require (or permit) memory objects to be in SSA form. @@ -324,7 +324,7 @@ variables now! <h2><a name="kalvars">Mutable Variables in Kaleidoscope</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we know the sort of problem we want to tackle, lets see what this looks like in the context of our little Kaleidoscope language. We're going to @@ -380,7 +380,7 @@ Kaleidoscope to support new variable definitions. <h2><a name="adjustments">Adjusting Existing Variables for Mutation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The symbol table in Kaleidoscope is managed at code generation time by the @@ -649,7 +649,7 @@ we'll add the assignment operator.</p> <h2><a name="assignment">New Assignment Operator</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>With our current framework, adding a new assignment operator is really simple. We will parse it just like any other binary operator, but handle it @@ -746,7 +746,7 @@ add this next! <h2><a name="localvars">User-defined Local Variables</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Adding var/in is just like any other other extensions we made to Kaleidoscope: we extend the lexer, the parser, the AST and the code generator. @@ -979,7 +979,7 @@ anywhere in sight.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with mutable diff --git a/docs/tutorial/LangImpl8.html b/docs/tutorial/LangImpl8.html index 449ac70..eed8c03 100644 --- a/docs/tutorial/LangImpl8.html +++ b/docs/tutorial/LangImpl8.html @@ -45,7 +45,7 @@ <h2><a name="conclusion">Tutorial Conclusion</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to the the final chapter of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. In the course of this tutorial, we have grown @@ -156,18 +156,16 @@ are very useful if you want to take advantage of LLVM's capabilities.</p> <h2><a name="llvmirproperties">Properties of the LLVM IR</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>We have a couple common questions about code in the LLVM IR form - lets just get these out of the way right now, shall we?</p> -</div> - <!-- ======================================================================= --> <h4><a name="targetindep">Target Independence</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Kaleidoscope is an example of a "portable language": any program written in Kaleidoscope will work the same way on any target that it runs on. Many other @@ -221,7 +219,7 @@ in-kernel language.</p> <h4><a name="safety">Safety Guarantees</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Many of the languages above are also "safe" languages: it is impossible for a program written in Java to corrupt its address space and crash the process @@ -243,7 +241,7 @@ list</a> if you are interested in more details.</p> <h4><a name="langspecific">Language-Specific Optimizations</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>One thing about LLVM that turns off many people is that it does not solve all the world's problems in one system (sorry 'world hunger', someone else will have @@ -293,23 +291,23 @@ language-specific AST. </div> +</div> + <!-- *********************************************************************** --> <h2><a name="tipsandtricks">Tips and Tricks</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>There is a variety of useful tips and tricks that you come to know after working on/with LLVM that aren't obvious at first glance. Instead of letting everyone rediscover them, this section talks about some of these issues.</p> -</div> - <!-- ======================================================================= --> <h4><a name="offsetofsizeof">Implementing portable offsetof/sizeof</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>One interesting thing that comes up, if you are trying to keep the code generated by your compiler "target independent", is that you often need to know @@ -329,7 +327,7 @@ in a portable way.</p> <h4><a name="gcstack">Garbage Collected Stack Frames</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Some languages want to explicitly manage their stack frames, often so that they are garbage collected or to allow easy implementation of closures. There @@ -343,6 +341,8 @@ Passing Style</a> and the use of tail calls (which LLVM also supports).</p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/tutorial/OCamlLangImpl1.html b/docs/tutorial/OCamlLangImpl1.html index 5446b7a..aa2bd87 100644 --- a/docs/tutorial/OCamlLangImpl1.html +++ b/docs/tutorial/OCamlLangImpl1.html @@ -38,7 +38,7 @@ AST</li> <h2><a name="intro">Tutorial Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to the "Implementing a language with LLVM" tutorial. This tutorial runs through the implementation of a simple language, showing how fun and @@ -133,7 +133,7 @@ languages!</p> <h2><a name="language">The Basic Language</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>This tutorial will be illustrated with a toy language that we'll call "<a href="http://en.wikipedia.org/wiki/Kaleidoscope">Kaleidoscope</a>" (derived @@ -191,7 +191,7 @@ a Mandelbrot Set</a> at various levels of magnification.</p> <h2><a name="lexer">The Lexer</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>When it comes to implementing a language, the first thing needed is the ability to process a text file and recognize what it says. The traditional diff --git a/docs/tutorial/OCamlLangImpl2.html b/docs/tutorial/OCamlLangImpl2.html index deb592e..20e006d 100644 --- a/docs/tutorial/OCamlLangImpl2.html +++ b/docs/tutorial/OCamlLangImpl2.html @@ -43,7 +43,7 @@ <h2><a name="intro">Chapter 2 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 2 of the "<a href="index.html">Implementing a language with LLVM in Objective Caml</a>" tutorial. This chapter shows you how to use @@ -68,7 +68,7 @@ Tree.</p> <h2><a name="ast">The Abstract Syntax Tree (AST)</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The AST for a program captures its behavior in such a way that it is easy for later stages of the compiler (e.g. code generation) to interpret. We basically @@ -149,7 +149,7 @@ bodies in Kaleidoscope.</p> <h2><a name="parserbasics">Parser Basics</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we have an AST to build, we need to define the parser code to build it. The idea here is that we want to parse something like "x+y" (which is @@ -184,7 +184,7 @@ piece of our grammar: numeric literals.</p> <h2><a name="parserprimexprs">Basic Expression Parsing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>We start with numeric literals, because they are the simplest to process. For each production in our grammar, we'll define a function which parses that @@ -305,7 +305,7 @@ They are a bit more complex.</p> <h2><a name="parserbinops">Binary Expression Parsing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Binary expressions are significantly harder to parse because they are often ambiguous. For example, when given the string "x+y*z", the parser can choose @@ -518,7 +518,7 @@ handle function definitions, etc.</p> <h2><a name="parsertop">Parsing the Rest</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The next thing missing is handling of function prototypes. In Kaleidoscope, @@ -597,7 +597,7 @@ actually <em>execute</em> this code we've built!</p> <h2><a name="driver">The Driver</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The driver for this simply invokes all of the parsing pieces with a top-level dispatch loop. There isn't much interesting here, so I'll just include the @@ -653,7 +653,7 @@ type "4+5;", and the parser will know you are done.</p> <h2><a name="conclusions">Conclusions</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>With just under 300 lines of commented code (240 lines of non-comment, non-blank code), we fully defined our minimal language, including a lexer, @@ -690,7 +690,7 @@ Representation (IR) from the AST.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for this and the previous chapter. diff --git a/docs/tutorial/OCamlLangImpl3.html b/docs/tutorial/OCamlLangImpl3.html index cf5afe9..45ee6e9 100644 --- a/docs/tutorial/OCamlLangImpl3.html +++ b/docs/tutorial/OCamlLangImpl3.html @@ -41,7 +41,7 @@ Support</li> <h2><a name="intro">Chapter 3 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 3 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. This chapter shows you how to transform the <a @@ -60,7 +60,7 @@ LLVM SVN to work. LLVM 2.2 and before will not work with it.</p> <h2><a name="basics">Code Generation Setup</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> In order to generate LLVM IR, we want some simple setup to get started. First @@ -131,7 +131,7 @@ that this has already been done, and we'll just use it to emit code.</p> <h2><a name="exprs">Expression Code Generation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Generating LLVM code for expression nodes is very straightforward: less than 30 lines of commented code for all four of our expression nodes. First @@ -266,7 +266,7 @@ basic framework.</p> <h2><a name="funcs">Function Code Generation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Code generation for prototypes and functions must handle a number of details, which make their code less beautiful than expression code @@ -469,7 +469,7 @@ def bar() foo(1, 2); # error, unknown function "foo" <h2><a name="driver">Driver Changes and Closing Thoughts</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> For now, code generation to LLVM doesn't really get us much, except that we can @@ -609,7 +609,7 @@ support</a> to this so we can actually start running code!</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/OCamlLangImpl4.html b/docs/tutorial/OCamlLangImpl4.html index e424045..fd2b5ad 100644 --- a/docs/tutorial/OCamlLangImpl4.html +++ b/docs/tutorial/OCamlLangImpl4.html @@ -40,7 +40,7 @@ Flow</li> <h2><a name="intro">Chapter 4 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 4 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. Chapters 1-3 described the implementation of a simple @@ -55,7 +55,7 @@ for the Kaleidoscope language.</p> <h2><a name="trivialconstfold">Trivial Constant Folding</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p><b>Note:</b> the default <tt>IRBuilder</tt> now always includes the constant folding optimisations below.<p> @@ -150,7 +150,7 @@ range of optimizations that you can use, in the form of "passes".</p> <h2><a name="optimizerpasses">LLVM Optimization Passes</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>LLVM provides many optimization passes, which do many different sorts of things and have different tradeoffs. Unlike other systems, LLVM doesn't hold @@ -284,7 +284,7 @@ executing it!</p> <h2><a name="jit">Adding a JIT Compiler</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Code that is available in LLVM IR can have a wide variety of tools applied to it. For example, you can run optimizations on it (as we did above), @@ -487,7 +487,7 @@ constructs</a>, tackling some interesting LLVM IR issues along the way.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/OCamlLangImpl5.html b/docs/tutorial/OCamlLangImpl5.html index 59c1749..d356f12 100644 --- a/docs/tutorial/OCamlLangImpl5.html +++ b/docs/tutorial/OCamlLangImpl5.html @@ -55,7 +55,7 @@ User-defined Operators</li> <h2><a name="intro">Chapter 5 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 5 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. Parts 1-4 described the implementation of the simple @@ -72,7 +72,7 @@ have an if/then/else expression plus a simple 'for' loop.</p> <h2><a name="ifthen">If/Then/Else</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Extending Kaleidoscope to support if/then/else is quite straightforward. It @@ -112,14 +112,12 @@ Since Kaleidoscope allows side-effects, this behavior is important to nail down. <p>Now that we know what we "want", lets break this down into its constituent pieces.</p> -</div> - <!-- ======================================================================= --> <h4><a name="iflexer">Lexer Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The lexer extensions are straightforward. First we add new variants for the relevant tokens:</p> @@ -155,7 +153,7 @@ stuff:</p> <h4><a name="ifast">AST Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>To represent the new expression we add a new AST variant for it:</p> @@ -176,7 +174,7 @@ type expr = <h4><a name="ifparser">Parser Extensions for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now that we have the relevant tokens coming from the lexer and we have the AST node to build, our parsing logic is relatively straightforward. First we @@ -214,7 +212,7 @@ let rec parse_primary = parser <h4><a name="ifir">LLVM IR for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now that we have it parsing and building the AST, the final piece is adding LLVM code generation support. This is the most interesting part of the @@ -331,7 +329,7 @@ directly.</p> <h4><a name="ifcodegen">Code Generation for If/Then/Else</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>In order to generate code for this, we implement the <tt>Codegen</tt> method for <tt>IfExprAST</tt>:</p> @@ -488,11 +486,13 @@ another useful expression that is familiar from non-functional languages...</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="for">'for' Loop Expression</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we know how to add basic control flow constructs to the language, we have the tools to add more powerful things. Lets add something more @@ -521,13 +521,11 @@ variables, it will get more useful.</p> <p>As before, lets talk about the changes that we need to Kaleidoscope to support this.</p> -</div> - <!-- ======================================================================= --> <h4><a name="forlexer">Lexer Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The lexer extensions are the same sort of thing as for if/then/else:</p> @@ -557,7 +555,7 @@ support this.</p> <h4><a name="forast">AST Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The AST variant is just as simple. It basically boils down to capturing the variable name and the constituent expressions in the node.</p> @@ -577,7 +575,7 @@ type expr = <h4><a name="forparser">Parser Extensions for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The parser code is also fairly standard. The only interesting thing here is handling of the optional step value. The parser code handles it by checking to @@ -624,7 +622,7 @@ let rec parse_primary = parser <h4><a name="forir">LLVM IR for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Now we get to the good part: the LLVM IR we want to generate for this thing. With the simple example above, we get this LLVM IR (note that this dump is @@ -669,7 +667,7 @@ expressions, and some basic blocks. Lets see how this fits together.</p> <h4><a name="forcodegen">Code Generation for the 'for' Loop</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>The first part of Codegen is very simple: we just output the start expression for the loop value:</p> @@ -842,11 +840,13 @@ to our poor innocent language.</p> </div> +</div> + <!-- *********************************************************************** --> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/OCamlLangImpl6.html b/docs/tutorial/OCamlLangImpl6.html index 693aafc..480aab3 100644 --- a/docs/tutorial/OCamlLangImpl6.html +++ b/docs/tutorial/OCamlLangImpl6.html @@ -41,7 +41,7 @@ Variables / SSA Construction</li> <h2><a name="intro">Chapter 6 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 6 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. At this point in our tutorial, we now have a fully @@ -67,7 +67,7 @@ an example of what you can build with Kaleidoscope and its feature set.</p> <h2><a name="idea">User-defined Operators: the Idea</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The "operator overloading" that we will add to Kaleidoscope is more general than @@ -132,7 +132,7 @@ operators.</p> <h2><a name="binary">User-defined Binary Operators</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Adding support for user-defined binary operators is pretty simple with our current framework. We'll first add support for the unary/binary keywords:</p> @@ -323,7 +323,7 @@ see what it takes.</p> <h2><a name="unary">User-defined Unary Operators</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Since we don't currently support unary operators in the Kaleidoscope language, we'll need to add everything to support them. Above, we added simple @@ -475,7 +475,7 @@ is simpler primarily because it doesn't need to handle any predefined operators. <h2><a name="example">Kicking the Tires</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>It is somewhat hard to believe, but with a few simple extensions we've covered in the last chapters, we have grown a real-ish language. With this, we @@ -781,7 +781,7 @@ add variable mutation without building SSA in your front-end.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with the diff --git a/docs/tutorial/OCamlLangImpl7.html b/docs/tutorial/OCamlLangImpl7.html index aebc81c..51986b5 100644 --- a/docs/tutorial/OCamlLangImpl7.html +++ b/docs/tutorial/OCamlLangImpl7.html @@ -45,7 +45,7 @@ <h2><a name="intro">Chapter 7 Introduction</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to Chapter 7 of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. In chapters 1 through 6, we've built a very @@ -73,7 +73,7 @@ support for this, though the way it works is a bit unexpected for some.</p> <h2><a name="why">Why is this a hard problem?</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> To understand why mutable variables cause complexities in SSA construction, @@ -147,7 +147,7 @@ logic.</p> <h2><a name="memory">Memory in LLVM</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>The 'trick' here is that while LLVM does require all register values to be in SSA form, it does not require (or permit) memory objects to be in SSA form. @@ -328,7 +328,7 @@ variables now! <h2><a name="kalvars">Mutable Variables in Kaleidoscope</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Now that we know the sort of problem we want to tackle, lets see what this looks like in the context of our little Kaleidoscope language. We're going to @@ -384,7 +384,7 @@ Kaleidoscope to support new variable definitions. <h2><a name="adjustments">Adjusting Existing Variables for Mutation</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> The symbol table in Kaleidoscope is managed at code generation time by the @@ -673,7 +673,7 @@ we'll add the assignment operator.</p> <h2><a name="assignment">New Assignment Operator</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>With our current framework, adding a new assignment operator is really simple. We will parse it just like any other binary operator, but handle it @@ -774,7 +774,7 @@ add this next! <h2><a name="localvars">User-defined Local Variables</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Adding var/in is just like any other other extensions we made to Kaleidoscope: we extend the lexer, the parser, the AST and the code generator. @@ -956,7 +956,7 @@ anywhere in sight.</p> <h2><a name="code">Full Code Listing</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p> Here is the complete code listing for our running example, enhanced with mutable diff --git a/docs/tutorial/OCamlLangImpl8.html b/docs/tutorial/OCamlLangImpl8.html index 449ac70..eed8c03 100644 --- a/docs/tutorial/OCamlLangImpl8.html +++ b/docs/tutorial/OCamlLangImpl8.html @@ -45,7 +45,7 @@ <h2><a name="conclusion">Tutorial Conclusion</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>Welcome to the the final chapter of the "<a href="index.html">Implementing a language with LLVM</a>" tutorial. In the course of this tutorial, we have grown @@ -156,18 +156,16 @@ are very useful if you want to take advantage of LLVM's capabilities.</p> <h2><a name="llvmirproperties">Properties of the LLVM IR</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>We have a couple common questions about code in the LLVM IR form - lets just get these out of the way right now, shall we?</p> -</div> - <!-- ======================================================================= --> <h4><a name="targetindep">Target Independence</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Kaleidoscope is an example of a "portable language": any program written in Kaleidoscope will work the same way on any target that it runs on. Many other @@ -221,7 +219,7 @@ in-kernel language.</p> <h4><a name="safety">Safety Guarantees</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Many of the languages above are also "safe" languages: it is impossible for a program written in Java to corrupt its address space and crash the process @@ -243,7 +241,7 @@ list</a> if you are interested in more details.</p> <h4><a name="langspecific">Language-Specific Optimizations</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>One thing about LLVM that turns off many people is that it does not solve all the world's problems in one system (sorry 'world hunger', someone else will have @@ -293,23 +291,23 @@ language-specific AST. </div> +</div> + <!-- *********************************************************************** --> <h2><a name="tipsandtricks">Tips and Tricks</a></h2> <!-- *********************************************************************** --> -<div class="doc_text"> +<div> <p>There is a variety of useful tips and tricks that you come to know after working on/with LLVM that aren't obvious at first glance. Instead of letting everyone rediscover them, this section talks about some of these issues.</p> -</div> - <!-- ======================================================================= --> <h4><a name="offsetofsizeof">Implementing portable offsetof/sizeof</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>One interesting thing that comes up, if you are trying to keep the code generated by your compiler "target independent", is that you often need to know @@ -329,7 +327,7 @@ in a portable way.</p> <h4><a name="gcstack">Garbage Collected Stack Frames</a></h4> <!-- ======================================================================= --> -<div class="doc_text"> +<div> <p>Some languages want to explicitly manage their stack frames, often so that they are garbage collected or to allow easy implementation of closures. There @@ -343,6 +341,8 @@ Passing Style</a> and the use of tail calls (which LLVM also supports).</p> </div> +</div> + <!-- *********************************************************************** --> <hr> <address> |