[www-releases] r349965 - Add 7.0.1 docs for clang, llvm, and lld
Tom Stellard via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 21 13:53:04 PST 2018
Added: www-releases/trunk/7.0.1/docs/BitCodeFormat.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/BitCodeFormat.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/BitCodeFormat.html (added)
+++ www-releases/trunk/7.0.1/docs/BitCodeFormat.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,1252 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Bitcode File Format — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="LLVM Block Frequency Terminology" href="BlockFrequencyTerminology.html" />
+ <link rel="prev" title="MemorySSA" href="MemorySSA.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="MemorySSA.html" title="MemorySSA"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-bitcode-file-format">
+<h1>LLVM Bitcode File Format<a class="headerlink" href="#llvm-bitcode-file-format" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id9">Abstract</a></li>
+<li><a class="reference internal" href="#overview" id="id10">Overview</a></li>
+<li><a class="reference internal" href="#bitstream-format" id="id11">Bitstream Format</a><ul>
+<li><a class="reference internal" href="#magic-numbers" id="id12">Magic Numbers</a></li>
+<li><a class="reference internal" href="#primitives" id="id13">Primitives</a><ul>
+<li><a class="reference internal" href="#fixed-width-value" id="id14">Fixed Width Integers</a></li>
+<li><a class="reference internal" href="#variable-width-value" id="id15">Variable Width Integers</a></li>
+<li><a class="reference internal" href="#bit-characters" id="id16">6-bit characters</a></li>
+<li><a class="reference internal" href="#word-alignment" id="id17">Word Alignment</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#abbreviation-ids" id="id18">Abbreviation IDs</a></li>
+<li><a class="reference internal" href="#blocks" id="id19">Blocks</a><ul>
+<li><a class="reference internal" href="#enter-subblock-encoding" id="id20">ENTER_SUBBLOCK Encoding</a></li>
+<li><a class="reference internal" href="#end-block-encoding" id="id21">END_BLOCK Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#data-records" id="id22">Data Records</a><ul>
+<li><a class="reference internal" href="#unabbrev-record-encoding" id="id23">UNABBREV_RECORD Encoding</a></li>
+<li><a class="reference internal" href="#abbreviated-record-encoding" id="id24">Abbreviated Record Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#abbreviations" id="id25">Abbreviations</a><ul>
+<li><a class="reference internal" href="#define-abbrev-encoding" id="id26">DEFINE_ABBREV Encoding</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#standard-block" id="id27">Standard Blocks</a><ul>
+<li><a class="reference internal" href="#blockinfo-block" id="id28">#0 - BLOCKINFO Block</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#bitcode-wrapper-format" id="id29">Bitcode Wrapper Format</a></li>
+<li><a class="reference internal" href="#native-object-file-wrapper-format" id="id30">Native Object File Wrapper Format</a></li>
+<li><a class="reference internal" href="#llvm-ir-encoding" id="id31">LLVM IR Encoding</a><ul>
+<li><a class="reference internal" href="#basics" id="id32">Basics</a><ul>
+<li><a class="reference internal" href="#llvm-ir-magic-number" id="id33">LLVM IR Magic Number</a></li>
+<li><a class="reference internal" href="#signed-vbrs" id="id34">Signed VBRs</a></li>
+<li><a class="reference internal" href="#llvm-ir-blocks" id="id35">LLVM IR Blocks</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#module-block-contents" id="id36">MODULE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#module-code-version-record" id="id37">MODULE_CODE_VERSION Record</a></li>
+<li><a class="reference internal" href="#module-code-triple-record" id="id38">MODULE_CODE_TRIPLE Record</a></li>
+<li><a class="reference internal" href="#module-code-datalayout-record" id="id39">MODULE_CODE_DATALAYOUT Record</a></li>
+<li><a class="reference internal" href="#module-code-asm-record" id="id40">MODULE_CODE_ASM Record</a></li>
+<li><a class="reference internal" href="#module-code-sectionname-record" id="id41">MODULE_CODE_SECTIONNAME Record</a></li>
+<li><a class="reference internal" href="#module-code-deplib-record" id="id42">MODULE_CODE_DEPLIB Record</a></li>
+<li><a class="reference internal" href="#module-code-globalvar-record" id="id43">MODULE_CODE_GLOBALVAR Record</a></li>
+<li><a class="reference internal" href="#module-code-function-record" id="id44">MODULE_CODE_FUNCTION Record</a></li>
+<li><a class="reference internal" href="#module-code-alias-record" id="id45">MODULE_CODE_ALIAS Record</a></li>
+<li><a class="reference internal" href="#module-code-gcname-record" id="id46">MODULE_CODE_GCNAME Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#paramattr-block-contents" id="id47">PARAMATTR_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#paramattr-code-entry-record" id="id48">PARAMATTR_CODE_ENTRY Record</a></li>
+<li><a class="reference internal" href="#paramattr-code-entry-old-record" id="id49">PARAMATTR_CODE_ENTRY_OLD Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#paramattr-group-block-contents" id="id50">PARAMATTR_GROUP_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#paramattr-grp-code-entry-record" id="id51">PARAMATTR_GRP_CODE_ENTRY Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#type-block-contents" id="id52">TYPE_BLOCK Contents</a><ul>
+<li><a class="reference internal" href="#type-code-numentry-record" id="id53">TYPE_CODE_NUMENTRY Record</a></li>
+<li><a class="reference internal" href="#type-code-void-record" id="id54">TYPE_CODE_VOID Record</a></li>
+<li><a class="reference internal" href="#type-code-half-record" id="id55">TYPE_CODE_HALF Record</a></li>
+<li><a class="reference internal" href="#type-code-float-record" id="id56">TYPE_CODE_FLOAT Record</a></li>
+<li><a class="reference internal" href="#type-code-double-record" id="id57">TYPE_CODE_DOUBLE Record</a></li>
+<li><a class="reference internal" href="#type-code-label-record" id="id58">TYPE_CODE_LABEL Record</a></li>
+<li><a class="reference internal" href="#type-code-opaque-record" id="id59">TYPE_CODE_OPAQUE Record</a></li>
+<li><a class="reference internal" href="#type-code-integer-record" id="id60">TYPE_CODE_INTEGER Record</a></li>
+<li><a class="reference internal" href="#type-code-pointer-record" id="id61">TYPE_CODE_POINTER Record</a></li>
+<li><a class="reference internal" href="#type-code-function-old-record" id="id62">TYPE_CODE_FUNCTION_OLD Record</a></li>
+<li><a class="reference internal" href="#type-code-array-record" id="id63">TYPE_CODE_ARRAY Record</a></li>
+<li><a class="reference internal" href="#type-code-vector-record" id="id64">TYPE_CODE_VECTOR Record</a></li>
+<li><a class="reference internal" href="#type-code-x86-fp80-record" id="id65">TYPE_CODE_X86_FP80 Record</a></li>
+<li><a class="reference internal" href="#type-code-fp128-record" id="id66">TYPE_CODE_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-ppc-fp128-record" id="id67">TYPE_CODE_PPC_FP128 Record</a></li>
+<li><a class="reference internal" href="#type-code-metadata-record" id="id68">TYPE_CODE_METADATA Record</a></li>
+<li><a class="reference internal" href="#type-code-x86-mmx-record" id="id69">TYPE_CODE_X86_MMX Record</a></li>
+<li><a class="reference internal" href="#type-code-struct-anon-record" id="id70">TYPE_CODE_STRUCT_ANON Record</a></li>
+<li><a class="reference internal" href="#type-code-struct-name-record" id="id71">TYPE_CODE_STRUCT_NAME Record</a></li>
+<li><a class="reference internal" href="#type-code-struct-named-record" id="id72">TYPE_CODE_STRUCT_NAMED Record</a></li>
+<li><a class="reference internal" href="#type-code-function-record" id="id73">TYPE_CODE_FUNCTION Record</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#constants-block-contents" id="id74">CONSTANTS_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#function-block-contents" id="id75">FUNCTION_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#value-symtab-block-contents" id="id76">VALUE_SYMTAB_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-block-contents" id="id77">METADATA_BLOCK Contents</a></li>
+<li><a class="reference internal" href="#metadata-attachment-contents" id="id78">METADATA_ATTACHMENT Contents</a></li>
+<li><a class="reference internal" href="#strtab-block-contents" id="id79">STRTAB_BLOCK Contents</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h2><a class="toc-backref" href="#id9">Abstract</a><a class="headerlink" href="#abstract" title="Permalink to this headline">¶</a></h2>
+<p>This document describes the LLVM bitstream file format and the encoding of the
+LLVM IR into it.</p>
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id10">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
+<p>What is commonly known as the LLVM bitcode file format (also, sometimes
+anachronistically known as bytecode) is actually two things: a <a class="reference internal" href="#bitstream-container-format">bitstream
+container format</a> and an <a class="reference internal" href="#encoding-of-llvm-ir">encoding of LLVM IR</a> into the container format.</p>
+<p>The bitstream format is an abstract encoding of structured data, very similar to
+XML in some ways. Like XML, bitstream files contain tags, and nested
+structures, and you can parse the file without having to understand the tags.
+Unlike XML, the bitstream format is a binary encoding, and unlike XML it
+provides a mechanism for the file to self-describe “abbreviations”, which are
+effectively size optimizations for the content.</p>
+<p>LLVM IR files may be optionally embedded into a <a class="reference internal" href="#wrapper">wrapper</a> structure, or in a
+<a class="reference internal" href="#native-object-file">native object file</a>. Both of these mechanisms make it easy to embed extra
+data along with LLVM IR files.</p>
+<p>This document first describes the LLVM bitstream format, describes the wrapper
+format, then describes the record structure used by LLVM IR files.</p>
+</div>
+<div class="section" id="bitstream-format">
+<span id="bitstream-container-format"></span><h2><a class="toc-backref" href="#id11">Bitstream Format</a><a class="headerlink" href="#bitstream-format" title="Permalink to this headline">¶</a></h2>
+<p>The bitstream format is literally a stream of bits, with a very simple
+structure. This structure consists of the following concepts:</p>
+<ul class="simple">
+<li>A “<a class="reference internal" href="#magic-number">magic number</a>” that identifies the contents of the stream.</li>
+<li>Encoding <a class="reference internal" href="#primitives">primitives</a> like variable bit-rate integers.</li>
+<li><a class="reference internal" href="#blocks">Blocks</a>, which define nested content.</li>
+<li><a class="reference internal" href="#data-records">Data Records</a>, which describe entities within the file.</li>
+<li>Abbreviations, which specify compression optimizations for the file.</li>
+</ul>
+<p>Note that the <a class="reference internal" href="CommandGuide/llvm-bcanalyzer.html"><em>llvm-bcanalyzer</em></a> tool can be
+used to dump and inspect arbitrary bitstreams, which is very useful for
+understanding the encoding.</p>
+<div class="section" id="magic-numbers">
+<span id="magic-number"></span><h3><a class="toc-backref" href="#id12">Magic Numbers</a><a class="headerlink" href="#magic-numbers" title="Permalink to this headline">¶</a></h3>
+<p>The first four bytes of a bitstream are used as an application-specific magic
+number. Generic bitcode tools may look at the first four bytes to determine
+whether the stream is a known stream type. However, these tools should <em>not</em>
+determine whether a bitstream is valid based on its magic number alone. New
+application-specific bitstream formats are being developed all the time; tools
+should not reject them just because they have a hitherto unseen magic number.</p>
+</div>
+<div class="section" id="primitives">
+<span id="id1"></span><h3><a class="toc-backref" href="#id13">Primitives</a><a class="headerlink" href="#primitives" title="Permalink to this headline">¶</a></h3>
+<p>A bitstream literally consists of a stream of bits, which are read in order
+starting with the least significant bit of each byte. The stream is made up of
+a number of primitive values that encode a stream of unsigned integer values.
+These integers are encoded in two ways: either as <a class="reference internal" href="#fixed-width-integers">Fixed Width Integers</a> or as
+<a class="reference internal" href="#variable-width-integers">Variable Width Integers</a>.</p>
+<div class="section" id="fixed-width-value">
+<span id="fixed-width-integers"></span><span id="id2"></span><h4><a class="toc-backref" href="#id14">Fixed Width Integers</a><a class="headerlink" href="#fixed-width-value" title="Permalink to this headline">¶</a></h4>
+<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 are
+used when there are a well-known number of options for a field. For example,
+boolean values are usually encoded with a 1-bit wide integer.</p>
+</div>
+<div class="section" id="variable-width-value">
+<span id="variable-width-integer"></span><span id="variable-width-integers"></span><span id="id3"></span><h4><a class="toc-backref" href="#id15">Variable Width Integers</a><a class="headerlink" href="#variable-width-value" title="Permalink to this headline">¶</a></h4>
+<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, any 3-bit
+value (0 through 7) is encoded directly, with the high bit set to zero. Values
+larger than N-1 bits emit their bits in a series of N-1 bit chunks, where all
+but the last set the high bit.</p>
+<p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a vbr4
+value. The first set of four bits indicates the value 3 (011) with a
+continuation piece (indicated by a high bit of 1). The next word indicates a
+value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
+27.</p>
+</div>
+<div class="section" id="bit-characters">
+<span id="char6-encoded-value"></span><h4><a class="toc-backref" href="#id16">6-bit characters</a><a class="headerlink" href="#bit-characters" title="Permalink to this headline">¶</a></h4>
+<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>
+<div class="highlight-python"><pre>'a' .. 'z' --- 0 .. 25
+'A' .. 'Z' --- 26 .. 51
+'0' .. '9' --- 52 .. 61
+ '.' --- 62
+ '_' --- 63</pre>
+</div>
+<p>This encoding is only suitable for encoding characters and strings that consist
+only of the above characters. It is completely incapable of encoding characters
+not in the set.</p>
+</div>
+<div class="section" id="word-alignment">
+<h4><a class="toc-backref" href="#id17">Word Alignment</a><a class="headerlink" href="#word-alignment" title="Permalink to this headline">¶</a></h4>
+<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 represented
+as a multiple of 32-bit words.</p>
+</div>
+</div>
+<div class="section" id="abbreviation-ids">
+<h3><a class="toc-backref" href="#id18">Abbreviation IDs</a><a class="headerlink" href="#abbreviation-ids" title="Permalink to this headline">¶</a></h3>
+<p>A bitstream is a sequential series of <a class="reference internal" href="#blocks">Blocks</a> and <a class="reference internal" href="#data-records">Data Records</a>. Both of
+these start with an abbreviation ID encoded as a fixed-bitwidth field. The
+width is specified by the current block, as described below. The value of the
+abbreviation ID specifies either a builtin ID (which have special meanings,
+defined below) or one of the abbreviation IDs defined for the current block by
+the stream itself.</p>
+<p>The set of builtin abbrev IDs is:</p>
+<ul class="simple">
+<li>0 - <a class="reference internal" href="#end-block">END_BLOCK</a> — This abbrev ID marks the end of the current block.</li>
+<li>1 - <a class="reference internal" href="#enter-subblock">ENTER_SUBBLOCK</a> — This abbrev ID marks the beginning of a new
+block.</li>
+<li>2 - <a class="reference internal" href="#define-abbrev">DEFINE_ABBREV</a> — This defines a new abbreviation.</li>
+<li>3 - <a class="reference internal" href="#unabbrev-record">UNABBREV_RECORD</a> — This ID specifies the definition of an
+unabbreviated record.</li>
+</ul>
+<p>Abbreviation IDs 4 and above are defined by the stream itself, and specify an
+<a class="reference internal" href="#abbreviated-record-encoding">abbreviated record encoding</a>.</p>
+</div>
+<div class="section" id="blocks">
+<span id="id4"></span><h3><a class="toc-backref" href="#id19">Blocks</a><a class="headerlink" href="#blocks" title="Permalink to this headline">¶</a></h3>
+<p>Blocks in a bitstream denote nested regions of the stream, and are identified by
+a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
+function bodies). Block IDs 0-7 are reserved for <a class="reference internal" href="#standard-blocks">standard blocks</a> whose
+meaning is defined by Bitcode; block IDs 8 and greater are application
+specific. Nested blocks capture the hierarchical structure of the data encoded
+in it, and various properties are associated with blocks as the file is parsed.
+Block definitions allow the reader to efficiently skip blocks in constant time
+if the reader wants a summary of blocks, or if it wants to efficiently skip data
+it does not understand. The LLVM IR reader uses this mechanism to skip function
+bodies, lazily reading them on demand.</p>
+<p>When reading and encoding the stream, several properties are maintained for the
+block. In particular, each block maintains:</p>
+<ol class="arabic simple">
+<li>A current abbrev id width. This value starts at 2 at the beginning of the
+stream, and is set every time a block record is entered. The block entry
+specifies the abbrev id width for the body of the block.</li>
+<li>A set of abbreviations. Abbreviations may be defined within a block, in
+which case they are only defined in that block (neither subblocks nor
+enclosing blocks see the abbreviation). Abbreviations can also be defined
+inside a <a class="reference internal" href="#blockinfo">BLOCKINFO</a> block, in which case they are defined in all blocks
+that match the ID that the <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block is describing.</li>
+</ol>
+<p>As sub blocks are entered, these properties are saved and the new sub-block has
+its own set of abbreviations, and its own abbrev id width. When a sub-block is
+popped, the saved values are restored.</p>
+<div class="section" id="enter-subblock-encoding">
+<span id="enter-subblock"></span><h4><a class="toc-backref" href="#id20">ENTER_SUBBLOCK Encoding</a><a class="headerlink" href="#enter-subblock-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>, <align32bits>, blocklen_32]
+<span class="raw-html"></tt></span></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTER_SUBBLOCK</span></tt> abbreviation ID specifies the start of a new block
+record. The <tt class="docutils literal"><span class="pre">blockid</span></tt> value is encoded as an 8-bit VBR identifier, and
+indicates the type of block being entered, which can be a <a class="reference internal" href="#standard-block">standard block</a> or
+an application-specific block. The <tt class="docutils literal"><span class="pre">newabbrevlen</span></tt> value is a 4-bit VBR, which
+specifies the abbrev id width for the sub-block. The <tt class="docutils literal"><span class="pre">blocklen</span></tt> value is a
+32-bit aligned value that specifies the size of the subblock in 32-bit
+words. This value allows the reader to skip over the entire block in one jump.</p>
+</div>
+<div class="section" id="end-block-encoding">
+<span id="end-block"></span><h4><a class="toc-backref" href="#id21">END_BLOCK Encoding</a><a class="headerlink" href="#end-block-encoding" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[END_BLOCK,</span> <span class="pre"><align32bits>]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">END_BLOCK</span></tt> abbreviation ID specifies the end of the current block record.
+Its end is aligned to 32-bits to ensure that the size of the block is an even
+multiple of 32-bits.</p>
+</div>
+</div>
+<div class="section" id="data-records">
+<span id="id5"></span><h3><a class="toc-backref" href="#id22">Data Records</a><a class="headerlink" href="#data-records" title="Permalink to this headline">¶</a></h3>
+<p>Data records consist of a record code and a number of (up to) 64-bit integer
+values. The interpretation of the code and values is application specific and
+may vary between different block types. Records can be encoded either using an
+unabbrev record, or with an abbreviation. In the LLVM IR format, for example,
+there is a record which encodes the target triple of a module. The code is
+<tt class="docutils literal"><span class="pre">MODULE_CODE_TRIPLE</span></tt>, and the values of the record are the ASCII codes for the
+characters in the string.</p>
+<div class="section" id="unabbrev-record-encoding">
+<span id="unabbrev-record"></span><h4><a class="toc-backref" href="#id23">UNABBREV_RECORD Encoding</a><a class="headerlink" href="#unabbrev-record-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>, op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]
+<span class="raw-html"></tt></span></p>
+<p>An <tt class="docutils literal"><span class="pre">UNABBREV_RECORD</span></tt> provides a default fallback encoding, which is both
+completely general and extremely inefficient. It can describe an arbitrary
+record by emitting the code and operands as VBRs.</p>
+<p>For example, emitting an LLVM IR target triple as an unabbreviated record
+requires emitting the <tt class="docutils literal"><span class="pre">UNABBREV_RECORD</span></tt> abbrevid, a vbr6 for the
+<tt class="docutils literal"><span class="pre">MODULE_CODE_TRIPLE</span></tt> code, a vbr6 for the length of the string, which is equal
+to the number of operands, and a vbr6 for each character. Because there are no
+letters with values less than 32, each letter would need to be emitted as at
+least a two-part VBR, which means that each letter would require at least 12
+bits. This is not an efficient encoding, but it is fully general.</p>
+</div>
+<div class="section" id="abbreviated-record-encoding">
+<span id="id6"></span><h4><a class="toc-backref" href="#id24">Abbreviated Record Encoding</a><a class="headerlink" href="#abbreviated-record-encoding" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[<abbrevid>,</span> <span class="pre">fields...]</span></tt></p>
+<p>An abbreviated record is a abbreviation id followed by a set of fields that are
+encoded according to the <a class="reference internal" href="#abbreviation-definition">abbreviation definition</a>. This allows records to be
+encoded significantly more densely than records encoded with the
+<a class="reference internal" href="#unabbrev-record">UNABBREV_RECORD</a> type, and allows the abbreviation types to be specified in
+the stream itself, which allows the files to be completely self describing. The
+actual encoding of abbreviations is defined below.</p>
+<p>The record code, which is the first field of an abbreviated record, may be
+encoded in the abbreviation definition (as a literal operand) or supplied in the
+abbreviated record (as a Fixed or VBR operand value).</p>
+</div>
+</div>
+<div class="section" id="abbreviations">
+<span id="abbreviation-definition"></span><h3><a class="toc-backref" href="#id25">Abbreviations</a><a class="headerlink" href="#abbreviations" title="Permalink to this headline">¶</a></h3>
+<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
+to emit many records. It takes space to emit the encoding into the file, but
+the space is recouped (hopefully plus some) when the records that use it are
+emitted.</p>
+<p>Abbreviations can be determined dynamically per client, per file. Because the
+abbreviations are stored in the bitstream itself, different streams of the same
+format can contain different sets of abbreviations according to the needs of the
+specific stream. As a concrete example, LLVM IR files usually emit an
+abbreviation for binary operators. If a specific LLVM module contained no or
+few binary operators, the abbreviation does not need to be emitted.</p>
+<div class="section" id="define-abbrev-encoding">
+<span id="define-abbrev"></span><h4><a class="toc-backref" href="#id26">DEFINE_ABBREV Encoding</a><a class="headerlink" href="#define-abbrev-encoding" title="Permalink to this headline">¶</a></h4>
+<p><span class="raw-html"><tt></span>
+[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1, ...]
+<span class="raw-html"></tt></span></p>
+<p>A <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> record adds an abbreviation to the list of currently defined
+abbreviations in the scope of this block. This definition only exists inside
+this immediate block — it is not visible in subblocks or enclosing blocks.
+Abbreviations are implicitly assigned IDs sequentially starting from 4 (the
+first application-defined abbreviation ID). Any abbreviations defined in a
+<tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> record for the particular block type receive IDs first, in order,
+followed by any abbreviations defined within the block itself. Abbreviated data
+records reference this ID to indicate what abbreviation they are invoking.</p>
+<p>An abbreviation definition consists of the <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> abbrevid followed
+by a VBR that specifies the number of abbrev operands, then the abbrev operands
+themselves. Abbreviation operands come in three forms. They all start with a
+single bit that indicates whether the abbrev operand is a literal operand (when
+the bit is 1) or an encoding operand (when the bit is 0).</p>
+<ol class="arabic simple">
+<li>Literal operands — <span class="raw-html"><tt></span> [1<sub>1</sub>, litvalue<sub>vbr8</sub>] <span class="raw-html"></tt></span> — Literal operands specify that the value in
+the result is always a single specific value. This specific value is emitted
+as a vbr8 after the bit indicating that it is a literal operand.</li>
+<li>Encoding info without data — <span class="raw-html"><tt></span> [0<sub>1</sub>, encoding<sub>3</sub>] <span class="raw-html"></tt></span> — Operand encodings that do not have extra data
+are just emitted as their code.</li>
+<li>Encoding info with data — <span class="raw-html"><tt></span> [0<sub>1</sub>, encoding<sub>3</sub>, value<sub>vbr5</sub>] <span class="raw-html"></tt></span> — Operand encodings that do
+have extra data are emitted as their code, followed by the extra data.</li>
+</ol>
+<p>The possible operand encodings are:</p>
+<ul class="simple">
+<li>Fixed (code 1): The field should be emitted as a <a class="reference internal" href="#fixed-width-value">fixed-width value</a>, whose
+width is specified by the operand’s extra data.</li>
+<li>VBR (code 2): The field should be emitted as a <a class="reference internal" href="#variable-width-value">variable-width value</a>, whose
+width is specified by the operand’s extra data.</li>
+<li>Array (code 3): This field is an array of values. The array operand has no
+extra data, but expects another operand to follow it, indicating the element
+type of the array. When reading an array in an abbreviated record, the first
+integer is a vbr6 that indicates the array length, followed by the encoded
+elements of the array. An array may only occur as the last operand of an
+abbreviation (except for the one final operand that gives the array’s
+type).</li>
+<li>Char6 (code 4): This field should be emitted as a <a class="reference internal" href="#char6-encoded-value">char6-encoded value</a>.
+This operand type takes no extra data. Char6 encoding is normally used as an
+array element type.</li>
+<li>Blob (code 5): This field is emitted as a vbr6, followed by padding to a
+32-bit boundary (for alignment) and an array of 8-bit objects. The array of
+bytes is further followed by tail padding to ensure that its total length is a
+multiple of 4 bytes. This makes it very efficient for the reader to decode
+the data without having to make a copy of it: it can use a pointer to the data
+in the mapped in file and poke directly at it. A blob may only occur as the
+last operand of an abbreviation.</li>
+</ul>
+<p>For example, target triples in LLVM modules are encoded as a record of the form
+<tt class="docutils literal"><span class="pre">[TRIPLE,</span> <span class="pre">'a',</span> <span class="pre">'b',</span> <span class="pre">'c',</span> <span class="pre">'d']</span></tt>. Consider if the bitstream emitted the
+following abbrev entry:</p>
+<div class="highlight-python"><div class="highlight"><pre><span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Fixed</span><span class="p">,</span> <span class="mi">4</span><span class="p">]</span>
+<span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Array</span><span class="p">]</span>
+<span class="p">[</span><span class="mi">0</span><span class="p">,</span> <span class="n">Char6</span><span class="p">]</span>
+</pre></div>
+</div>
+<p>When emitting a record with this abbreviation, the above entry would be emitted
+as:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>, 0<sub>6</sub>, 1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+<p>These values are:</p>
+<ol class="arabic simple">
+<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
+<li>The second value, 2, is the record code for <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> records within LLVM IR
+file <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt> blocks.</li>
+<li>The third value, 4, is the length of the array.</li>
+<li>The rest of the values are the char6 encoded values for <tt class="docutils literal"><span class="pre">"abcd"</span></tt>.</li>
+</ol>
+<p>With this abbreviation, the triple is emitted with only 37 bits (assuming a
+abbrev id width of 3). Without the abbreviation, significantly more space would
+be required to emit the target triple. Also, because the <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> value is
+not emitted as a literal in the abbreviation, the abbreviation can also be used
+for any other string value.</p>
+</div>
+</div>
+<div class="section" id="standard-block">
+<span id="standard-blocks"></span><span id="id7"></span><h3><a class="toc-backref" href="#id27">Standard Blocks</a><a class="headerlink" href="#standard-block" title="Permalink to this headline">¶</a></h3>
+<p>In addition to the basic block structure and record encodings, the bitstream
+also defines specific built-in block types. These block types specify how the
+stream is to be decoded or other metadata. In the future, new standard blocks
+may be added. Block IDs 0-7 are reserved for standard blocks.</p>
+<div class="section" id="blockinfo-block">
+<span id="blockinfo"></span><h4><a class="toc-backref" href="#id28">#0 - BLOCKINFO Block</a><a class="headerlink" href="#blockinfo-block" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block allows the description of metadata for other blocks.
+The currently specified records are:</p>
+<div class="highlight-python"><pre>[SETBID (#1), blockid]
+[DEFINE_ABBREV, ...]
+[BLOCKNAME, ...name...]
+[SETRECORDNAME, RecordID, ...name...]</pre>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">SETBID</span></tt> record (code 1) indicates which block ID is being described.
+<tt class="docutils literal"><span class="pre">SETBID</span></tt> records can occur multiple times throughout the block to change which
+block ID is being described. There must be a <tt class="docutils literal"><span class="pre">SETBID</span></tt> record prior to any
+other records.</p>
+<p>Standard <tt class="docutils literal"><span class="pre">DEFINE_ABBREV</span></tt> records can occur inside <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks, but
+unlike their occurrence in normal blocks, the abbreviation is defined for blocks
+matching the block ID we are describing, <em>not</em> the <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> block
+itself. The abbreviations defined in <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks receive abbreviation
+IDs as described in <a class="reference internal" href="#define-abbrev">DEFINE_ABBREV</a>.</p>
+<p>The <tt class="docutils literal"><span class="pre">BLOCKNAME</span></tt> record (code 2) can optionally occur in this block. The
+elements of the record are the bytes of the string name of the block.
+llvm-bcanalyzer can use this to dump out bitcode files symbolically.</p>
+<p>The <tt class="docutils literal"><span class="pre">SETRECORDNAME</span></tt> record (code 3) can also optionally occur in this block.
+The first operand value is a record ID number, and the rest of the elements of
+the record are the bytes for the string name of the record. llvm-bcanalyzer can
+use this to dump out bitcode files symbolically.</p>
+<p>Note that although the data in <tt class="docutils literal"><span class="pre">BLOCKINFO</span></tt> blocks is described as “metadata,”
+the abbreviations they contain are essential for parsing records from the
+corresponding blocks. It is not safe to skip them.</p>
+</div>
+</div>
+</div>
+<div class="section" id="bitcode-wrapper-format">
+<span id="wrapper"></span><h2><a class="toc-backref" href="#id29">Bitcode Wrapper Format</a><a class="headerlink" href="#bitcode-wrapper-format" title="Permalink to this headline">¶</a></h2>
+<p>Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
+structure. This structure contains a simple header that indicates the offset
+and size of the embedded BC file. This allows additional information to be
+stored alongside the BC file. The structure of this file header is:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>, Size<sub>32</sub>, CPUType<sub>32</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+<p>Each of the fields are 32-bit fields stored in little endian form (as with the
+rest of the bitcode file fields). The Magic number is always <tt class="docutils literal"><span class="pre">0x0B17C0DE</span></tt> and
+the version is currently always <tt class="docutils literal"><span class="pre">0</span></tt>. The Offset field is the offset in bytes
+to the start of the bitcode stream in the file, and the Size field is the size
+in bytes of the stream. CPUType is a target-specific value that can be used to
+encode the CPU of the target.</p>
+</div>
+<div class="section" id="native-object-file-wrapper-format">
+<span id="native-object-file"></span><h2><a class="toc-backref" href="#id30">Native Object File Wrapper Format</a><a class="headerlink" href="#native-object-file-wrapper-format" title="Permalink to this headline">¶</a></h2>
+<p>Bitcode files for LLVM IR may also be wrapped in a native object file
+(i.e. ELF, COFF, Mach-O). The bitcode must be stored in a section of the object
+file named <tt class="docutils literal"><span class="pre">__LLVM,__bitcode</span></tt> for MachO and <tt class="docutils literal"><span class="pre">.llvmbc</span></tt> for the other object
+formats. This wrapper format is useful for accommodating LTO in compilation
+pipelines where intermediate objects must be native object files which contain
+metadata in other sections.</p>
+<p>Not all tools support this format.</p>
+</div>
+<div class="section" id="llvm-ir-encoding">
+<span id="encoding-of-llvm-ir"></span><h2><a class="toc-backref" href="#id31">LLVM IR Encoding</a><a class="headerlink" href="#llvm-ir-encoding" title="Permalink to this headline">¶</a></h2>
+<p>LLVM IR is encoded into a bitstream by defining blocks and records. It uses
+blocks for things like constant pools, functions, symbol tables, etc. It uses
+records for things like instructions, global variable descriptors, type
+descriptions, etc. This document does not describe the set of abbreviations
+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 class="section" id="basics">
+<h3><a class="toc-backref" href="#id32">Basics</a><a class="headerlink" href="#basics" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="llvm-ir-magic-number">
+<h4><a class="toc-backref" href="#id33">LLVM IR Magic Number</a><a class="headerlink" href="#llvm-ir-magic-number" title="Permalink to this headline">¶</a></h4>
+<p>The magic number for LLVM IR files is:</p>
+<p><span class="raw-html"><tt><blockquote></span>
+[‘B’<sub>8</sub>, ‘C’<sub>8</sub>, 0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]
+<span class="raw-html"></blockquote></tt></span></p>
+</div>
+<div class="section" id="signed-vbrs">
+<span id="id8"></span><h4><a class="toc-backref" href="#id34">Signed VBRs</a><a class="headerlink" href="#signed-vbrs" title="Permalink to this headline">¶</a></h4>
+<p><a class="reference internal" href="#variable-width-integer">Variable Width Integer</a> encoding is an efficient way to encode arbitrary sized
+unsigned values, but is an extremely inefficient for encoding signed values, as
+signed values are otherwise treated as maximally large unsigned values.</p>
+<p>As such, signed VBR values of a specific width are emitted as follows:</p>
+<ul class="simple">
+<li>Positive values are emitted as VBRs of the specified width, but with their
+value shifted left by one.</li>
+<li>Negative values are emitted as VBRs of the specified width, but the negated
+value is shifted left by one, and the low bit is set.</li>
+</ul>
+<p>With this encoding, small positive and small negative values can both be emitted
+efficiently. Signed VBR encoding is used in <tt class="docutils literal"><span class="pre">CST_CODE_INTEGER</span></tt> and
+<tt class="docutils literal"><span class="pre">CST_CODE_WIDE_INTEGER</span></tt> records within <tt class="docutils literal"><span class="pre">CONSTANTS_BLOCK</span></tt> blocks.
+It is also used for phi instruction operands in <a class="reference internal" href="#module-code-version">MODULE_CODE_VERSION</a> 1.</p>
+</div>
+<div class="section" id="llvm-ir-blocks">
+<h4><a class="toc-backref" href="#id35">LLVM IR Blocks</a><a class="headerlink" href="#llvm-ir-blocks" title="Permalink to this headline">¶</a></h4>
+<p>LLVM IR is defined with the following blocks:</p>
+<ul class="simple">
+<li>8 — <a class="reference internal" href="#module-block">MODULE_BLOCK</a> — This is the top-level block that contains the entire
+module, and describes a variety of per-module information.</li>
+<li>9 — <a class="reference internal" href="#paramattr-block">PARAMATTR_BLOCK</a> — This enumerates the parameter attributes.</li>
+<li>10 — <a class="reference internal" href="#paramattr-group-block">PARAMATTR_GROUP_BLOCK</a> — This describes the attribute group table.</li>
+<li>11 — <a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a> — This describes constants for a module or
+function.</li>
+<li>12 — <a class="reference internal" href="#function-block">FUNCTION_BLOCK</a> — This describes a function body.</li>
+<li>14 — <a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a> — This describes a value symbol table.</li>
+<li>15 — <a class="reference internal" href="#metadata-block">METADATA_BLOCK</a> — This describes metadata items.</li>
+<li>16 — <a class="reference internal" href="#metadata-attachment">METADATA_ATTACHMENT</a> — This contains records associating metadata
+with function instruction values.</li>
+<li>17 — <a class="reference internal" href="#type-block">TYPE_BLOCK</a> — This describes all of the types in the module.</li>
+<li>23 — <a class="reference internal" href="#strtab-block">STRTAB_BLOCK</a> — The bitcode file’s string table.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="module-block-contents">
+<span id="module-block"></span><h3><a class="toc-backref" href="#id36">MODULE_BLOCK Contents</a><a class="headerlink" href="#module-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt> block (id 8) is the top-level block for LLVM bitcode files,
+and each bitcode file must contain exactly one. In addition to records
+(described below) containing information about the module, a <tt class="docutils literal"><span class="pre">MODULE_BLOCK</span></tt>
+block may contain the following sub-blocks:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#blockinfo">BLOCKINFO</a></li>
+<li><a class="reference internal" href="#paramattr-block">PARAMATTR_BLOCK</a></li>
+<li><a class="reference internal" href="#paramattr-group-block">PARAMATTR_GROUP_BLOCK</a></li>
+<li><a class="reference internal" href="#type-block">TYPE_BLOCK</a></li>
+<li><a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a></li>
+<li><a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a></li>
+<li><a class="reference internal" href="#function-block">FUNCTION_BLOCK</a></li>
+<li><a class="reference internal" href="#metadata-block">METADATA_BLOCK</a></li>
+</ul>
+<div class="section" id="module-code-version-record">
+<span id="module-code-version"></span><h4><a class="toc-backref" href="#id37">MODULE_CODE_VERSION Record</a><a class="headerlink" href="#module-code-version-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VERSION,</span> <span class="pre">version#]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VERSION</span></tt> record (code 1) contains a single value indicating the format
+version. Versions 0, 1 and 2 are supported at this time. The difference between
+version 0 and 1 is in the encoding of instruction operands in
+each <a class="reference internal" href="#function-block">FUNCTION_BLOCK</a>.</p>
+<p>In version 0, each value defined by an instruction is assigned an ID
+unique to the function. Function-level value IDs are assigned starting from
+<tt class="docutils literal"><span class="pre">NumModuleValues</span></tt> since they share the same namespace as module-level
+values. The value enumerator resets after each function. When a value is
+an operand of an instruction, the value ID is used to represent the operand.
+For large functions or large modules, these operand values can be large.</p>
+<p>The encoding in version 1 attempts to avoid large operand values
+in common cases. Instead of using the value ID directly, operands are
+encoded as relative to the current instruction. Thus, if an operand
+is the value defined by the previous instruction, the operand
+will be encoded as 1.</p>
+<p>For example, instead of</p>
+<div class="highlight-none"><div class="highlight"><pre>#n = load #n-1
+#n+1 = icmp eq #n, #const0
+br #n+1, label #(bb1), label #(bb2)
+</pre></div>
+</div>
+<p>version 1 will encode the instructions as</p>
+<div class="highlight-none"><div class="highlight"><pre>#n = load #1
+#n+1 = icmp eq #1, (#n+1)-#const0
+br #1, label #(bb1), label #(bb2)
+</pre></div>
+</div>
+<p>Note in the example that operands which are constants also use
+the relative encoding, while operands like basic block labels
+do not use the relative encoding.</p>
+<p>Forward references will result in a negative value.
+This can be inefficient, as operands are normally encoded
+as unsigned VBRs. However, forward references are rare, except in the
+case of phi instructions. For phi instructions, operands are encoded as
+<a class="reference internal" href="#signed-vbrs">Signed VBRs</a> to deal with forward references.</p>
+<p>In version 2, the meaning of module records <tt class="docutils literal"><span class="pre">FUNCTION</span></tt>, <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt>,
+<tt class="docutils literal"><span class="pre">ALIAS</span></tt>, <tt class="docutils literal"><span class="pre">IFUNC</span></tt> and <tt class="docutils literal"><span class="pre">COMDAT</span></tt> change such that the first two operands
+specify an offset and size of a string in a string table (see <a class="reference internal" href="#strtab-block-contents">STRTAB_BLOCK
+Contents</a>), the function name is removed from the <tt class="docutils literal"><span class="pre">FNENTRY</span></tt> record in the
+value symbol table, and the top-level <tt class="docutils literal"><span class="pre">VALUE_SYMTAB_BLOCK</span></tt> may only contain
+<tt class="docutils literal"><span class="pre">FNENTRY</span></tt> records.</p>
+</div>
+<div class="section" id="module-code-triple-record">
+<h4><a class="toc-backref" href="#id38">MODULE_CODE_TRIPLE Record</a><a class="headerlink" href="#module-code-triple-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[TRIPLE,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">TRIPLE</span></tt> record (code 2) contains a variable number of values representing
+the bytes of the <tt class="docutils literal"><span class="pre">target</span> <span class="pre">triple</span></tt> specification string.</p>
+</div>
+<div class="section" id="module-code-datalayout-record">
+<h4><a class="toc-backref" href="#id39">MODULE_CODE_DATALAYOUT Record</a><a class="headerlink" href="#module-code-datalayout-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DATALAYOUT,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DATALAYOUT</span></tt> record (code 3) contains a variable number of values
+representing the bytes of the <tt class="docutils literal"><span class="pre">target</span> <span class="pre">datalayout</span></tt> specification string.</p>
+</div>
+<div class="section" id="module-code-asm-record">
+<h4><a class="toc-backref" href="#id40">MODULE_CODE_ASM Record</a><a class="headerlink" href="#module-code-asm-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ASM,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ASM</span></tt> record (code 4) contains a variable number of values representing
+the bytes of <tt class="docutils literal"><span class="pre">module</span> <span class="pre">asm</span></tt> strings, with individual assembly blocks separated
+by newline (ASCII 10) characters.</p>
+</div>
+<div class="section" id="module-code-sectionname-record">
+<span id="module-code-sectionname"></span><h4><a class="toc-backref" href="#id41">MODULE_CODE_SECTIONNAME Record</a><a class="headerlink" href="#module-code-sectionname-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[SECTIONNAME,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">SECTIONNAME</span></tt> record (code 5) contains a variable number of values
+representing the bytes of a single section name string. There should be one
+<tt class="docutils literal"><span class="pre">SECTIONNAME</span></tt> record for each section name referenced (e.g., in global
+variable or function <tt class="docutils literal"><span class="pre">section</span></tt> attributes) within the module. These records
+can be referenced by the 1-based index in the <em>section</em> fields of <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt>
+or <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> records.</p>
+</div>
+<div class="section" id="module-code-deplib-record">
+<h4><a class="toc-backref" href="#id42">MODULE_CODE_DEPLIB Record</a><a class="headerlink" href="#module-code-deplib-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DEPLIB,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DEPLIB</span></tt> record (code 6) contains a variable number of values representing
+the bytes of a single dependent library name string, one of the libraries
+mentioned in a <tt class="docutils literal"><span class="pre">deplibs</span></tt> declaration. There should be one <tt class="docutils literal"><span class="pre">DEPLIB</span></tt> record
+for each library name referenced.</p>
+</div>
+<div class="section" id="module-code-globalvar-record">
+<h4><a class="toc-backref" href="#id43">MODULE_CODE_GLOBALVAR Record</a><a class="headerlink" href="#module-code-globalvar-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[GLOBALVAR,</span> <span class="pre">strtab</span> <span class="pre">offset,</span> <span class="pre">strtab</span> <span class="pre">size,</span> <span class="pre">pointer</span> <span class="pre">type,</span> <span class="pre">isconst,</span> <span class="pre">initid,</span> <span class="pre">linkage,</span> <span class="pre">alignment,</span> <span class="pre">section,</span> <span class="pre">visibility,</span> <span class="pre">threadlocal,</span> <span class="pre">unnamed_addr,</span> <span class="pre">externally_initialized,</span> <span class="pre">dllstorageclass,</span> <span class="pre">comdat,</span> <span class="pre">attributes,</span> <span class="pre">preemptionspecifier]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">GLOBALVAR</span></tt> record (code 7) marks the declaration or definition of a
+global variable. The operand fields are:</p>
+<ul class="simple">
+<li><em>strtab offset</em>, <em>strtab size</em>: Specifies the name of the global variable.
+See <a class="reference internal" href="#strtab-block-contents">STRTAB_BLOCK Contents</a>.</li>
+<li><em>pointer type</em>: The type index of the pointer type used to point to this
+global variable</li>
+<li><em>isconst</em>: Non-zero if the variable is treated as constant within the module,
+or zero if it is not</li>
+<li><em>initid</em>: If non-zero, the value index of the initializer for this variable,
+plus 1.</li>
+</ul>
+<ul class="simple" id="linkage-type">
+<li><em>linkage</em>: An encoding of the linkage type for this variable:<ul>
+<li><tt class="docutils literal"><span class="pre">external</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">weak</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">appending</span></tt>: code 2</li>
+<li><tt class="docutils literal"><span class="pre">internal</span></tt>: code 3</li>
+<li><tt class="docutils literal"><span class="pre">linkonce</span></tt>: code 4</li>
+<li><tt class="docutils literal"><span class="pre">dllimport</span></tt>: code 5</li>
+<li><tt class="docutils literal"><span class="pre">dllexport</span></tt>: code 6</li>
+<li><tt class="docutils literal"><span class="pre">extern_weak</span></tt>: code 7</li>
+<li><tt class="docutils literal"><span class="pre">common</span></tt>: code 8</li>
+<li><tt class="docutils literal"><span class="pre">private</span></tt>: code 9</li>
+<li><tt class="docutils literal"><span class="pre">weak_odr</span></tt>: code 10</li>
+<li><tt class="docutils literal"><span class="pre">linkonce_odr</span></tt>: code 11</li>
+<li><tt class="docutils literal"><span class="pre">available_externally</span></tt>: code 12</li>
+<li>deprecated : code 13</li>
+<li>deprecated : code 14</li>
+</ul>
+</li>
+<li>alignment*: The logarithm base 2 of the variable’s requested alignment, plus 1</li>
+<li><em>section</em>: If non-zero, the 1-based section index in the table of
+<a class="reference internal" href="#module-code-sectionname">MODULE_CODE_SECTIONNAME</a> entries.</li>
+</ul>
+<ul class="simple" id="visibility">
+<li><em>visibility</em>: If present, an encoding of the visibility of this variable:<ul>
+<li><tt class="docutils literal"><span class="pre">default</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">hidden</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">protected</span></tt>: code 2</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcthreadlocal">
+<li><em>threadlocal</em>: If present, an encoding of the thread local storage mode of the
+variable:<ul>
+<li><tt class="docutils literal"><span class="pre">not</span> <span class="pre">thread</span> <span class="pre">local</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">thread</span> <span class="pre">local;</span> <span class="pre">default</span> <span class="pre">TLS</span> <span class="pre">model</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">localdynamic</span></tt>: code 2</li>
+<li><tt class="docutils literal"><span class="pre">initialexec</span></tt>: code 3</li>
+<li><tt class="docutils literal"><span class="pre">localexec</span></tt>: code 4</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcunnamedaddr">
+<li><em>unnamed_addr</em>: If present, an encoding of the <tt class="docutils literal"><span class="pre">unnamed_addr</span></tt> attribute of this
+variable:<ul>
+<li>not <tt class="docutils literal"><span class="pre">unnamed_addr</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">unnamed_addr</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">local_unnamed_addr</span></tt>: code 2</li>
+</ul>
+</li>
+</ul>
+<ul class="simple" id="bcdllstorageclass">
+<li><em>dllstorageclass</em>: If present, an encoding of the DLL storage class of this variable:<ul>
+<li><tt class="docutils literal"><span class="pre">default</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">dllimport</span></tt>: code 1</li>
+<li><tt class="docutils literal"><span class="pre">dllexport</span></tt>: code 2</li>
+</ul>
+</li>
+<li><em>comdat</em>: An encoding of the COMDAT of this function</li>
+<li><em>attributes</em>: If nonzero, the 1-based index into the table of AttributeLists.</li>
+</ul>
+<ul class="simple" id="bcpreemptionspecifier">
+<li><em>preemptionspecifier</em>: If present, an encoding of the runtime preemption specifier of this variable:<ul>
+<li><tt class="docutils literal"><span class="pre">dso_preemptable</span></tt>: code 0</li>
+<li><tt class="docutils literal"><span class="pre">dso_local</span></tt>: code 1</li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="module-code-function-record">
+<span id="function"></span><h4><a class="toc-backref" href="#id44">MODULE_CODE_FUNCTION Record</a><a class="headerlink" href="#module-code-function-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FUNCTION,</span> <span class="pre">strtab</span> <span class="pre">offset,</span> <span class="pre">strtab</span> <span class="pre">size,</span> <span class="pre">type,</span> <span class="pre">callingconv,</span> <span class="pre">isproto,</span> <span class="pre">linkage,</span> <span class="pre">paramattr,</span> <span class="pre">alignment,</span> <span class="pre">section,</span> <span class="pre">visibility,</span> <span class="pre">gc,</span> <span class="pre">prologuedata,</span> <span class="pre">dllstorageclass,</span> <span class="pre">comdat,</span> <span class="pre">prefixdata,</span> <span class="pre">personalityfn,</span> <span class="pre">preemptionspecifier]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> record (code 8) marks the declaration or definition of a
+function. The operand fields are:</p>
+<ul class="simple">
+<li><em>strtab offset</em>, <em>strtab size</em>: Specifies the name of the function.
+See <a class="reference internal" href="#strtab-block-contents">STRTAB_BLOCK Contents</a>.</li>
+<li><em>type</em>: The type index of the function type describing this function</li>
+<li><em>callingconv</em>: The calling convention number:
+* <tt class="docutils literal"><span class="pre">ccc</span></tt>: code 0
+* <tt class="docutils literal"><span class="pre">fastcc</span></tt>: code 8
+* <tt class="docutils literal"><span class="pre">coldcc</span></tt>: code 9
+* <tt class="docutils literal"><span class="pre">webkit_jscc</span></tt>: code 12
+* <tt class="docutils literal"><span class="pre">anyregcc</span></tt>: code 13
+* <tt class="docutils literal"><span class="pre">preserve_mostcc</span></tt>: code 14
+* <tt class="docutils literal"><span class="pre">preserve_allcc</span></tt>: code 15
+* <tt class="docutils literal"><span class="pre">swiftcc</span></tt> : code 16
+* <tt class="docutils literal"><span class="pre">cxx_fast_tlscc</span></tt>: code 17
+* <tt class="docutils literal"><span class="pre">x86_stdcallcc</span></tt>: code 64
+* <tt class="docutils literal"><span class="pre">x86_fastcallcc</span></tt>: code 65
+* <tt class="docutils literal"><span class="pre">arm_apcscc</span></tt>: code 66
+* <tt class="docutils literal"><span class="pre">arm_aapcscc</span></tt>: code 67
+* <tt class="docutils literal"><span class="pre">arm_aapcs_vfpcc</span></tt>: code 68</li>
+<li>isproto*: Non-zero if this entry represents a declaration rather than a
+definition</li>
+<li><em>linkage</em>: An encoding of the <a class="reference internal" href="#linkage-type">linkage type</a> for this function</li>
+<li><em>paramattr</em>: If nonzero, the 1-based parameter attribute index into the table
+of <a class="reference internal" href="#paramattr-code-entry">PARAMATTR_CODE_ENTRY</a> entries.</li>
+<li><em>alignment</em>: The logarithm base 2 of the function’s requested alignment, plus
+1</li>
+<li><em>section</em>: If non-zero, the 1-based section index in the table of
+<a class="reference internal" href="#module-code-sectionname">MODULE_CODE_SECTIONNAME</a> entries.</li>
+<li><em>visibility</em>: An encoding of the <a class="reference internal" href="#visibility">visibility</a> of this function</li>
+<li><em>gc</em>: If present and nonzero, the 1-based garbage collector index in the table
+of <a class="reference internal" href="#module-code-gcname">MODULE_CODE_GCNAME</a> entries.</li>
+<li><em>unnamed_addr</em>: If present, an encoding of the
+<a class="reference internal" href="#bcunnamedaddr"><em>unnamed_addr</em></a> attribute of this function</li>
+<li><em>prologuedata</em>: If non-zero, the value index of the prologue data for this function,
+plus 1.</li>
+<li><em>dllstorageclass</em>: An encoding of the
+<a class="reference internal" href="#bcdllstorageclass"><em>dllstorageclass</em></a> of this function</li>
+<li><em>comdat</em>: An encoding of the COMDAT of this function</li>
+<li><em>prefixdata</em>: If non-zero, the value index of the prefix data for this function,
+plus 1.</li>
+<li><em>personalityfn</em>: If non-zero, the value index of the personality function for this function,
+plus 1.</li>
+<li><em>preemptionspecifier</em>: If present, an encoding of the <a class="reference internal" href="#bcpreemptionspecifier"><em>runtime preemption specifier</em></a> of this function.</li>
+</ul>
+</div>
+<div class="section" id="module-code-alias-record">
+<h4><a class="toc-backref" href="#id45">MODULE_CODE_ALIAS Record</a><a class="headerlink" href="#module-code-alias-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ALIAS,</span> <span class="pre">strtab</span> <span class="pre">offset,</span> <span class="pre">strtab</span> <span class="pre">size,</span> <span class="pre">alias</span> <span class="pre">type,</span> <span class="pre">aliasee</span> <span class="pre">val#,</span> <span class="pre">linkage,</span> <span class="pre">visibility,</span> <span class="pre">dllstorageclass,</span> <span class="pre">threadlocal,</span> <span class="pre">unnamed_addr,</span> <span class="pre">preemptionspecifier]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ALIAS</span></tt> record (code 9) marks the definition of an alias. The operand
+fields are</p>
+<ul class="simple">
+<li><em>strtab offset</em>, <em>strtab size</em>: Specifies the name of the alias.
+See <a class="reference internal" href="#strtab-block-contents">STRTAB_BLOCK Contents</a>.</li>
+<li><em>alias type</em>: The type index of the alias</li>
+<li><em>aliasee val#</em>: The value index of the aliased value</li>
+<li><em>linkage</em>: An encoding of the <a class="reference internal" href="#linkage-type">linkage type</a> for this alias</li>
+<li><em>visibility</em>: If present, an encoding of the <a class="reference internal" href="#visibility">visibility</a> of the alias</li>
+<li><em>dllstorageclass</em>: If present, an encoding of the
+<a class="reference internal" href="#bcdllstorageclass"><em>dllstorageclass</em></a> of the alias</li>
+<li><em>threadlocal</em>: If present, an encoding of the
+<a class="reference internal" href="#bcthreadlocal"><em>thread local property</em></a> of the alias</li>
+<li><em>unnamed_addr</em>: If present, an encoding of the
+<a class="reference internal" href="#bcunnamedaddr"><em>unnamed_addr</em></a> attribute of this alias</li>
+<li><em>preemptionspecifier</em>: If present, an encoding of the <a class="reference internal" href="#bcpreemptionspecifier"><em>runtime preemption specifier</em></a> of this alias.</li>
+</ul>
+</div>
+<div class="section" id="module-code-gcname-record">
+<span id="module-code-gcname"></span><h4><a class="toc-backref" href="#id46">MODULE_CODE_GCNAME Record</a><a class="headerlink" href="#module-code-gcname-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[GCNAME,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">GCNAME</span></tt> record (code 11) contains a variable number of values
+representing the bytes of a single garbage collector name string. There should
+be one <tt class="docutils literal"><span class="pre">GCNAME</span></tt> record for each garbage collector name referenced in function
+<tt class="docutils literal"><span class="pre">gc</span></tt> attributes within the module. These records can be referenced by 1-based
+index in the <em>gc</em> fields of <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> records.</p>
+</div>
+</div>
+<div class="section" id="paramattr-block-contents">
+<span id="paramattr-block"></span><h3><a class="toc-backref" href="#id47">PARAMATTR_BLOCK Contents</a><a class="headerlink" href="#paramattr-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">PARAMATTR_BLOCK</span></tt> block (id 9) contains a table of entries describing the
+attributes of function parameters. These entries are referenced by 1-based index
+in the <em>paramattr</em> field of module block <a class="reference internal" href="#function">FUNCTION</a> records, or within the
+<em>attr</em> field of function block <tt class="docutils literal"><span class="pre">INST_INVOKE</span></tt> and <tt class="docutils literal"><span class="pre">INST_CALL</span></tt> records.</p>
+<p>Entries within <tt class="docutils literal"><span class="pre">PARAMATTR_BLOCK</span></tt> are constructed to ensure that each is unique
+(i.e., no two indices represent equivalent attribute lists).</p>
+<div class="section" id="paramattr-code-entry-record">
+<span id="paramattr-code-entry"></span><h4><a class="toc-backref" href="#id48">PARAMATTR_CODE_ENTRY Record</a><a class="headerlink" href="#paramattr-code-entry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ENTRY,</span> <span class="pre">attrgrp0,</span> <span class="pre">attrgrp1,</span> <span class="pre">...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTRY</span></tt> record (code 2) contains a variable number of values describing a
+unique set of function parameter attributes. Each <em>attrgrp</em> value is used as a
+key with which to look up an entry in the attribute group table described
+in the <tt class="docutils literal"><span class="pre">PARAMATTR_GROUP_BLOCK</span></tt> block.</p>
+</div>
+<div class="section" id="paramattr-code-entry-old-record">
+<span id="paramattr-code-entry-old"></span><h4><a class="toc-backref" href="#id49">PARAMATTR_CODE_ENTRY_OLD Record</a><a class="headerlink" href="#paramattr-code-entry-old-record" title="Permalink to this headline">¶</a></h4>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This is a legacy encoding for attributes, produced by LLVM versions 3.2 and
+earlier. It is guaranteed to be understood by the current LLVM version, as
+specified in the <a class="reference internal" href="DeveloperPolicy.html#ir-backwards-compatibility"><em>IR Backwards Compatibility</em></a> policy.</p>
+</div>
+<p><tt class="docutils literal"><span class="pre">[ENTRY,</span> <span class="pre">paramidx0,</span> <span class="pre">attr0,</span> <span class="pre">paramidx1,</span> <span class="pre">attr1...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTRY</span></tt> record (code 1) contains an even number of values describing a
+unique set of function parameter attributes. Each <em>paramidx</em> value indicates
+which set of attributes is represented, with 0 representing the return value
+attributes, 0xFFFFFFFF representing function attributes, and other values
+representing 1-based function parameters. Each <em>attr</em> value is a bitmap with the
+following interpretation:</p>
+<ul class="simple">
+<li>bit 0: <tt class="docutils literal"><span class="pre">zeroext</span></tt></li>
+<li>bit 1: <tt class="docutils literal"><span class="pre">signext</span></tt></li>
+<li>bit 2: <tt class="docutils literal"><span class="pre">noreturn</span></tt></li>
+<li>bit 3: <tt class="docutils literal"><span class="pre">inreg</span></tt></li>
+<li>bit 4: <tt class="docutils literal"><span class="pre">sret</span></tt></li>
+<li>bit 5: <tt class="docutils literal"><span class="pre">nounwind</span></tt></li>
+<li>bit 6: <tt class="docutils literal"><span class="pre">noalias</span></tt></li>
+<li>bit 7: <tt class="docutils literal"><span class="pre">byval</span></tt></li>
+<li>bit 8: <tt class="docutils literal"><span class="pre">nest</span></tt></li>
+<li>bit 9: <tt class="docutils literal"><span class="pre">readnone</span></tt></li>
+<li>bit 10: <tt class="docutils literal"><span class="pre">readonly</span></tt></li>
+<li>bit 11: <tt class="docutils literal"><span class="pre">noinline</span></tt></li>
+<li>bit 12: <tt class="docutils literal"><span class="pre">alwaysinline</span></tt></li>
+<li>bit 13: <tt class="docutils literal"><span class="pre">optsize</span></tt></li>
+<li>bit 14: <tt class="docutils literal"><span class="pre">ssp</span></tt></li>
+<li>bit 15: <tt class="docutils literal"><span class="pre">sspreq</span></tt></li>
+<li>bits 16-31: <tt class="docutils literal"><span class="pre">align</span> <span class="pre">n</span></tt></li>
+<li>bit 32: <tt class="docutils literal"><span class="pre">nocapture</span></tt></li>
+<li>bit 33: <tt class="docutils literal"><span class="pre">noredzone</span></tt></li>
+<li>bit 34: <tt class="docutils literal"><span class="pre">noimplicitfloat</span></tt></li>
+<li>bit 35: <tt class="docutils literal"><span class="pre">naked</span></tt></li>
+<li>bit 36: <tt class="docutils literal"><span class="pre">inlinehint</span></tt></li>
+<li>bits 37-39: <tt class="docutils literal"><span class="pre">alignstack</span> <span class="pre">n</span></tt>, represented as the logarithm
+base 2 of the requested alignment, plus 1</li>
+</ul>
+</div>
+</div>
+<div class="section" id="paramattr-group-block-contents">
+<span id="paramattr-group-block"></span><h3><a class="toc-backref" href="#id50">PARAMATTR_GROUP_BLOCK Contents</a><a class="headerlink" href="#paramattr-group-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">PARAMATTR_GROUP_BLOCK</span></tt> block (id 10) contains a table of entries
+describing the attribute groups present in the module. These entries can be
+referenced within <tt class="docutils literal"><span class="pre">PARAMATTR_CODE_ENTRY</span></tt> entries.</p>
+<div class="section" id="paramattr-grp-code-entry-record">
+<span id="paramattr-grp-code-entry"></span><h4><a class="toc-backref" href="#id51">PARAMATTR_GRP_CODE_ENTRY Record</a><a class="headerlink" href="#paramattr-grp-code-entry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ENTRY,</span> <span class="pre">grpid,</span> <span class="pre">paramidx,</span> <span class="pre">attr0,</span> <span class="pre">attr1,</span> <span class="pre">...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ENTRY</span></tt> record (code 3) contains <em>grpid</em> and <em>paramidx</em> values, followed
+by a variable number of values describing a unique group of attributes. The
+<em>grpid</em> value is a unique key for the attribute group, which can be referenced
+within <tt class="docutils literal"><span class="pre">PARAMATTR_CODE_ENTRY</span></tt> entries. The <em>paramidx</em> value indicates which
+set of attributes is represented, with 0 representing the return value
+attributes, 0xFFFFFFFF representing function attributes, and other values
+representing 1-based function parameters.</p>
+<p>Each <em>attr</em> is itself represented as a variable number of values:</p>
+<p><tt class="docutils literal"><span class="pre">kind,</span> <span class="pre">key</span> <span class="pre">[,</span> <span class="pre">...],</span> <span class="pre">[value</span> <span class="pre">[,</span> <span class="pre">...]]</span></tt></p>
+<p>Each attribute is either a well-known LLVM attribute (possibly with an integer
+value associated with it), or an arbitrary string (possibly with an arbitrary
+string value associated with it). The <em>kind</em> value is an integer code
+distinguishing between these possibilities:</p>
+<ul class="simple">
+<li>code 0: well-known attribute</li>
+<li>code 1: well-known attribute with an integer value</li>
+<li>code 3: string attribute</li>
+<li>code 4: string attribute with a string value</li>
+</ul>
+<p>For well-known attributes (code 0 or 1), the <em>key</em> value is an integer code
+identifying the attribute. For attributes with an integer argument (code 1),
+the <em>value</em> value indicates the argument.</p>
+<p>For string attributes (code 3 or 4), the <em>key</em> value is actually a variable
+number of values representing the bytes of a null-terminated string. For
+attributes with a string argument (code 4), the <em>value</em> value is similarly a
+variable number of values representing the bytes of a null-terminated string.</p>
+<p>The integer codes are mapped to well-known attributes as follows.</p>
+<ul class="simple">
+<li>code 1: <tt class="docutils literal"><span class="pre">align(<n>)</span></tt></li>
+<li>code 2: <tt class="docutils literal"><span class="pre">alwaysinline</span></tt></li>
+<li>code 3: <tt class="docutils literal"><span class="pre">byval</span></tt></li>
+<li>code 4: <tt class="docutils literal"><span class="pre">inlinehint</span></tt></li>
+<li>code 5: <tt class="docutils literal"><span class="pre">inreg</span></tt></li>
+<li>code 6: <tt class="docutils literal"><span class="pre">minsize</span></tt></li>
+<li>code 7: <tt class="docutils literal"><span class="pre">naked</span></tt></li>
+<li>code 8: <tt class="docutils literal"><span class="pre">nest</span></tt></li>
+<li>code 9: <tt class="docutils literal"><span class="pre">noalias</span></tt></li>
+<li>code 10: <tt class="docutils literal"><span class="pre">nobuiltin</span></tt></li>
+<li>code 11: <tt class="docutils literal"><span class="pre">nocapture</span></tt></li>
+<li>code 12: <tt class="docutils literal"><span class="pre">noduplicates</span></tt></li>
+<li>code 13: <tt class="docutils literal"><span class="pre">noimplicitfloat</span></tt></li>
+<li>code 14: <tt class="docutils literal"><span class="pre">noinline</span></tt></li>
+<li>code 15: <tt class="docutils literal"><span class="pre">nonlazybind</span></tt></li>
+<li>code 16: <tt class="docutils literal"><span class="pre">noredzone</span></tt></li>
+<li>code 17: <tt class="docutils literal"><span class="pre">noreturn</span></tt></li>
+<li>code 18: <tt class="docutils literal"><span class="pre">nounwind</span></tt></li>
+<li>code 19: <tt class="docutils literal"><span class="pre">optsize</span></tt></li>
+<li>code 20: <tt class="docutils literal"><span class="pre">readnone</span></tt></li>
+<li>code 21: <tt class="docutils literal"><span class="pre">readonly</span></tt></li>
+<li>code 22: <tt class="docutils literal"><span class="pre">returned</span></tt></li>
+<li>code 23: <tt class="docutils literal"><span class="pre">returns_twice</span></tt></li>
+<li>code 24: <tt class="docutils literal"><span class="pre">signext</span></tt></li>
+<li>code 25: <tt class="docutils literal"><span class="pre">alignstack(<n>)</span></tt></li>
+<li>code 26: <tt class="docutils literal"><span class="pre">ssp</span></tt></li>
+<li>code 27: <tt class="docutils literal"><span class="pre">sspreq</span></tt></li>
+<li>code 28: <tt class="docutils literal"><span class="pre">sspstrong</span></tt></li>
+<li>code 29: <tt class="docutils literal"><span class="pre">sret</span></tt></li>
+<li>code 30: <tt class="docutils literal"><span class="pre">sanitize_address</span></tt></li>
+<li>code 31: <tt class="docutils literal"><span class="pre">sanitize_thread</span></tt></li>
+<li>code 32: <tt class="docutils literal"><span class="pre">sanitize_memory</span></tt></li>
+<li>code 33: <tt class="docutils literal"><span class="pre">uwtable</span></tt></li>
+<li>code 34: <tt class="docutils literal"><span class="pre">zeroext</span></tt></li>
+<li>code 35: <tt class="docutils literal"><span class="pre">builtin</span></tt></li>
+<li>code 36: <tt class="docutils literal"><span class="pre">cold</span></tt></li>
+<li>code 37: <tt class="docutils literal"><span class="pre">optnone</span></tt></li>
+<li>code 38: <tt class="docutils literal"><span class="pre">inalloca</span></tt></li>
+<li>code 39: <tt class="docutils literal"><span class="pre">nonnull</span></tt></li>
+<li>code 40: <tt class="docutils literal"><span class="pre">jumptable</span></tt></li>
+<li>code 41: <tt class="docutils literal"><span class="pre">dereferenceable(<n>)</span></tt></li>
+<li>code 42: <tt class="docutils literal"><span class="pre">dereferenceable_or_null(<n>)</span></tt></li>
+<li>code 43: <tt class="docutils literal"><span class="pre">convergent</span></tt></li>
+<li>code 44: <tt class="docutils literal"><span class="pre">safestack</span></tt></li>
+<li>code 45: <tt class="docutils literal"><span class="pre">argmemonly</span></tt></li>
+<li>code 46: <tt class="docutils literal"><span class="pre">swiftself</span></tt></li>
+<li>code 47: <tt class="docutils literal"><span class="pre">swifterror</span></tt></li>
+<li>code 48: <tt class="docutils literal"><span class="pre">norecurse</span></tt></li>
+<li>code 49: <tt class="docutils literal"><span class="pre">inaccessiblememonly</span></tt></li>
+<li>code 50: <tt class="docutils literal"><span class="pre">inaccessiblememonly_or_argmemonly</span></tt></li>
+<li>code 51: <tt class="docutils literal"><span class="pre">allocsize(<EltSizeParam>[,</span> <span class="pre"><NumEltsParam>])</span></tt></li>
+<li>code 52: <tt class="docutils literal"><span class="pre">writeonly</span></tt></li>
+<li>code 53: <tt class="docutils literal"><span class="pre">speculatable</span></tt></li>
+<li>code 54: <tt class="docutils literal"><span class="pre">strictfp</span></tt></li>
+<li>code 55: <tt class="docutils literal"><span class="pre">sanitize_hwaddress</span></tt></li>
+<li>code 56: <tt class="docutils literal"><span class="pre">nocf_check</span></tt></li>
+<li>code 57: <tt class="docutils literal"><span class="pre">optforfuzzing</span></tt></li>
+<li>code 58: <tt class="docutils literal"><span class="pre">shadowcallstack</span></tt></li>
+</ul>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">The <tt class="docutils literal"><span class="pre">allocsize</span></tt> attribute has a special encoding for its arguments. Its two
+arguments, which are 32-bit integers, are packed into one 64-bit integer value
+(i.e. <tt class="docutils literal"><span class="pre">(EltSizeParam</span> <span class="pre"><<</span> <span class="pre">32)</span> <span class="pre">|</span> <span class="pre">NumEltsParam</span></tt>), with <tt class="docutils literal"><span class="pre">NumEltsParam</span></tt> taking on
+the sentinel value -1 if it is not specified.</p>
+</div>
+</div>
+</div>
+<div class="section" id="type-block-contents">
+<span id="type-block"></span><h3><a class="toc-backref" href="#id52">TYPE_BLOCK Contents</a><a class="headerlink" href="#type-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TYPE_BLOCK</span></tt> block (id 17) contains records which constitute a table of
+type operator entries used to represent types referenced within an LLVM
+module. Each record (with the exception of <a class="reference internal" href="#numentry">NUMENTRY</a>) generates a single type
+table entry, which may be referenced by 0-based index from instructions,
+constants, metadata, type symbol table entries, or other type operator records.</p>
+<p>Entries within <tt class="docutils literal"><span class="pre">TYPE_BLOCK</span></tt> are constructed to ensure that each entry is
+unique (i.e., no two indices represent structurally equivalent types).</p>
+<div class="section" id="type-code-numentry-record">
+<span id="numentry"></span><span id="type-code-numentry"></span><h4><a class="toc-backref" href="#id53">TYPE_CODE_NUMENTRY Record</a><a class="headerlink" href="#type-code-numentry-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[NUMENTRY,</span> <span class="pre">numentries]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">NUMENTRY</span></tt> record (code 1) contains a single value which indicates the
+total number of type code entries in the type table of the module. If present,
+<tt class="docutils literal"><span class="pre">NUMENTRY</span></tt> should be the first record in the block.</p>
+</div>
+<div class="section" id="type-code-void-record">
+<h4><a class="toc-backref" href="#id54">TYPE_CODE_VOID Record</a><a class="headerlink" href="#type-code-void-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VOID]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VOID</span></tt> record (code 2) adds a <tt class="docutils literal"><span class="pre">void</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-half-record">
+<h4><a class="toc-backref" href="#id55">TYPE_CODE_HALF Record</a><a class="headerlink" href="#type-code-half-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[HALF]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">HALF</span></tt> record (code 10) adds a <tt class="docutils literal"><span class="pre">half</span></tt> (16-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-float-record">
+<h4><a class="toc-backref" href="#id56">TYPE_CODE_FLOAT Record</a><a class="headerlink" href="#type-code-float-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FLOAT]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FLOAT</span></tt> record (code 3) adds a <tt class="docutils literal"><span class="pre">float</span></tt> (32-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-double-record">
+<h4><a class="toc-backref" href="#id57">TYPE_CODE_DOUBLE Record</a><a class="headerlink" href="#type-code-double-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[DOUBLE]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">DOUBLE</span></tt> record (code 4) adds a <tt class="docutils literal"><span class="pre">double</span></tt> (64-bit floating point) type to
+the type table.</p>
+</div>
+<div class="section" id="type-code-label-record">
+<h4><a class="toc-backref" href="#id58">TYPE_CODE_LABEL Record</a><a class="headerlink" href="#type-code-label-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[LABEL]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">LABEL</span></tt> record (code 5) adds a <tt class="docutils literal"><span class="pre">label</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-opaque-record">
+<h4><a class="toc-backref" href="#id59">TYPE_CODE_OPAQUE Record</a><a class="headerlink" href="#type-code-opaque-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[OPAQUE]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">OPAQUE</span></tt> record (code 6) adds an <tt class="docutils literal"><span class="pre">opaque</span></tt> type to the type table, with
+a name defined by a previously encountered <tt class="docutils literal"><span class="pre">STRUCT_NAME</span></tt> record. Note that
+distinct <tt class="docutils literal"><span class="pre">opaque</span></tt> types are not unified.</p>
+</div>
+<div class="section" id="type-code-integer-record">
+<h4><a class="toc-backref" href="#id60">TYPE_CODE_INTEGER Record</a><a class="headerlink" href="#type-code-integer-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[INTEGER,</span> <span class="pre">width]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">INTEGER</span></tt> record (code 7) adds an integer type to the type table. The
+single <em>width</em> field indicates the width of the integer type.</p>
+</div>
+<div class="section" id="type-code-pointer-record">
+<h4><a class="toc-backref" href="#id61">TYPE_CODE_POINTER Record</a><a class="headerlink" href="#type-code-pointer-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[POINTER,</span> <span class="pre">pointee</span> <span class="pre">type,</span> <span class="pre">address</span> <span class="pre">space]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">POINTER</span></tt> record (code 8) adds a pointer type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>pointee type</em>: The type index of the pointed-to type</li>
+<li><em>address space</em>: If supplied, the target-specific numbered address space where
+the pointed-to object resides. Otherwise, the default address space is zero.</li>
+</ul>
+</div>
+<div class="section" id="type-code-function-old-record">
+<h4><a class="toc-backref" href="#id62">TYPE_CODE_FUNCTION_OLD Record</a><a class="headerlink" href="#type-code-function-old-record" title="Permalink to this headline">¶</a></h4>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This is a legacy encoding for functions, produced by LLVM versions 3.0 and
+earlier. It is guaranteed to be understood by the current LLVM version, as
+specified in the <a class="reference internal" href="DeveloperPolicy.html#ir-backwards-compatibility"><em>IR Backwards Compatibility</em></a> policy.</p>
+</div>
+<p><tt class="docutils literal"><span class="pre">[FUNCTION_OLD,</span> <span class="pre">vararg,</span> <span class="pre">ignored,</span> <span class="pre">retty,</span> <span class="pre">...paramty...</span> <span class="pre">]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION_OLD</span></tt> record (code 9) adds a function type to the type table.
+The operand fields are</p>
+<ul class="simple">
+<li><em>vararg</em>: Non-zero if the type represents a varargs function</li>
+<li><em>ignored</em>: This value field is present for backward compatibility only, and is
+ignored</li>
+<li><em>retty</em>: The type index of the function’s return type</li>
+<li><em>paramty</em>: Zero or more type indices representing the parameter types of the
+function</li>
+</ul>
+</div>
+<div class="section" id="type-code-array-record">
+<h4><a class="toc-backref" href="#id63">TYPE_CODE_ARRAY Record</a><a class="headerlink" href="#type-code-array-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[ARRAY,</span> <span class="pre">numelts,</span> <span class="pre">eltty]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">ARRAY</span></tt> record (code 11) adds an array type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>numelts</em>: The number of elements in arrays of this type</li>
+<li><em>eltty</em>: The type index of the array element type</li>
+</ul>
+</div>
+<div class="section" id="type-code-vector-record">
+<h4><a class="toc-backref" href="#id64">TYPE_CODE_VECTOR Record</a><a class="headerlink" href="#type-code-vector-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[VECTOR,</span> <span class="pre">numelts,</span> <span class="pre">eltty]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">VECTOR</span></tt> record (code 12) adds a vector type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>numelts</em>: The number of elements in vectors of this type</li>
+<li><em>eltty</em>: The type index of the vector element type</li>
+</ul>
+</div>
+<div class="section" id="type-code-x86-fp80-record">
+<h4><a class="toc-backref" href="#id65">TYPE_CODE_X86_FP80 Record</a><a class="headerlink" href="#type-code-x86-fp80-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[X86_FP80]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">X86_FP80</span></tt> record (code 13) adds an <tt class="docutils literal"><span class="pre">x86_fp80</span></tt> (80-bit floating point)
+type to the type table.</p>
+</div>
+<div class="section" id="type-code-fp128-record">
+<h4><a class="toc-backref" href="#id66">TYPE_CODE_FP128 Record</a><a class="headerlink" href="#type-code-fp128-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FP128]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FP128</span></tt> record (code 14) adds an <tt class="docutils literal"><span class="pre">fp128</span></tt> (128-bit floating point) type
+to the type table.</p>
+</div>
+<div class="section" id="type-code-ppc-fp128-record">
+<h4><a class="toc-backref" href="#id67">TYPE_CODE_PPC_FP128 Record</a><a class="headerlink" href="#type-code-ppc-fp128-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[PPC_FP128]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">PPC_FP128</span></tt> record (code 15) adds a <tt class="docutils literal"><span class="pre">ppc_fp128</span></tt> (128-bit floating point)
+type to the type table.</p>
+</div>
+<div class="section" id="type-code-metadata-record">
+<h4><a class="toc-backref" href="#id68">TYPE_CODE_METADATA Record</a><a class="headerlink" href="#type-code-metadata-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[METADATA]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">METADATA</span></tt> record (code 16) adds a <tt class="docutils literal"><span class="pre">metadata</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-x86-mmx-record">
+<h4><a class="toc-backref" href="#id69">TYPE_CODE_X86_MMX Record</a><a class="headerlink" href="#type-code-x86-mmx-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[X86_MMX]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">X86_MMX</span></tt> record (code 17) adds an <tt class="docutils literal"><span class="pre">x86_mmx</span></tt> type to the type table.</p>
+</div>
+<div class="section" id="type-code-struct-anon-record">
+<h4><a class="toc-backref" href="#id70">TYPE_CODE_STRUCT_ANON Record</a><a class="headerlink" href="#type-code-struct-anon-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[STRUCT_ANON,</span> <span class="pre">ispacked,</span> <span class="pre">...eltty...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">STRUCT_ANON</span></tt> record (code 18) adds a literal struct type to the type
+table. The operand fields are</p>
+<ul class="simple">
+<li><em>ispacked</em>: Non-zero if the type represents a packed structure</li>
+<li><em>eltty</em>: Zero or more type indices representing the element types of the
+structure</li>
+</ul>
+</div>
+<div class="section" id="type-code-struct-name-record">
+<h4><a class="toc-backref" href="#id71">TYPE_CODE_STRUCT_NAME Record</a><a class="headerlink" href="#type-code-struct-name-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[STRUCT_NAME,</span> <span class="pre">...string...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">STRUCT_NAME</span></tt> record (code 19) contains a variable number of values
+representing the bytes of a struct name. The next <tt class="docutils literal"><span class="pre">OPAQUE</span></tt> or
+<tt class="docutils literal"><span class="pre">STRUCT_NAMED</span></tt> record will use this name.</p>
+</div>
+<div class="section" id="type-code-struct-named-record">
+<h4><a class="toc-backref" href="#id72">TYPE_CODE_STRUCT_NAMED Record</a><a class="headerlink" href="#type-code-struct-named-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[STRUCT_NAMED,</span> <span class="pre">ispacked,</span> <span class="pre">...eltty...]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">STRUCT_NAMED</span></tt> record (code 20) adds an identified struct type to the
+type table, with a name defined by a previously encountered <tt class="docutils literal"><span class="pre">STRUCT_NAME</span></tt>
+record. The operand fields are</p>
+<ul class="simple">
+<li><em>ispacked</em>: Non-zero if the type represents a packed structure</li>
+<li><em>eltty</em>: Zero or more type indices representing the element types of the
+structure</li>
+</ul>
+</div>
+<div class="section" id="type-code-function-record">
+<h4><a class="toc-backref" href="#id73">TYPE_CODE_FUNCTION Record</a><a class="headerlink" href="#type-code-function-record" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">[FUNCTION,</span> <span class="pre">vararg,</span> <span class="pre">retty,</span> <span class="pre">...paramty...</span> <span class="pre">]</span></tt></p>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION</span></tt> record (code 21) adds a function type to the type table. The
+operand fields are</p>
+<ul class="simple">
+<li><em>vararg</em>: Non-zero if the type represents a varargs function</li>
+<li><em>retty</em>: The type index of the function’s return type</li>
+<li><em>paramty</em>: Zero or more type indices representing the parameter types of the
+function</li>
+</ul>
+</div>
+</div>
+<div class="section" id="constants-block-contents">
+<span id="constants-block"></span><h3><a class="toc-backref" href="#id74">CONSTANTS_BLOCK Contents</a><a class="headerlink" href="#constants-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">CONSTANTS_BLOCK</span></tt> block (id 11) ...</p>
+</div>
+<div class="section" id="function-block-contents">
+<span id="function-block"></span><h3><a class="toc-backref" href="#id75">FUNCTION_BLOCK Contents</a><a class="headerlink" href="#function-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">FUNCTION_BLOCK</span></tt> block (id 12) ...</p>
+<p>In addition to the record types described below, a <tt class="docutils literal"><span class="pre">FUNCTION_BLOCK</span></tt> block may
+contain the following sub-blocks:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#constants-block">CONSTANTS_BLOCK</a></li>
+<li><a class="reference internal" href="#value-symtab-block">VALUE_SYMTAB_BLOCK</a></li>
+<li><a class="reference internal" href="#metadata-attachment">METADATA_ATTACHMENT</a></li>
+</ul>
+</div>
+<div class="section" id="value-symtab-block-contents">
+<span id="value-symtab-block"></span><h3><a class="toc-backref" href="#id76">VALUE_SYMTAB_BLOCK Contents</a><a class="headerlink" href="#value-symtab-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">VALUE_SYMTAB_BLOCK</span></tt> block (id 14) ...</p>
+</div>
+<div class="section" id="metadata-block-contents">
+<span id="metadata-block"></span><h3><a class="toc-backref" href="#id77">METADATA_BLOCK Contents</a><a class="headerlink" href="#metadata-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">METADATA_BLOCK</span></tt> block (id 15) ...</p>
+</div>
+<div class="section" id="metadata-attachment-contents">
+<span id="metadata-attachment"></span><h3><a class="toc-backref" href="#id78">METADATA_ATTACHMENT Contents</a><a class="headerlink" href="#metadata-attachment-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">METADATA_ATTACHMENT</span></tt> block (id 16) ...</p>
+</div>
+<div class="section" id="strtab-block-contents">
+<span id="strtab-block"></span><h3><a class="toc-backref" href="#id79">STRTAB_BLOCK Contents</a><a class="headerlink" href="#strtab-block-contents" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">STRTAB</span></tt> block (id 23) contains a single record (<tt class="docutils literal"><span class="pre">STRTAB_BLOB</span></tt>, id 1)
+with a single blob operand containing the bitcode file’s string table.</p>
+<p>Strings in the string table are not null terminated. A record’s <em>strtab
+offset</em> and <em>strtab size</em> operands specify the byte offset and size of a
+string within the string table.</p>
+<p>The string table is used by all preceding blocks in the bitcode file that are
+not succeeded by another intervening <tt class="docutils literal"><span class="pre">STRTAB</span></tt> block. Normally a bitcode
+file will have a single string table, but it may have more than one if it
+was created by binary concatenation of multiple bitcode files.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="MemorySSA.html" title="MemorySSA"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/BlockFrequencyTerminology.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/BlockFrequencyTerminology.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/BlockFrequencyTerminology.html (added)
+++ www-releases/trunk/7.0.1/docs/BlockFrequencyTerminology.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,213 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Block Frequency Terminology — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="LLVM Branch Weight Metadata" href="BranchWeightMetadata.html" />
+ <link rel="prev" title="LLVM Bitcode File Format" href="BitCodeFormat.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-block-frequency-terminology">
+<h1>LLVM Block Frequency Terminology<a class="headerlink" href="#llvm-block-frequency-terminology" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#branch-probability" id="id2">Branch Probability</a></li>
+<li><a class="reference internal" href="#branch-weight" id="id3">Branch Weight</a></li>
+<li><a class="reference internal" href="#block-frequency" id="id4">Block Frequency</a></li>
+<li><a class="reference internal" href="#implementation-a-series-of-dags" id="id5">Implementation: a series of DAGs</a></li>
+<li><a class="reference internal" href="#block-mass" id="id6">Block Mass</a></li>
+<li><a class="reference internal" href="#loop-scale" id="id7">Loop Scale</a></li>
+<li><a class="reference internal" href="#implementation-getting-from-mass-and-scale-to-frequency" id="id8">Implementation: Getting from mass and scale to frequency</a></li>
+<li><a class="reference internal" href="#block-bias" id="id9">Block Bias</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Block Frequency is a metric for estimating the relative frequency of different
+basic blocks. This document describes the terminology that the
+<tt class="docutils literal"><span class="pre">BlockFrequencyInfo</span></tt> and <tt class="docutils literal"><span class="pre">MachineBlockFrequencyInfo</span></tt> analysis passes use.</p>
+</div>
+<div class="section" id="branch-probability">
+<h2><a class="toc-backref" href="#id2">Branch Probability</a><a class="headerlink" href="#branch-probability" title="Permalink to this headline">¶</a></h2>
+<p>Blocks with multiple successors have probabilities associated with each
+outgoing edge. These are called branch probabilities. For a given block, the
+sum of its outgoing branch probabilities should be 1.0.</p>
+</div>
+<div class="section" id="branch-weight">
+<h2><a class="toc-backref" href="#id3">Branch Weight</a><a class="headerlink" href="#branch-weight" title="Permalink to this headline">¶</a></h2>
+<p>Rather than storing fractions on each edge, we store an integer weight.
+Weights are relative to the other edges of a given predecessor block. The
+branch probability associated with a given edge is its own weight divided by
+the sum of the weights on the predecessor’s outgoing edges.</p>
+<p>For example, consider this IR:</p>
+<div class="highlight-llvm"><pre>define void @foo() {
+ ; ...
+ A:
+ br i1 %cond, label %B, label %C, !prof !0
+ ; ...
+}
+!0 = metadata !{metadata !"branch_weights", i32 7, i32 8}</pre>
+</div>
+<p>and this simple graph representation:</p>
+<div class="highlight-python"><pre>A -> B (edge-weight: 7)
+A -> C (edge-weight: 8)</pre>
+</div>
+<p>The probability of branching from block A to block B is 7/15, and the
+probability of branching from block A to block C is 8/15.</p>
+<p>See <a class="reference internal" href="BranchWeightMetadata.html"><em>LLVM Branch Weight Metadata</em></a> for details about the branch weight IR
+representation.</p>
+</div>
+<div class="section" id="block-frequency">
+<h2><a class="toc-backref" href="#id4">Block Frequency</a><a class="headerlink" href="#block-frequency" title="Permalink to this headline">¶</a></h2>
+<p>Block frequency is a relative metric that represents the number of times a
+block executes. The ratio of a block frequency to the entry block frequency is
+the expected number of times the block will execute per entry to the function.</p>
+<p>Block frequency is the main output of the <tt class="docutils literal"><span class="pre">BlockFrequencyInfo</span></tt> and
+<tt class="docutils literal"><span class="pre">MachineBlockFrequencyInfo</span></tt> analysis passes.</p>
+</div>
+<div class="section" id="implementation-a-series-of-dags">
+<h2><a class="toc-backref" href="#id5">Implementation: a series of DAGs</a><a class="headerlink" href="#implementation-a-series-of-dags" title="Permalink to this headline">¶</a></h2>
+<p>The implementation of the block frequency calculation analyses each loop,
+bottom-up, ignoring backedges; i.e., as a DAG. After each loop is processed,
+it’s packaged up to act as a pseudo-node in its parent loop’s (or the
+function’s) DAG analysis.</p>
+</div>
+<div class="section" id="block-mass">
+<h2><a class="toc-backref" href="#id6">Block Mass</a><a class="headerlink" href="#block-mass" title="Permalink to this headline">¶</a></h2>
+<p>For each DAG, the entry node is assigned a mass of <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt> and mass is
+distributed to successors according to branch weights. Block Mass uses a
+fixed-point representation where <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt> represents <tt class="docutils literal"><span class="pre">1.0</span></tt> and <tt class="docutils literal"><span class="pre">0</span></tt>
+represents a number just above <tt class="docutils literal"><span class="pre">0.0</span></tt>.</p>
+<p>After mass is fully distributed, in any cut of the DAG that separates the exit
+nodes from the entry node, the sum of the block masses of the nodes succeeded
+by a cut edge should equal <tt class="docutils literal"><span class="pre">UINT64_MAX</span></tt>. In other words, mass is conserved
+as it “falls” through the DAG.</p>
+<p>If a function’s basic block graph is a DAG, then block masses are valid block
+frequencies. This works poorly in practise though, since downstream users rely
+on adding block frequencies together without hitting the maximum.</p>
+</div>
+<div class="section" id="loop-scale">
+<h2><a class="toc-backref" href="#id7">Loop Scale</a><a class="headerlink" href="#loop-scale" title="Permalink to this headline">¶</a></h2>
+<p>Loop scale is a metric that indicates how many times a loop iterates per entry.
+As mass is distributed through the loop’s DAG, the (otherwise ignored) backedge
+mass is collected. This backedge mass is used to compute the exit frequency,
+and thus the loop scale.</p>
+</div>
+<div class="section" id="implementation-getting-from-mass-and-scale-to-frequency">
+<h2><a class="toc-backref" href="#id8">Implementation: Getting from mass and scale to frequency</a><a class="headerlink" href="#implementation-getting-from-mass-and-scale-to-frequency" title="Permalink to this headline">¶</a></h2>
+<p>After analysing the complete series of DAGs, each block has a mass (local to
+its containing loop, if any), and each loop pseudo-node has a loop scale and
+its own mass (from its parent’s DAG).</p>
+<p>We can get an initial frequency assignment (with entry frequency of 1.0) by
+multiplying these masses and loop scales together. A given block’s frequency
+is the product of its mass, the mass of containing loops’ pseudo nodes, and the
+containing loops’ loop scales.</p>
+<p>Since downstream users need integers (not floating point), this initial
+frequency assignment is shifted as necessary into the range of <tt class="docutils literal"><span class="pre">uint64_t</span></tt>.</p>
+</div>
+<div class="section" id="block-bias">
+<h2><a class="toc-backref" href="#id9">Block Bias</a><a class="headerlink" href="#block-bias" title="Permalink to this headline">¶</a></h2>
+<p>Block bias is a proposed <em>absolute</em> metric to indicate a bias toward or away
+from a given block during a function’s execution. The idea is that bias can be
+used in isolation to indicate whether a block is relatively hot or cold, or to
+compare two blocks to indicate whether one is hotter or colder than the other.</p>
+<p>The proposed calculation involves calculating a <em>reference</em> block frequency,
+where:</p>
+<ul class="simple">
+<li>every branch weight is assumed to be 1 (i.e., every branch probability
+distribution is even) and</li>
+<li>loop scales are ignored.</li>
+</ul>
+<p>This reference frequency represents what the block frequency would be in an
+unbiased graph.</p>
+<p>The bias is the ratio of the block frequency to this reference block frequency.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="BitCodeFormat.html" title="LLVM Bitcode File Format"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/BranchWeightMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/BranchWeightMetadata.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/BranchWeightMetadata.html (added)
+++ www-releases/trunk/7.0.1/docs/BranchWeightMetadata.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,251 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Branch Weight Metadata — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="LLVM bugpoint tool: design and usage" href="Bugpoint.html" />
+ <link rel="prev" title="LLVM Block Frequency Terminology" href="BlockFrequencyTerminology.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-branch-weight-metadata">
+<h1>LLVM Branch Weight Metadata<a class="headerlink" href="#llvm-branch-weight-metadata" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#supported-instructions" id="id2">Supported Instructions</a><ul>
+<li><a class="reference internal" href="#branchinst" id="id3"><tt class="docutils literal"><span class="pre">BranchInst</span></tt></a></li>
+<li><a class="reference internal" href="#switchinst" id="id4"><tt class="docutils literal"><span class="pre">SwitchInst</span></tt></a></li>
+<li><a class="reference internal" href="#indirectbrinst" id="id5"><tt class="docutils literal"><span class="pre">IndirectBrInst</span></tt></a></li>
+<li><a class="reference internal" href="#callinst" id="id6"><tt class="docutils literal"><span class="pre">CallInst</span></tt></a></li>
+<li><a class="reference internal" href="#other" id="id7">Other</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#built-in-expect-instructions" id="id8">Built-in <tt class="docutils literal"><span class="pre">expect</span></tt> Instructions</a><ul>
+<li><a class="reference internal" href="#if-statement" id="id9"><tt class="docutils literal"><span class="pre">if</span></tt> statement</a></li>
+<li><a class="reference internal" href="#switch-statement" id="id10"><tt class="docutils literal"><span class="pre">switch</span></tt> statement</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#cfg-modifications" id="id11">CFG Modifications</a></li>
+<li><a class="reference internal" href="#function-entry-counts" id="id12">Function Entry Counts</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>Branch Weight Metadata represents branch weights as its likeliness to be taken
+(see <a class="reference internal" href="BlockFrequencyTerminology.html"><em>LLVM Block Frequency Terminology</em></a>). Metadata is assigned to the
+<tt class="docutils literal"><span class="pre">TerminatorInst</span></tt> as a <tt class="docutils literal"><span class="pre">MDNode</span></tt> of the <tt class="docutils literal"><span class="pre">MD_prof</span></tt> kind. The first operator
+is always a <tt class="docutils literal"><span class="pre">MDString</span></tt> node with the string “branch_weights”. Number of
+operators depends on the terminator type.</p>
+<p>Branch weights might be fetch from the profiling file, or generated based on
+<a class="reference internal" href="#builtin-expect">__builtin_expect</a> instruction.</p>
+<p>All weights are represented as an unsigned 32-bit values, where higher value
+indicates greater chance to be taken.</p>
+</div>
+<div class="section" id="supported-instructions">
+<h2><a class="toc-backref" href="#id2">Supported Instructions</a><a class="headerlink" href="#supported-instructions" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="branchinst">
+<h3><a class="toc-backref" href="#id3"><tt class="docutils literal"><span class="pre">BranchInst</span></tt></a><a class="headerlink" href="#branchinst" title="Permalink to this headline">¶</a></h3>
+<p>Metadata is only assigned to the conditional branches. There are two extra
+operands for the true and the false branch.</p>
+<div class="highlight-none"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <TRUE_BRANCH_WEIGHT>,
+ i32 <FALSE_BRANCH_WEIGHT>
+}
+</pre></div>
+</div>
+</div>
+<div class="section" id="switchinst">
+<h3><a class="toc-backref" href="#id4"><tt class="docutils literal"><span class="pre">SwitchInst</span></tt></a><a class="headerlink" href="#switchinst" title="Permalink to this headline">¶</a></h3>
+<p>Branch weights are assigned to every case (including the <tt class="docutils literal"><span class="pre">default</span></tt> case which
+is always case #0).</p>
+<div class="highlight-none"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <DEFAULT_BRANCH_WEIGHT>
+ [ , i32 <CASE_BRANCH_WEIGHT> ... ]
+}
+</pre></div>
+</div>
+</div>
+<div class="section" id="indirectbrinst">
+<h3><a class="toc-backref" href="#id5"><tt class="docutils literal"><span class="pre">IndirectBrInst</span></tt></a><a class="headerlink" href="#indirectbrinst" title="Permalink to this headline">¶</a></h3>
+<p>Branch weights are assigned to every destination.</p>
+<div class="highlight-none"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <LABEL_BRANCH_WEIGHT>
+ [ , i32 <LABEL_BRANCH_WEIGHT> ... ]
+}
+</pre></div>
+</div>
+</div>
+<div class="section" id="callinst">
+<h3><a class="toc-backref" href="#id6"><tt class="docutils literal"><span class="pre">CallInst</span></tt></a><a class="headerlink" href="#callinst" title="Permalink to this headline">¶</a></h3>
+<p>Calls may have branch weight metadata, containing the execution count of
+the call. It is currently used in SamplePGO mode only, to augment the
+block and entry counts which may not be accurate with sampling.</p>
+<div class="highlight-none"><div class="highlight"><pre>!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <CALL_BRANCH_WEIGHT>
+}
+</pre></div>
+</div>
+</div>
+<div class="section" id="other">
+<h3><a class="toc-backref" href="#id7">Other</a><a class="headerlink" href="#other" title="Permalink to this headline">¶</a></h3>
+<p>Other terminator instructions are not allowed to contain Branch Weight Metadata.</p>
+</div>
+</div>
+<div class="section" id="built-in-expect-instructions">
+<span id="builtin-expect"></span><h2><a class="toc-backref" href="#id8">Built-in <tt class="docutils literal"><span class="pre">expect</span></tt> Instructions</a><a class="headerlink" href="#built-in-expect-instructions" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">__builtin_expect(long</span> <span class="pre">exp,</span> <span class="pre">long</span> <span class="pre">c)</span></tt> instruction provides branch prediction
+information. The return value is the value of <tt class="docutils literal"><span class="pre">exp</span></tt>.</p>
+<p>It is especially useful in conditional statements. Currently Clang supports two
+conditional statements:</p>
+<div class="section" id="if-statement">
+<h3><a class="toc-backref" href="#id9"><tt class="docutils literal"><span class="pre">if</span></tt> statement</a><a class="headerlink" href="#if-statement" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">exp</span></tt> parameter is the condition. The <tt class="docutils literal"><span class="pre">c</span></tt> parameter is the expected
+comparison value. If it is equal to 1 (true), the condition is likely to be
+true, in other case condition is likely to be false. For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">__builtin_expect</span><span class="p">(</span><span class="n">x</span> <span class="o">></span> <span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">))</span> <span class="p">{</span>
+ <span class="c1">// This block is likely to be taken.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="switch-statement">
+<h3><a class="toc-backref" href="#id10"><tt class="docutils literal"><span class="pre">switch</span></tt> statement</a><a class="headerlink" href="#switch-statement" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">exp</span></tt> parameter is the value. The <tt class="docutils literal"><span class="pre">c</span></tt> parameter is the expected
+value. If the expected value doesn’t show on the cases list, the <tt class="docutils literal"><span class="pre">default</span></tt>
+case is assumed to be likely taken.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">switch</span> <span class="p">(</span><span class="n">__builtin_expect</span><span class="p">(</span><span class="n">x</span><span class="p">,</span> <span class="mi">5</span><span class="p">))</span> <span class="p">{</span>
+<span class="k">default</span><span class="o">:</span> <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="mi">0</span><span class="o">:</span> <span class="c1">// ...</span>
+<span class="k">case</span> <span class="mi">3</span><span class="o">:</span> <span class="c1">// ...</span>
+<span class="k">case</span> <span class="mi">5</span><span class="o">:</span> <span class="c1">// This case is likely to be taken.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="cfg-modifications">
+<h2><a class="toc-backref" href="#id11">CFG Modifications</a><a class="headerlink" href="#cfg-modifications" title="Permalink to this headline">¶</a></h2>
+<p>Branch Weight Metatada is not proof against CFG changes. If terminator operands’
+are changed some action should be taken. In other case some misoptimizations may
+occur due to incorrect branch prediction information.</p>
+</div>
+<div class="section" id="function-entry-counts">
+<h2><a class="toc-backref" href="#id12">Function Entry Counts</a><a class="headerlink" href="#function-entry-counts" title="Permalink to this headline">¶</a></h2>
+<p>To allow comparing different functions during inter-procedural analysis and
+optimization, <tt class="docutils literal"><span class="pre">MD_prof</span></tt> nodes can also be assigned to a function definition.
+The first operand is a string indicating the name of the associated counter.</p>
+<p>Currently, one counter is supported: “function_entry_count”. The second operand
+is a 64-bit counter that indicates the number of times that this function was
+invoked (in the case of instrumentation-based profiles). In the case of
+sampling-based profiles, this operand is an approximation of how many times
+the function was invoked.</p>
+<p>For example, in the code below, the instrumentation for function foo()
+indicates that it was called 2,590 times at runtime.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i32</span> <span class="vg">@foo</span><span class="p">()</span> <span class="nv">!prof</span> <span class="nv-Anonymous">!1</span> <span class="p">{</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="m">0</span>
+<span class="p">}</span>
+<span class="nv-Anonymous">!1</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"function_entry_count"</span><span class="p">,</span> <span class="k">i64</span> <span class="m">2590</span><span class="p">}</span>
+</pre></div>
+</div>
+<p>If “function_entry_count” has more than 2 operands, the later operands are
+the GUID of the functions that needs to be imported by ThinLTO. This is only
+set by sampling based profile. It is needed because the sampling based profile
+was collected on a binary that had already imported and inlined these functions,
+and we need to ensure the IR matches in the ThinLTO backends for profile
+annotation. The reason why we cannot annotate this on the callsite is that it
+can only goes down 1 level in the call chain. For the cases where
+foo_in_a_cc()->bar_in_b_cc()->baz_in_c_cc(), we will need to go down 2 levels
+in the call chain to import both bar_in_b_cc and baz_in_c_cc.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="BlockFrequencyTerminology.html" title="LLVM Block Frequency Terminology"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/Bugpoint.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/Bugpoint.html (added)
+++ www-releases/trunk/7.0.1/docs/Bugpoint.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,300 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM bugpoint tool: design and usage — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="The LLVM Target-Independent Code Generator" href="CodeGenerator.html" />
+ <link rel="prev" title="LLVM Branch Weight Metadata" href="BranchWeightMetadata.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="CodeGenerator.html" title="The LLVM Target-Independent Code Generator"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-bugpoint-tool-design-and-usage">
+<h1>LLVM bugpoint tool: design and usage<a class="headerlink" href="#llvm-bugpoint-tool-design-and-usage" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#description" id="id4">Description</a></li>
+<li><a class="reference internal" href="#design-philosophy" id="id5">Design Philosophy</a><ul>
+<li><a class="reference internal" href="#automatic-debugger-selection" id="id6">Automatic Debugger Selection</a></li>
+<li><a class="reference internal" href="#crash-debugger" id="id7">Crash debugger</a></li>
+<li><a class="reference internal" href="#code-generator-debugger" id="id8">Code generator debugger</a></li>
+<li><a class="reference internal" href="#miscompilation-debugger" id="id9">Miscompilation debugger</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#advice-for-using-bugpoint" id="id10">Advice for using bugpoint</a></li>
+<li><a class="reference internal" href="#what-to-do-when-bugpoint-isn-t-enough" id="id11">What to do when bugpoint isn’t enough</a></li>
+</ul>
+</div>
+<div class="section" id="description">
+<h2><a class="toc-backref" href="#id4">Description</a><a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> narrows down the source of problems in LLVM tools and passes. It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers). It aims to reduce large test cases to small, useful ones.
+For example, if <tt class="docutils literal"><span class="pre">opt</span></tt> crashes while optimizing a file, it will identify the
+optimization (or combination of optimizations) that causes the crash, and reduce
+the file down to a small example which triggers the crash.</p>
+<p>For detailed case scenarios, such as debugging <tt class="docutils literal"><span class="pre">opt</span></tt>, or one of the LLVM code
+generators, see <a class="reference internal" href="HowToSubmitABug.html"><em>How to submit an LLVM bug report</em></a>.</p>
+</div>
+<div class="section" id="design-philosophy">
+<h2><a class="toc-backref" href="#id5">Design Philosophy</a><a class="headerlink" href="#design-philosophy" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></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 passes and code
+generators, and does not need to “know” how they work. Because of this, it may
+appear to do stupid things or miss obvious simplifications. <tt class="docutils literal"><span class="pre">bugpoint</span></tt> is
+also designed to trade off programmer time for computer time in the
+compiler-debugging process; consequently, it may take a long period of
+(unattended) time to reduce a test case, but we feel it is still worth it. Note
+that <tt class="docutils literal"><span class="pre">bugpoint</span></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 class="section" id="automatic-debugger-selection">
+<h3><a class="toc-backref" href="#id6">Automatic Debugger Selection</a><a class="headerlink" href="#automatic-debugger-selection" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> reads each <tt class="docutils literal"><span class="pre">.bc</span></tt> or <tt class="docutils literal"><span class="pre">.ll</span></tt> file specified on the command line
+and links them together into a single module, called the test program. If any
+LLVM passes are specified on the command line, it runs these passes on the test
+program. If any of the passes crash, or if they produce malformed output (which
+causes the verifier to abort), <tt class="docutils literal"><span class="pre">bugpoint</span></tt> starts the <a class="reference internal" href="#crash-debugger">crash debugger</a>.</p>
+<p>Otherwise, if the <tt class="docutils literal"><span class="pre">-output</span></tt> option was not specified, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> runs the
+test program with the “safe” backend (which is assumed to generate good code) to
+generate a reference output. Once <tt class="docutils literal"><span class="pre">bugpoint</span></tt> has a reference output for the
+test program, it tries executing it with the selected code generator. If the
+selected code generator crashes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> starts the <a class="reference internal" href="#crash-debugger">crash debugger</a> on
+the code generator. Otherwise, if the resulting output differs from the
+reference output, it assumes the difference resulted from a code generator
+failure, and starts the <a class="reference internal" href="#code-generator-debugger">code generator debugger</a>.</p>
+<p>Finally, if the output of the selected code generator matches the reference
+output, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> runs the test program after all of the LLVM passes have
+been applied to it. If its output differs from the reference output, it assumes
+the difference resulted from a failure in one of the LLVM passes, and enters the
+<a class="reference internal" href="#miscompilation-debugger">miscompilation debugger</a>. Otherwise, there is no problem <tt class="docutils literal"><span class="pre">bugpoint</span></tt> can
+debug.</p>
+</div>
+<div class="section" id="crash-debugger">
+<span id="id1"></span><h3><a class="toc-backref" href="#id7">Crash debugger</a><a class="headerlink" href="#crash-debugger" title="Permalink to this headline">¶</a></h3>
+<p>If an optimizer or code generator crashes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> will try as hard as it
+can to reduce the list of passes (for optimizer crashes) and the size of the
+test program. First, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> figures out which combination of optimizer
+passes triggers the bug. This is useful when debugging a problem exposed by
+<tt class="docutils literal"><span class="pre">opt</span></tt>, for example, because it runs over 38 passes.</p>
+<p>Next, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> tries removing functions from the test program, to reduce its
+size. Usually it is able to reduce a test program to a single function, when
+debugging intraprocedural optimizations. Once the number of functions has been
+reduced, it attempts to delete various edges in the control flow graph, to
+reduce the size of the function as much as possible. Finally, <tt class="docutils literal"><span class="pre">bugpoint</span></tt>
+deletes any individual LLVM instructions whose absence does not eliminate the
+failure. At the end, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> should tell you what passes crash, give you a
+bitcode file, and give you instructions on how to reproduce the failure with
+<tt class="docutils literal"><span class="pre">opt</span></tt> or <tt class="docutils literal"><span class="pre">llc</span></tt>.</p>
+</div>
+<div class="section" id="code-generator-debugger">
+<span id="id2"></span><h3><a class="toc-backref" href="#id8">Code generator debugger</a><a class="headerlink" href="#code-generator-debugger" title="Permalink to this headline">¶</a></h3>
+<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 test
+program and partitions it into two pieces: one piece which it compiles with the
+“safe” backend (into a shared object), and one piece which it runs with either
+the JIT or the static LLC compiler. It uses several techniques to reduce the
+amount of code pushed through the LLVM code generator, to reduce the potential
+scope of the problem. After it is finished, it emits two bitcode files (called
+“test” [to be compiled with the code generator] and “safe” [to be compiled with
+the “safe” backend], respectively), and instructions for reproducing the
+problem. The code generator debugger assumes that the “safe” backend produces
+good code.</p>
+</div>
+<div class="section" id="miscompilation-debugger">
+<span id="id3"></span><h3><a class="toc-backref" href="#id9">Miscompilation debugger</a><a class="headerlink" href="#miscompilation-debugger" title="Permalink to this headline">¶</a></h3>
+<p>The miscompilation debugger works similarly to the code generator debugger. It
+works by splitting the test program into two pieces, running the optimizations
+specified on one piece, linking the two pieces back together, and then executing
+the result. It attempts to narrow down the list of passes to the one (or few)
+which are causing the miscompilation, then reduce the portion of the test
+program which is being miscompiled. The miscompilation debugger assumes that
+the selected code generator is working properly.</p>
+</div>
+</div>
+<div class="section" id="advice-for-using-bugpoint">
+<h2><a class="toc-backref" href="#id10">Advice for using bugpoint</a><a class="headerlink" href="#advice-for-using-bugpoint" title="Permalink to this headline">¶</a></h2>
+<p><tt class="docutils literal"><span class="pre">bugpoint</span></tt> can be a remarkably useful tool, but it sometimes works in
+non-obvious ways. Here are some hints and tips:</p>
+<ul>
+<li><p class="first">In the code generator and miscompilation debuggers, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> only works
+with programs that have deterministic output. Thus, if the program outputs
+<tt class="docutils literal"><span class="pre">argv[0]</span></tt>, the date, time, or any other “random” data, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> may
+misinterpret differences in these data, when output, as the result of a
+miscompilation. Programs should be temporarily modified to disable outputs
+that are likely to vary from run to run.</p>
+</li>
+<li><p class="first">In the code generator and miscompilation debuggers, debugging will go faster
+if you manually modify the program or its inputs to reduce the runtime, but
+still exhibit the problem.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> is extremely useful when working on a new optimization: it helps
+track down regressions quickly. To avoid having to relink <tt class="docutils literal"><span class="pre">bugpoint</span></tt> every
+time you change your optimization however, have <tt class="docutils literal"><span class="pre">bugpoint</span></tt> dynamically load
+your optimization with the <tt class="docutils literal"><span class="pre">-load</span></tt> option.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> can generate a lot of output and run for a long period of time.
+It is often useful to capture the output of the program to file. For example,
+in the C shell, you can run:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> bugpoint ... |& tee bugpoint.log
+</pre></div>
+</div>
+<p>to get a copy of <tt class="docutils literal"><span class="pre">bugpoint</span></tt>‘s output in the file <tt class="docutils literal"><span class="pre">bugpoint.log</span></tt>, as well
+as on your terminal.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> cannot debug problems with the LLVM linker. If <tt class="docutils literal"><span class="pre">bugpoint</span></tt>
+crashes before you see its “All input ok” message, you might try <tt class="docutils literal"><span class="pre">llvm-link</span>
+<span class="pre">-v</span></tt> on the same set of input files. If that also crashes, you may be
+experiencing a linker bug.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> is useful for proactively finding bugs in LLVM. Invoking
+<tt class="docutils literal"><span class="pre">bugpoint</span></tt> with the <tt class="docutils literal"><span class="pre">-find-bugs</span></tt> option will cause the list of specified
+optimizations to be randomized and applied to the program. This process will
+repeat until a bug is found or the user kills <tt class="docutils literal"><span class="pre">bugpoint</span></tt>.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">bugpoint</span></tt> can produce IR which contains long names. Run <tt class="docutils literal"><span class="pre">opt</span>
+<span class="pre">-metarenamer</span></tt> over the IR to rename everything using easy-to-read,
+metasyntactic names. Alternatively, run <tt class="docutils literal"><span class="pre">opt</span> <span class="pre">-strip</span> <span class="pre">-instnamer</span></tt> to rename
+everything with very short (often purely numeric) names.</p>
+</li>
+</ul>
+</div>
+<div class="section" id="what-to-do-when-bugpoint-isn-t-enough">
+<h2><a class="toc-backref" href="#id11">What to do when bugpoint isn’t enough</a><a class="headerlink" href="#what-to-do-when-bugpoint-isn-t-enough" title="Permalink to this headline">¶</a></h2>
+<p>Sometimes, <tt class="docutils literal"><span class="pre">bugpoint</span></tt> is not enough. In particular, InstCombine and
+TargetLowering both have visitor structured code with lots of potential
+transformations. If the process of using bugpoint has left you with still too
+much code to figure out and the problem seems to be in instcombine, the
+following steps may help. These same techniques are useful with TargetLowering
+as well.</p>
+<p>Turn on <tt class="docutils literal"><span class="pre">-debug-only=instcombine</span></tt> and see which transformations within
+instcombine are firing by selecting out lines with “<tt class="docutils literal"><span class="pre">IC</span></tt>” in them.</p>
+<p>At this point, you have a decision to make. Is the number of transformations
+small enough to step through them using a debugger? If so, then try that.</p>
+<p>If there are too many transformations, then a source modification approach may
+be helpful. In this approach, you can modify the source code of instcombine to
+disable just those transformations that are being performed on your test input
+and perform a binary search over the set of transformations. One set of places
+to modify are the “<tt class="docutils literal"><span class="pre">visit*</span></tt>” methods of <tt class="docutils literal"><span class="pre">InstCombiner</span></tt> (<em>e.g.</em>
+<tt class="docutils literal"><span class="pre">visitICmpInst</span></tt>) by adding a “<tt class="docutils literal"><span class="pre">return</span> <span class="pre">false</span></tt>” as the first line of the
+method.</p>
+<p>If that still doesn’t remove enough, then change the caller of
+<tt class="docutils literal"><span class="pre">InstCombiner::DoOneIteration</span></tt>, <tt class="docutils literal"><span class="pre">InstCombiner::runOnFunction</span></tt> to limit the
+number of iterations.</p>
+<p>You may also find it useful to use “<tt class="docutils literal"><span class="pre">-stats</span></tt>” now to see what parts of
+instcombine are firing. This can guide where to put additional reporting code.</p>
+<p>At this point, if the amount of transformations is still too large, then
+inserting code to limit whether or not to execute the body of the code in the
+visit function can be helpful. Add a static counter which is incremented on
+every invocation of the function. Then add code which simply returns false on
+desired ranges. For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">static</span> <span class="kt">int</span> <span class="n">calledCount</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="n">calledCount</span><span class="o">++</span><span class="p">;</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o"><</span> <span class="mi">212</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">></span> <span class="mi">217</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">213</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">214</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">215</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="k">if</span> <span class="p">(</span><span class="n">calledCount</span> <span class="o">==</span> <span class="mi">216</span><span class="p">)</span> <span class="k">return</span> <span class="kc">false</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="n">dbgs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"visitXOR calledCount: "</span> <span class="o"><<</span> <span class="n">calledCount</span> <span class="o"><<</span> <span class="s">"</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
+<span class="n">LLVM_DEBUG</span><span class="p">(</span><span class="n">dbgs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"I: "</span><span class="p">;</span> <span class="n">I</span><span class="o">-></span><span class="n">dump</span><span class="p">());</span>
+</pre></div>
+</div>
+<p>could be added to <tt class="docutils literal"><span class="pre">visitXOR</span></tt> to limit <tt class="docutils literal"><span class="pre">visitXor</span></tt> to being applied only to
+calls 212 and 217. This is from an actual test case and raises an important
+point—a simple binary search may not be sufficient, as transformations that
+interact may require isolating more than one call. In TargetLowering, use
+<tt class="docutils literal"><span class="pre">return</span> <span class="pre">SDNode();</span></tt> instead of <tt class="docutils literal"><span class="pre">return</span> <span class="pre">false;</span></tt>.</p>
+<p>Now that the number of transformations is down to a manageable number, try
+examining the output to see if you can figure out which transformations are
+being done. If that can be figured out, then do the usual debugging. If which
+code corresponds to the transformation being performed isn’t obvious, set a
+breakpoint after the call count based disabling and step through the code.
+Alternatively, you can use “<tt class="docutils literal"><span class="pre">printf</span></tt>” style debugging to report waypoints.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="CodeGenerator.html" title="The LLVM Target-Independent Code Generator"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="BranchWeightMetadata.html" title="LLVM Branch Weight Metadata"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CFIVerify.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CFIVerify.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CFIVerify.html (added)
+++ www-releases/trunk/7.0.1/docs/CFIVerify.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,186 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Control Flow Verification Tool Design Document — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="Contributing to LLVM" href="Contributing.html" />
+ <link rel="prev" title="CodeView Type Records" href="PDB/CodeViewTypes.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Contributing.html" title="Contributing to LLVM"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="PDB/CodeViewTypes.html" title="CodeView Type Records"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="control-flow-verification-tool-design-document">
+<h1>Control Flow Verification Tool Design Document<a class="headerlink" href="#control-flow-verification-tool-design-document" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#objective" id="id1">Objective</a></li>
+<li><a class="reference internal" href="#location" id="id2">Location</a></li>
+<li><a class="reference internal" href="#background" id="id3">Background</a></li>
+<li><a class="reference internal" href="#design-ideas" id="id4">Design Ideas</a><ul>
+<li><a class="reference internal" href="#other-design-notes" id="id5">Other Design Notes</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="objective">
+<h2><a class="toc-backref" href="#id1">Objective</a><a class="headerlink" href="#objective" title="Permalink to this headline">¶</a></h2>
+<p>This document provides an overview of an external tool to verify the protection
+mechanisms implemented by Clang’s <em>Control Flow Integrity</em> (CFI) schemes
+(<tt class="docutils literal"><span class="pre">-fsanitize=cfi</span></tt>). This tool, provided a binary or DSO, should infer whether
+indirect control flow operations are protected by CFI, and should output these
+results in a human-readable form.</p>
+<p>This tool should also be added as part of Clang’s continuous integration testing
+framework, where modifications to the compiler ensure that CFI protection
+schemes are still present in the final binary.</p>
+</div>
+<div class="section" id="location">
+<h2><a class="toc-backref" href="#id2">Location</a><a class="headerlink" href="#location" title="Permalink to this headline">¶</a></h2>
+<p>This tool will be present as a part of the LLVM toolchain, and will reside in
+the “/llvm/tools/llvm-cfi-verify” directory, relative to the LLVM trunk. It will
+be tested in two methods:</p>
+<ul class="simple">
+<li>Unit tests to validate code sections, present in
+“/llvm/unittests/tools/llvm-cfi-verify”.</li>
+<li>Integration tests, present in “/llvm/tools/clang/test/LLVMCFIVerify”. These
+integration tests are part of clang as part of a continuous integration
+framework, ensuring updates to the compiler that reduce CFI coverage on
+indirect control flow instructions are identified.</li>
+</ul>
+</div>
+<div class="section" id="background">
+<h2><a class="toc-backref" href="#id3">Background</a><a class="headerlink" href="#background" title="Permalink to this headline">¶</a></h2>
+<p>This tool will continuously validate that CFI directives are properly
+implemented around all indirect control flows by analysing the output machine
+code. The analysis of machine code is important as it ensures that any bugs
+present in linker or compiler do not subvert CFI protections in the final
+shipped binary.</p>
+<p>Unprotected indirect control flow instructions will be flagged for manual
+review. These unexpected control flows may simply have not been accounted for in
+the compiler implementation of CFI (e.g. indirect jumps to facilitate switch
+statements may not be fully protected).</p>
+<p>It may be possible in the future to extend this tool to flag unnecessary CFI
+directives (e.g. CFI directives around a static call to a non-polymorphic base
+type). This type of directive has no security implications, but may present
+performance impacts.</p>
+</div>
+<div class="section" id="design-ideas">
+<h2><a class="toc-backref" href="#id4">Design Ideas</a><a class="headerlink" href="#design-ideas" title="Permalink to this headline">¶</a></h2>
+<p>This tool will disassemble binaries and DSO’s from their machine code format and
+analyse the disassembled machine code. The tool will inspect virtual calls and
+indirect function calls. This tool will also inspect indirect jumps, as inlined
+functions and jump tables should also be subject to CFI protections. Non-virtual
+calls (<tt class="docutils literal"><span class="pre">-fsanitize=cfi-nvcall</span></tt>) and cast checks (<tt class="docutils literal"><span class="pre">-fsanitize=cfi-*cast*</span></tt>)
+are not implemented due to a lack of information provided by the bytecode.</p>
+<p>The tool would operate by searching for indirect control flow instructions in
+the disassembly. A control flow graph would be generated from a small buffer of
+the instructions surrounding the ‘target’ control flow instruction. If the
+target instruction is branched-to, the fallthrough of the branch should be the
+CFI trap (on x86, this is a <tt class="docutils literal"><span class="pre">ud2</span></tt> instruction). If the target instruction is
+the fallthrough (i.e. immediately succeeds) of a conditional jump, the
+conditional jump target should be the CFI trap. If an indirect control flow
+instruction does not conform to one of these formats, the target will be noted
+as being CFI-unprotected.</p>
+<p>Note that in the second case outlined above (where the target instruction is the
+fallthrough of a conditional jump), if the target represents a vcall that takes
+arguments, these arguments may be pushed to the stack after the branch but
+before the target instruction. In these cases, a secondary ‘spill graph’ in
+constructed, to ensure the register argument used by the indirect jump/call is
+not spilled from the stack at any point in the interim period. If there are no
+spills that affect the target register, the target is marked as CFI-protected.</p>
+<div class="section" id="other-design-notes">
+<h3><a class="toc-backref" href="#id5">Other Design Notes</a><a class="headerlink" href="#other-design-notes" title="Permalink to this headline">¶</a></h3>
+<p>Only machine code sections that are marked as executable will be subject to this
+analysis. Non-executable sections do not require analysis as any execution
+present in these sections has already violated the control flow integrity.</p>
+<p>Suitable extensions may be made at a later date to include analysis for indirect
+control flow operations across DSO boundaries. Currently, these CFI features are
+only experimental with an unstable ABI, making them unsuitable for analysis.</p>
+<p>The tool currently only supports the x86, x86_64, and AArch64 architectures.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Contributing.html" title="Contributing to LLVM"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="PDB/CodeViewTypes.html" title="CodeView Type Records"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CMake.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CMake.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CMake.html (added)
+++ www-releases/trunk/7.0.1/docs/CMake.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,777 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Building LLVM with CMake — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="CMake Primer" href="CMakePrimer.html" />
+ <link rel="prev" title="LLVM Language Reference Manual" href="LangRef.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="CMakePrimer.html" title="CMake Primer"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="LangRef.html" title="LLVM Language Reference Manual"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="building-llvm-with-cmake">
+<h1>Building LLVM with CMake<a class="headerlink" href="#building-llvm-with-cmake" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id5">Introduction</a></li>
+<li><a class="reference internal" href="#quick-start" id="id6">Quick start</a></li>
+<li><a class="reference internal" href="#usage" id="id7">Basic CMake usage</a></li>
+<li><a class="reference internal" href="#options-and-variables" id="id8">Options and variables</a><ul>
+<li><a class="reference internal" href="#frequently-used-cmake-variables" id="id9">Frequently-used CMake variables</a></li>
+<li><a class="reference internal" href="#llvm-specific-variables" id="id10">LLVM-specific variables</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#cmake-caches" id="id11">CMake Caches</a></li>
+<li><a class="reference internal" href="#executing-the-test-suite" id="id12">Executing the test suite</a></li>
+<li><a class="reference internal" href="#cross-compiling" id="id13">Cross compiling</a></li>
+<li><a class="reference internal" href="#embedding-llvm-in-your-project" id="id14">Embedding LLVM in your project</a><ul>
+<li><a class="reference internal" href="#developing-llvm-passes-out-of-source" id="id15">Developing LLVM passes out of source</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#compiler-platform-specific-topics" id="id16">Compiler/Platform-specific topics</a><ul>
+<li><a class="reference internal" href="#microsoft-visual-c" id="id17">Microsoft Visual C++</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id5">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p><a class="reference external" href="http://www.cmake.org/">CMake</a> is a cross-platform build-generator tool. CMake
+does not build the project, it generates the files needed by your build tool
+(GNU make, Visual Studio, etc.) for building LLVM.</p>
+<p>If <strong>you are a new contributor</strong>, please start with the <a class="reference internal" href="GettingStarted.html"><em>Getting Started with the LLVM System</em></a>
+page. This page is geared for existing contributors moving from the
+legacy configure/make system.</p>
+<p>If you are really anxious about getting a functional LLVM build, go to the
+<a class="reference internal" href="#quick-start">Quick start</a> section. If you are a CMake novice, start with <a class="reference internal" href="#basic-cmake-usage">Basic CMake usage</a>
+and then go back to the <a class="reference internal" href="#quick-start">Quick start</a> section once you know what you are doing. The
+<a class="reference internal" href="#options-and-variables">Options and variables</a> section is a reference for customizing your build. If
+you already have experience with CMake, this is the recommended starting point.</p>
+<p>This page is geared towards users of the LLVM CMake build. If you’re looking for
+information about modifying the LLVM CMake build system you may want to see the
+<a class="reference internal" href="CMakePrimer.html"><em>CMake Primer</em></a> page. It has a basic overview of the CMake language.</p>
+</div>
+<div class="section" id="quick-start">
+<span id="id1"></span><h2><a class="toc-backref" href="#id6">Quick start</a><a class="headerlink" href="#quick-start" title="Permalink to this headline">¶</a></h2>
+<p>We use here the command-line, non-interactive CMake interface.</p>
+<ol class="arabic">
+<li><p class="first"><a class="reference external" href="http://www.cmake.org/cmake/resources/software.html">Download</a> and install
+CMake. Version 3.4.3 is the minimum required.</p>
+</li>
+<li><p class="first">Open a shell. Your development tools must be reachable from this shell
+through the PATH environment variable.</p>
+</li>
+<li><p class="first">Create a build directory. Building LLVM in the source
+directory is not supported. cd to this directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> mkdir mybuilddir
+<span class="gp">$</span> <span class="nb">cd </span>mybuilddir
+</pre></div>
+</div>
+</li>
+<li><p class="first">Execute this command in the shell replacing <cite>path/to/llvm/source/root</cite> with
+the path to the root of your LLVM source tree:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake path/to/llvm/source/root
+</pre></div>
+</div>
+<p>CMake will detect your development environment, perform a series of tests, and
+generate the files required for building LLVM. CMake will use default values
+for all build parameters. See the <a class="reference internal" href="#options-and-variables">Options and variables</a> section for
+a list of build parameters that you can modify.</p>
+<p>This can fail if CMake can’t detect your toolset, or if it thinks that the
+environment is not sane enough. In this case, make sure that the toolset that
+you intend to use is the only one reachable from the shell, and that the shell
+itself is the correct one for your development environment. CMake will refuse
+to build MinGW makefiles if you have a POSIX shell reachable through the PATH
+environment variable, for instance. You can force CMake to use a given build
+tool; for instructions, see the <a class="reference internal" href="#usage">Usage</a> section, below.</p>
+</li>
+<li><p class="first">After CMake has finished running, proceed to use IDE project files, or start
+the build from the build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --build .
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">--build</span></tt> option tells <tt class="docutils literal"><span class="pre">cmake</span></tt> to invoke the underlying build
+tool (<tt class="docutils literal"><span class="pre">make</span></tt>, <tt class="docutils literal"><span class="pre">ninja</span></tt>, <tt class="docutils literal"><span class="pre">xcodebuild</span></tt>, <tt class="docutils literal"><span class="pre">msbuild</span></tt>, etc.)</p>
+<p>The underlying build tool can be invoked directly, of course, but
+the <tt class="docutils literal"><span class="pre">--build</span></tt> option is portable.</p>
+</li>
+<li><p class="first">After LLVM has finished building, install it from the build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --build . --target install
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">--target</span></tt> option with <tt class="docutils literal"><span class="pre">install</span></tt> parameter in addition to
+the <tt class="docutils literal"><span class="pre">--build</span></tt> option tells <tt class="docutils literal"><span class="pre">cmake</span></tt> to build the <tt class="docutils literal"><span class="pre">install</span></tt> target.</p>
+<p>It is possible to set a different install prefix at installation time
+by invoking the <tt class="docutils literal"><span class="pre">cmake_install.cmake</span></tt> script generated in the
+build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DCMAKE_INSTALL_PREFIX<span class="o">=</span>/tmp/llvm -P cmake_install.cmake
+</pre></div>
+</div>
+</li>
+</ol>
+</div>
+<div class="section" id="usage">
+<span id="basic-cmake-usage"></span><span id="id2"></span><h2><a class="toc-backref" href="#id7">Basic CMake usage</a><a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h2>
+<p>This section explains basic aspects of CMake
+which you may need in your day-to-day usage.</p>
+<p>CMake comes with extensive documentation, in the form of html files, and as
+online help accessible via the <tt class="docutils literal"><span class="pre">cmake</span></tt> executable itself. Execute <tt class="docutils literal"><span class="pre">cmake</span>
+<span class="pre">--help</span></tt> for further help options.</p>
+<p>CMake allows you to specify a build tool (e.g., GNU make, Visual Studio,
+or Xcode). If not specified on the command line, CMake tries to guess which
+build tool to use, based on your environment. Once it has identified your
+build tool, CMake uses the corresponding <em>Generator</em> to create files for your
+build tool (e.g., Makefiles or Visual Studio or Xcode project files). You can
+explicitly specify the generator with the command line option <tt class="docutils literal"><span class="pre">-G</span> <span class="pre">"Name</span> <span class="pre">of</span> <span class="pre">the</span>
+<span class="pre">generator"</span></tt>. To see a list of the available generators on your system, execute</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake --help
+</pre></div>
+</div>
+<p>This will list the generator names at the end of the help text.</p>
+<p>Generators’ names are case-sensitive, and may contain spaces. For this reason,
+you should enter them exactly as they are listed in the <tt class="docutils literal"><span class="pre">cmake</span> <span class="pre">--help</span></tt>
+output, in quotes. For example, to generate project files specifically for
+Visual Studio 12, you can execute:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -G <span class="s2">"Visual Studio 12"</span> path/to/llvm/source/root
+</pre></div>
+</div>
+<p>For a given development platform there can be more than one adequate
+generator. If you use Visual Studio, “NMake Makefiles” is a generator you can use
+for building with NMake. By default, CMake chooses the most specific generator
+supported by your development environment. If you want an alternative generator,
+you must tell this to CMake with the <tt class="docutils literal"><span class="pre">-G</span></tt> option.</p>
+</div>
+<div class="section" id="options-and-variables">
+<span id="id3"></span><h2><a class="toc-backref" href="#id8">Options and variables</a><a class="headerlink" href="#options-and-variables" title="Permalink to this headline">¶</a></h2>
+<p>Variables customize how the build will be generated. Options are boolean
+variables, with possible values ON/OFF. Options and variables are defined on the
+CMake command line like this:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DVARIABLE<span class="o">=</span>value path/to/llvm/source
+</pre></div>
+</div>
+<p>You can set a variable after the initial CMake invocation to change its
+value. You can also undefine a variable:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -UVARIABLE path/to/llvm/source
+</pre></div>
+</div>
+<p>Variables are stored in the CMake cache. This is a file named <tt class="docutils literal"><span class="pre">CMakeCache.txt</span></tt>
+stored at the root of your build directory that is generated by <tt class="docutils literal"><span class="pre">cmake</span></tt>.
+Editing it yourself is not recommended.</p>
+<p>Variables are listed in the CMake cache and later in this document with
+the variable name and type separated by a colon. You can also specify the
+variable and type on the CMake command line:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -DVARIABLE:TYPE<span class="o">=</span>value path/to/llvm/source
+</pre></div>
+</div>
+<div class="section" id="frequently-used-cmake-variables">
+<h3><a class="toc-backref" href="#id9">Frequently-used CMake variables</a><a class="headerlink" href="#frequently-used-cmake-variables" title="Permalink to this headline">¶</a></h3>
+<p>Here are some of the CMake variables that are used often, along with a
+brief explanation and LLVM-specific notes. For full documentation, consult the
+CMake manual, or execute <tt class="docutils literal"><span class="pre">cmake</span> <span class="pre">--help-variable</span> <span class="pre">VARIABLE_NAME</span></tt>.</p>
+<dl class="docutils">
+<dt><strong>CMAKE_BUILD_TYPE</strong>:STRING</dt>
+<dd>Sets the build type for <tt class="docutils literal"><span class="pre">make</span></tt>-based generators. Possible values are
+Release, Debug, RelWithDebInfo and MinSizeRel. If you are using an IDE such as
+Visual Studio, you should use the IDE settings to set the build type.
+Be aware that Release and RelWithDebInfo use different optimization levels on
+most platforms.</dd>
+<dt><strong>CMAKE_INSTALL_PREFIX</strong>:PATH</dt>
+<dd>Path where LLVM will be installed if “make install” is invoked or the
+“install” target is built.</dd>
+<dt><strong>LLVM_LIBDIR_SUFFIX</strong>:STRING</dt>
+<dd>Extra suffix to append to the directory where libraries are to be
+installed. On a 64-bit architecture, one could use <tt class="docutils literal"><span class="pre">-DLLVM_LIBDIR_SUFFIX=64</span></tt>
+to install libraries to <tt class="docutils literal"><span class="pre">/usr/lib64</span></tt>.</dd>
+<dt><strong>CMAKE_C_FLAGS</strong>:STRING</dt>
+<dd>Extra flags to use when compiling C source files.</dd>
+<dt><strong>CMAKE_CXX_FLAGS</strong>:STRING</dt>
+<dd>Extra flags to use when compiling C++ source files.</dd>
+</dl>
+</div>
+<div class="section" id="llvm-specific-variables">
+<span id="id4"></span><h3><a class="toc-backref" href="#id10">LLVM-specific variables</a><a class="headerlink" href="#llvm-specific-variables" title="Permalink to this headline">¶</a></h3>
+<dl class="docutils">
+<dt><strong>LLVM_TARGETS_TO_BUILD</strong>:STRING</dt>
+<dd>Semicolon-separated list of targets to build, or <em>all</em> for building all
+targets. Case-sensitive. Defaults to <em>all</em>. Example:
+<tt class="docutils literal"><span class="pre">-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"</span></tt>.</dd>
+<dt><strong>LLVM_BUILD_TOOLS</strong>:BOOL</dt>
+<dd>Build LLVM tools. Defaults to ON. Targets for building each tool are generated
+in any case. You can build a tool separately by invoking its target. For
+example, you can build <em>llvm-as</em> with a Makefile-based system by executing <em>make
+llvm-as</em> at the root of your build directory.</dd>
+<dt><strong>LLVM_INCLUDE_TOOLS</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM tools. Defaults to ON. You can use this
+option to disable the generation of build targets for the LLVM tools.</dd>
+<dt><strong>LLVM_INSTALL_BINUTILS_SYMLINKS</strong>:BOOL</dt>
+<dd>Install symlinks from the binutils tool names to the corresponding LLVM tools.
+For example, ar will be symlinked to llvm-ar.</dd>
+<dt><strong>LLVM_BUILD_EXAMPLES</strong>:BOOL</dt>
+<dd>Build LLVM examples. Defaults to OFF. Targets for building each example are
+generated in any case. See documentation for <em>LLVM_BUILD_TOOLS</em> above for more
+details.</dd>
+<dt><strong>LLVM_INCLUDE_EXAMPLES</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM examples. Defaults to ON. You can use this
+option to disable the generation of build targets for the LLVM examples.</dd>
+<dt><strong>LLVM_BUILD_TESTS</strong>:BOOL</dt>
+<dd>Build LLVM unit tests. Defaults to OFF. Targets for building each unit test
+are generated in any case. You can build a specific unit test using the
+targets defined under <em>unittests</em>, such as ADTTests, IRTests, SupportTests,
+etc. (Search for <tt class="docutils literal"><span class="pre">add_llvm_unittest</span></tt> in the subdirectories of <em>unittests</em>
+for a complete list of unit tests.) It is possible to build all unit tests
+with the target <em>UnitTests</em>.</dd>
+<dt><strong>LLVM_INCLUDE_TESTS</strong>:BOOL</dt>
+<dd>Generate build targets for the LLVM unit tests. Defaults to ON. You can use
+this option to disable the generation of build targets for the LLVM unit
+tests.</dd>
+<dt><strong>LLVM_APPEND_VC_REV</strong>:BOOL</dt>
+<dd>Embed version control revision info (svn revision number or Git revision id).
+The version info is provided by the <tt class="docutils literal"><span class="pre">LLVM_REVISION</span></tt> macro in
+<tt class="docutils literal"><span class="pre">llvm/include/llvm/Support/VCSRevision.h</span></tt>. Developers using git who don’t
+need revision info can disable this option to avoid re-linking most binaries
+after a branch switch. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_THREADS</strong>:BOOL</dt>
+<dd>Build with threads support, if available. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_CXX1Y</strong>:BOOL</dt>
+<dd>Build in C++1y mode, if available. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_ASSERTIONS</strong>:BOOL</dt>
+<dd>Enables code assertions. Defaults to ON if and only if <tt class="docutils literal"><span class="pre">CMAKE_BUILD_TYPE</span></tt>
+is <em>Debug</em>.</dd>
+<dt><strong>LLVM_ENABLE_EH</strong>:BOOL</dt>
+<dd>Build LLVM with exception-handling support. This is necessary if you wish to
+link against LLVM libraries and make use of C++ exceptions in your own code
+that need to propagate through LLVM code. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_EXPENSIVE_CHECKS</strong>:BOOL</dt>
+<dd>Enable additional time/memory expensive checking. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_PIC</strong>:BOOL</dt>
+<dd>Add the <tt class="docutils literal"><span class="pre">-fPIC</span></tt> flag to the compiler command-line, if the compiler supports
+this flag. Some systems, like Windows, do not need this flag. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_RTTI</strong>:BOOL</dt>
+<dd>Build LLVM with run-time type information. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_WARNINGS</strong>:BOOL</dt>
+<dd>Enable all compiler warnings. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_PEDANTIC</strong>:BOOL</dt>
+<dd>Enable pedantic mode. This disables compiler-specific extensions, if
+possible. Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_WERROR</strong>:BOOL</dt>
+<dd>Stop and fail the build, if a compiler warning is triggered. Defaults to OFF.</dd>
+<dt><strong>LLVM_ABI_BREAKING_CHECKS</strong>:STRING</dt>
+<dd>Used to decide if LLVM should be built with ABI breaking checks or
+not. Allowed values are <cite>WITH_ASSERTS</cite> (default), <cite>FORCE_ON</cite> and
+<cite>FORCE_OFF</cite>. <cite>WITH_ASSERTS</cite> turns on ABI breaking checks in an
+assertion enabled build. <cite>FORCE_ON</cite> (<cite>FORCE_OFF</cite>) turns them on
+(off) irrespective of whether normal (<cite>NDEBUG</cite>-based) assertions are
+enabled or not. A version of LLVM built with ABI breaking checks
+is not ABI compatible with a version built without it.</dd>
+<dt><strong>LLVM_BUILD_32_BITS</strong>:BOOL</dt>
+<dd>Build 32-bit executables and libraries on 64-bit systems. This option is
+available only on some 64-bit Unix systems. Defaults to OFF.</dd>
+<dt><strong>LLVM_TARGET_ARCH</strong>:STRING</dt>
+<dd>LLVM target to use for native code generation. This is required for JIT
+generation. It defaults to “host”, meaning that it shall pick the architecture
+of the machine where LLVM is being built. If you are cross-compiling, set it
+to the target architecture name.</dd>
+<dt><strong>LLVM_TABLEGEN</strong>:STRING</dt>
+<dd>Full path to a native TableGen executable (usually named <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt>). This is
+intended for cross-compiling: if the user sets this variable, no native
+TableGen will be created.</dd>
+<dt><strong>LLVM_LIT_ARGS</strong>:STRING</dt>
+<dd>Arguments given to lit. <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> and <tt class="docutils literal"><span class="pre">make</span> <span class="pre">clang-test</span></tt> are affected.
+By default, <tt class="docutils literal"><span class="pre">'-sv</span> <span class="pre">--no-progress-bar'</span></tt> on Visual C++ and Xcode, <tt class="docutils literal"><span class="pre">'-sv'</span></tt> on
+others.</dd>
+<dt><strong>LLVM_LIT_TOOLS_DIR</strong>:PATH</dt>
+<dd>The path to GnuWin32 tools for tests. Valid on Windows host. Defaults to
+the empty string, in which case lit will look for tools needed for tests
+(e.g. <tt class="docutils literal"><span class="pre">grep</span></tt>, <tt class="docutils literal"><span class="pre">sort</span></tt>, etc.) in your %PATH%. If GnuWin32 is not in your
+%PATH%, then you can set this variable to the GnuWin32 directory so that
+lit can find tools needed for tests in that directory.</dd>
+<dt><strong>LLVM_ENABLE_FFI</strong>:BOOL</dt>
+<dd>Indicates whether the LLVM Interpreter will be linked with the Foreign Function
+Interface library (libffi) in order to enable calling external functions.
+If the library or its headers are installed in a custom
+location, you can also set the variables FFI_INCLUDE_DIR and
+FFI_LIBRARY_DIR to the directories where ffi.h and libffi.so can be found,
+respectively. Defaults to OFF.</dd>
+<dt><strong>LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR</strong>:PATH</dt>
+<dd>These variables specify the path to the source directory for the external
+LLVM projects Clang, lld, and Polly, respectively, relative to the top-level
+source directory. If the in-tree subdirectory for an external project
+exists (e.g., llvm/tools/clang for Clang), then the corresponding variable
+will not be used. If the variable for an external project does not point
+to a valid path, then that project will not be built.</dd>
+<dt><strong>LLVM_ENABLE_PROJECTS</strong>:STRING</dt>
+<dd>Semicolon-separated list of projects to build, or <em>all</em> for building all
+(clang, libcxx, libcxxabi, lldb, compiler-rt, lld, polly) projects.
+This flag assumes that projects are checked out side-by-side and not nested,
+i.e. clang needs to be in parallel of llvm instead of nested in <cite>llvm/tools</cite>.
+This feature allows to have one build for only LLVM and another for clang+llvm
+using the same source checkout.</dd>
+<dt><strong>LLVM_EXTERNAL_PROJECTS</strong>:STRING</dt>
+<dd>Semicolon-separated list of additional external projects to build as part of
+llvm. For each project LLVM_EXTERNAL_<NAME>_SOURCE_DIR have to be specified
+with the path for the source code of the project. Example:
+<tt class="docutils literal"><span class="pre">-DLLVM_EXTERNAL_PROJECTS="Foo;Bar"</span>
+<span class="pre">-DLLVM_EXTERNAL_FOO_SOURCE_DIR=/src/foo</span>
+<span class="pre">-DLLVM_EXTERNAL_BAR_SOURCE_DIR=/src/bar</span></tt>.</dd>
+<dt><strong>LLVM_USE_OPROFILE</strong>:BOOL</dt>
+<dd>Enable building OProfile JIT support. Defaults to OFF.</dd>
+<dt><strong>LLVM_PROFDATA_FILE</strong>:PATH</dt>
+<dd>Path to a profdata file to pass into clang’s -fprofile-instr-use flag. This
+can only be specified if you’re building with clang.</dd>
+<dt><strong>LLVM_USE_INTEL_JITEVENTS</strong>:BOOL</dt>
+<dd>Enable building support for Intel JIT Events API. Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_LIBPFM</strong>:BOOL</dt>
+<dd><p class="first">Enable building with libpfm to support hardware counter measurements in LLVM
+tools.
+Defaults to ON.</p>
+<p class="last"><strong>LLVM_USE_PERF</strong>:BOOL
+Enable building support for Perf (linux profiling tool) JIT support. Defaults to OFF.</p>
+</dd>
+<dt><strong>LLVM_ENABLE_ZLIB</strong>:BOOL</dt>
+<dd>Enable building with zlib to support compression/uncompression in LLVM tools.
+Defaults to ON.</dd>
+<dt><strong>LLVM_ENABLE_DIA_SDK</strong>:BOOL</dt>
+<dd>Enable building with MSVC DIA SDK for PDB debugging support. Available
+only with MSVC. Defaults to ON.</dd>
+<dt><strong>LLVM_USE_SANITIZER</strong>:STRING</dt>
+<dd>Define the sanitizer used to build LLVM binaries and tests. Possible values
+are <tt class="docutils literal"><span class="pre">Address</span></tt>, <tt class="docutils literal"><span class="pre">Memory</span></tt>, <tt class="docutils literal"><span class="pre">MemoryWithOrigins</span></tt>, <tt class="docutils literal"><span class="pre">Undefined</span></tt>, <tt class="docutils literal"><span class="pre">Thread</span></tt>,
+and <tt class="docutils literal"><span class="pre">Address;Undefined</span></tt>. Defaults to empty string.</dd>
+<dt><strong>LLVM_ENABLE_LTO</strong>:STRING</dt>
+<dd>Add <tt class="docutils literal"><span class="pre">-flto</span></tt> or <tt class="docutils literal"><span class="pre">-flto=</span></tt> flags to the compile and link command
+lines, enabling link-time optimization. Possible values are <tt class="docutils literal"><span class="pre">Off</span></tt>,
+<tt class="docutils literal"><span class="pre">On</span></tt>, <tt class="docutils literal"><span class="pre">Thin</span></tt> and <tt class="docutils literal"><span class="pre">Full</span></tt>. Defaults to OFF.</dd>
+<dt><strong>LLVM_USE_LINKER</strong>:STRING</dt>
+<dd>Add <tt class="docutils literal"><span class="pre">-fuse-ld={name}</span></tt> to the link invocation. The possible value depend on
+your compiler, for clang the value can be an absolute path to your custom
+linker, otherwise clang will prefix the name with <tt class="docutils literal"><span class="pre">ld.</span></tt> and apply its usual
+search. For example to link LLVM with the Gold linker, cmake can be invoked
+with <tt class="docutils literal"><span class="pre">-DLLVM_USE_LINKER=gold</span></tt>.</dd>
+<dt><strong>LLVM_ENABLE_LLD</strong>:BOOL</dt>
+<dd>This option is equivalent to <cite>-DLLVM_USE_LINKER=lld</cite>, except during a 2-stage
+build where a dependency is added from the first stage to the second ensuring
+that lld is built before stage2 begins.</dd>
+<dt><strong>LLVM_PARALLEL_COMPILE_JOBS</strong>:STRING</dt>
+<dd>Define the maximum number of concurrent compilation jobs.</dd>
+<dt><strong>LLVM_PARALLEL_LINK_JOBS</strong>:STRING</dt>
+<dd>Define the maximum number of concurrent link jobs.</dd>
+<dt><strong>LLVM_BUILD_DOCS</strong>:BOOL</dt>
+<dd>Adds all <em>enabled</em> documentation targets (i.e. Doxgyen and Sphinx targets) as
+dependencies of the default build targets. This results in all of the (enabled)
+documentation targets being as part of a normal build. If the <tt class="docutils literal"><span class="pre">install</span></tt>
+target is run then this also enables all built documentation targets to be
+installed. Defaults to OFF. To enable a particular documentation target, see
+see LLVM_ENABLE_SPHINX and LLVM_ENABLE_DOXYGEN.</dd>
+<dt><strong>LLVM_ENABLE_DOXYGEN</strong>:BOOL</dt>
+<dd>Enables the generation of browsable HTML documentation using doxygen.
+Defaults to OFF.</dd>
+<dt><strong>LLVM_ENABLE_DOXYGEN_QT_HELP</strong>:BOOL</dt>
+<dd>Enables the generation of a Qt Compressed Help file. Defaults to OFF.
+This affects the make target <tt class="docutils literal"><span class="pre">doxygen-llvm</span></tt>. When enabled, apart from
+the normal HTML output generated by doxygen, this will produce a QCH file
+named <tt class="docutils literal"><span class="pre">org.llvm.qch</span></tt>. You can then load this file into Qt Creator.
+This option is only useful in combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN=ON</span></tt>;
+otherwise this has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QCH_FILENAME</strong>:STRING</dt>
+<dd>The filename of the Qt Compressed Help file that will be generated when
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN=ON</span></tt> and
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt> are given. Defaults to
+<tt class="docutils literal"><span class="pre">org.llvm.qch</span></tt>.
+This option is only useful in combination with
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>;
+otherwise it has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QHP_NAMESPACE</strong>:STRING</dt>
+<dd>Namespace under which the intermediate Qt Help Project file lives. See <a class="reference external" href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters">Qt
+Help Project</a>
+for more information. Defaults to “org.llvm”. This option is only useful in
+combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>; otherwise
+it has no effect.</dd>
+<dt><strong>LLVM_DOXYGEN_QHP_CUST_FILTER_NAME</strong>:STRING</dt>
+<dd>See <a class="reference external" href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters">Qt Help Project</a> for
+more information. Defaults to the CMake variable <tt class="docutils literal"><span class="pre">${PACKAGE_STRING}</span></tt> which
+is a combination of the package name and version string. This filter can then
+be used in Qt Creator to select only documentation from LLVM when browsing
+through all the help files that you might have loaded. This option is only
+useful in combination with <tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>;
+otherwise it has no effect.</dd>
+</dl>
+<dl class="docutils">
+<dt><strong>LLVM_DOXYGEN_QHELPGENERATOR_PATH</strong>:STRING</dt>
+<dd>The path to the <tt class="docutils literal"><span class="pre">qhelpgenerator</span></tt> executable. Defaults to whatever CMake’s
+<tt class="docutils literal"><span class="pre">find_program()</span></tt> can find. This option is only useful in combination with
+<tt class="docutils literal"><span class="pre">-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON</span></tt>; otherwise it has no
+effect.</dd>
+<dt><strong>LLVM_DOXYGEN_SVG</strong>:BOOL</dt>
+<dd>Uses .svg files instead of .png files for graphs in the Doxygen output.
+Defaults to OFF.</dd>
+<dt><strong>LLVM_INSTALL_DOXYGEN_HTML_DIR</strong>:STRING</dt>
+<dd>The path to install Doxygen-generated HTML documentation to. This path can
+either be absolute or relative to the CMAKE_INSTALL_PREFIX. Defaults to
+<cite>share/doc/llvm/doxygen-html</cite>.</dd>
+<dt><strong>LLVM_ENABLE_SPHINX</strong>:BOOL</dt>
+<dd>If specified, CMake will search for the <tt class="docutils literal"><span class="pre">sphinx-build</span></tt> executable and will make
+the <tt class="docutils literal"><span class="pre">SPHINX_OUTPUT_HTML</span></tt> and <tt class="docutils literal"><span class="pre">SPHINX_OUTPUT_MAN</span></tt> CMake options available.
+Defaults to OFF.</dd>
+<dt><strong>SPHINX_EXECUTABLE</strong>:STRING</dt>
+<dd>The path to the <tt class="docutils literal"><span class="pre">sphinx-build</span></tt> executable detected by CMake.
+For installation instructions, see
+<a class="reference external" href="http://www.sphinx-doc.org/en/latest/install.html">http://www.sphinx-doc.org/en/latest/install.html</a></dd>
+<dt><strong>SPHINX_OUTPUT_HTML</strong>:BOOL</dt>
+<dd>If enabled (and <tt class="docutils literal"><span class="pre">LLVM_ENABLE_SPHINX</span></tt> is enabled) then the targets for
+building the documentation as html are added (but not built by default unless
+<tt class="docutils literal"><span class="pre">LLVM_BUILD_DOCS</span></tt> is enabled). There is a target for each project in the
+source tree that uses sphinx (e.g. <tt class="docutils literal"><span class="pre">docs-llvm-html</span></tt>, <tt class="docutils literal"><span class="pre">docs-clang-html</span></tt>
+and <tt class="docutils literal"><span class="pre">docs-lld-html</span></tt>). Defaults to ON.</dd>
+<dt><strong>SPHINX_OUTPUT_MAN</strong>:BOOL</dt>
+<dd>If enabled (and <tt class="docutils literal"><span class="pre">LLVM_ENABLE_SPHINX</span></tt> is enabled) the targets for building
+the man pages are added (but not built by default unless <tt class="docutils literal"><span class="pre">LLVM_BUILD_DOCS</span></tt>
+is enabled). Currently the only target added is <tt class="docutils literal"><span class="pre">docs-llvm-man</span></tt>. Defaults
+to ON.</dd>
+<dt><strong>SPHINX_WARNINGS_AS_ERRORS</strong>:BOOL</dt>
+<dd>If enabled then sphinx documentation warnings will be treated as
+errors. Defaults to ON.</dd>
+<dt><strong>LLVM_INSTALL_SPHINX_HTML_DIR</strong>:STRING</dt>
+<dd>The path to install Sphinx-generated HTML documentation to. This path can
+either be absolute or relative to the CMAKE_INSTALL_PREFIX. Defaults to
+<cite>share/doc/llvm/html</cite>.</dd>
+<dt><strong>LLVM_INSTALL_OCAMLDOC_HTML_DIR</strong>:STRING</dt>
+<dd>The path to install OCamldoc-generated HTML documentation to. This path can
+either be absolute or relative to the CMAKE_INSTALL_PREFIX. Defaults to
+<cite>share/doc/llvm/ocaml-html</cite>.</dd>
+<dt><strong>LLVM_CREATE_XCODE_TOOLCHAIN</strong>:BOOL</dt>
+<dd>OS X Only: If enabled CMake will generate a target named
+‘install-xcode-toolchain’. This target will create a directory at
+$CMAKE_INSTALL_PREFIX/Toolchains containing an xctoolchain directory which can
+be used to override the default system tools.</dd>
+<dt><strong>LLVM_BUILD_LLVM_DYLIB</strong>:BOOL</dt>
+<dd>If enabled, the target for building the libLLVM shared library is added.
+This library contains all of LLVM’s components in a single shared library.
+Defaults to OFF. This cannot be used in conjunction with BUILD_SHARED_LIBS.
+Tools will only be linked to the libLLVM shared library if LLVM_LINK_LLVM_DYLIB
+is also ON.
+The components in the library can be customised by setting LLVM_DYLIB_COMPONENTS
+to a list of the desired components.</dd>
+<dt><strong>LLVM_LINK_LLVM_DYLIB</strong>:BOOL</dt>
+<dd>If enabled, tools will be linked with the libLLVM shared library. Defaults
+to OFF. Setting LLVM_LINK_LLVM_DYLIB to ON also sets LLVM_BUILD_LLVM_DYLIB
+to ON.</dd>
+<dt><strong>BUILD_SHARED_LIBS</strong>:BOOL</dt>
+<dd><p class="first">Flag indicating if each LLVM component (e.g. Support) is built as a shared
+library (ON) or as a static library (OFF). Its default value is OFF. On
+Windows, shared libraries may be used when building with MinGW, including
+mingw-w64, but not when building with the Microsoft toolchain.</p>
+<div class="last admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">BUILD_SHARED_LIBS is only recommended for use by LLVM developers.
+If you want to build LLVM as a shared library, you should use the
+<tt class="docutils literal"><span class="pre">LLVM_BUILD_LLVM_DYLIB</span></tt> option.</p>
+</div>
+</dd>
+<dt><strong>LLVM_OPTIMIZED_TABLEGEN</strong>:BOOL</dt>
+<dd>If enabled and building a debug or asserts build the CMake build system will
+generate a Release build tree to build a fully optimized tablegen for use
+during the build. Enabling this option can significantly speed up build times
+especially when building LLVM in Debug configurations.</dd>
+<dt><strong>LLVM_REVERSE_ITERATION</strong>:BOOL</dt>
+<dd>If enabled, all supported unordered llvm containers would be iterated in
+reverse order. This is useful for uncovering non-determinism caused by
+iteration of unordered containers.</dd>
+<dt><strong>LLVM_BUILD_INSTRUMENTED_COVERAGE</strong>:BOOL</dt>
+<dd>If enabled, <a class="reference external" href="http://clang.llvm.org/docs/SourceBasedCodeCoverage.html">source-based code coverage</a> instrumentation
+is enabled while building llvm.</dd>
+<dt><strong>LLVM_CCACHE_BUILD</strong>:BOOL</dt>
+<dd>If enabled and the <tt class="docutils literal"><span class="pre">ccache</span></tt> program is available, then LLVM will be
+built using <tt class="docutils literal"><span class="pre">ccache</span></tt> to speed up rebuilds of LLVM and its components.
+Defaults to OFF. The size and location of the cache maintained
+by <tt class="docutils literal"><span class="pre">ccache</span></tt> can be adjusted via the LLVM_CCACHE_MAXSIZE and LLVM_CCACHE_DIR
+options, which are passed to the CCACHE_MAXSIZE and CCACHE_DIR environment
+variables, respectively.</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="cmake-caches">
+<h2><a class="toc-backref" href="#id11">CMake Caches</a><a class="headerlink" href="#cmake-caches" title="Permalink to this headline">¶</a></h2>
+<p>Recently LLVM and Clang have been adding some more complicated build system
+features. Utilizing these new features often involves a complicated chain of
+CMake variables passed on the command line. Clang provides a collection of CMake
+cache scripts to make these features more approachable.</p>
+<p>CMake cache files are utilized using CMake’s -C flag:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> cmake -C <path to cache file> <path to sources>
+</pre></div>
+</div>
+<p>CMake cache scripts are processed in an isolated scope, only cached variables
+remain set when the main configuration runs. CMake cached variables do not reset
+variables that are already set unless the FORCE option is specified.</p>
+<p>A few notes about CMake Caches:</p>
+<ul class="simple">
+<li>Order of command line arguments is important<ul>
+<li>-D arguments specified before -C are set before the cache is processed and
+can be read inside the cache file</li>
+<li>-D arguments specified after -C are set after the cache is processed and
+are unset inside the cache file</li>
+</ul>
+</li>
+<li>All -D arguments will override cache file settings</li>
+<li>CMAKE_TOOLCHAIN_FILE is evaluated after both the cache file and the command
+line arguments</li>
+<li>It is recommended that all -D options should be specified <em>before</em> -C</li>
+</ul>
+<p>For more information about some of the advanced build configurations supported
+via Cache files see <a class="reference internal" href="AdvancedBuilds.html"><em>Advanced Build Configurations</em></a>.</p>
+</div>
+<div class="section" id="executing-the-test-suite">
+<h2><a class="toc-backref" href="#id12">Executing the test suite</a><a class="headerlink" href="#executing-the-test-suite" title="Permalink to this headline">¶</a></h2>
+<p>Testing is performed when the <em>check-all</em> target is built. For instance, if you are
+using Makefiles, execute this command in the root of your build directory:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> make check-all
+</pre></div>
+</div>
+<p>On Visual Studio, you may run tests by building the project “check-all”.
+For more information about testing, see the <a class="reference internal" href="TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a>.</p>
+</div>
+<div class="section" id="cross-compiling">
+<h2><a class="toc-backref" href="#id13">Cross compiling</a><a class="headerlink" href="#cross-compiling" title="Permalink to this headline">¶</a></h2>
+<p>See <a class="reference external" href="http://www.vtk.org/Wiki/CMake_Cross_Compiling">this wiki page</a> for
+generic instructions on how to cross-compile with CMake. It goes into detailed
+explanations and may seem daunting, but it is not. On the wiki page there are
+several examples including toolchain files. Go directly to <a class="reference external" href="http://www.vtk.org/Wiki/CMake_Cross_Compiling#Information_how_to_set_up_various_cross_compiling_toolchains">this section</a>
+for a quick solution.</p>
+<p>Also see the <a class="reference internal" href="#llvm-specific-variables">LLVM-specific variables</a> section for variables used when
+cross-compiling.</p>
+</div>
+<div class="section" id="embedding-llvm-in-your-project">
+<h2><a class="toc-backref" href="#id14">Embedding LLVM in your project</a><a class="headerlink" href="#embedding-llvm-in-your-project" title="Permalink to this headline">¶</a></h2>
+<p>From LLVM 3.5 onwards both the CMake and autoconf/Makefile build systems export
+LLVM libraries as importable CMake targets. This means that clients of LLVM can
+now reliably use CMake to develop their own LLVM-based projects against an
+installed version of LLVM regardless of how it was built.</p>
+<p>Here is a simple example of a CMakeLists.txt file that imports the LLVM libraries
+and uses them to build a simple application <tt class="docutils literal"><span class="pre">simple-tool</span></tt>.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.4.3</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">SimpleProject</span><span class="p">)</span>
+
+<span class="nb">find_package</span><span class="p">(</span><span class="s">LLVM</span> <span class="s">REQUIRED</span> <span class="s">CONFIG</span><span class="p">)</span>
+
+<span class="nb">message</span><span class="p">(</span><span class="s">STATUS</span> <span class="s2">"Found LLVM ${LLVM_PACKAGE_VERSION}"</span><span class="p">)</span>
+<span class="nb">message</span><span class="p">(</span><span class="s">STATUS</span> <span class="s2">"Using LLVMConfig.cmake in: ${LLVM_DIR}"</span><span class="p">)</span>
+
+<span class="c"># Set your project compile flags.</span>
+<span class="c"># E.g. if using the C++ header files</span>
+<span class="c"># you will need to enable C++11 support</span>
+<span class="c"># for your compiler.</span>
+
+<span class="nb">include_directories</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_INCLUDE_DIRS</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">add_definitions</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_DEFINITIONS</span><span class="o">}</span><span class="p">)</span>
+
+<span class="c"># Now build our tools</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">simple-tool</span> <span class="s">tool.cpp</span><span class="p">)</span>
+
+<span class="c"># Find the libraries that correspond to the LLVM components</span>
+<span class="c"># that we wish to use</span>
+<span class="nb">llvm_map_components_to_libnames</span><span class="p">(</span><span class="s">llvm_libs</span> <span class="s">support</span> <span class="s">core</span> <span class="s">irreader</span><span class="p">)</span>
+
+<span class="c"># Link against LLVM libraries</span>
+<span class="nb">target_link_libraries</span><span class="p">(</span><span class="s">simple-tool</span> <span class="o">${</span><span class="nv">llvm_libs</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">find_package(...)</span></tt> directive when used in CONFIG mode (as in the above
+example) will look for the <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> file in various locations (see
+cmake manual for details). It creates a <tt class="docutils literal"><span class="pre">LLVM_DIR</span></tt> cache entry to save the
+directory where <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> is found or allows the user to specify the
+directory (e.g. by passing <tt class="docutils literal"><span class="pre">-DLLVM_DIR=/usr/lib/cmake/llvm</span></tt> to
+the <tt class="docutils literal"><span class="pre">cmake</span></tt> command or by setting it directly in <tt class="docutils literal"><span class="pre">ccmake</span></tt> or <tt class="docutils literal"><span class="pre">cmake-gui</span></tt>).</p>
+<p>This file is available in two different locations.</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre"><INSTALL_PREFIX>/lib/cmake/llvm/LLVMConfig.cmake</span></tt> where
+<tt class="docutils literal"><span class="pre"><INSTALL_PREFIX></span></tt> is the install prefix of an installed version of LLVM.
+On Linux typically this is <tt class="docutils literal"><span class="pre">/usr/lib/cmake/llvm/LLVMConfig.cmake</span></tt>.</li>
+<li><tt class="docutils literal"><span class="pre"><LLVM_BUILD_ROOT>/lib/cmake/llvm/LLVMConfig.cmake</span></tt> where
+<tt class="docutils literal"><span class="pre"><LLVM_BUILD_ROOT></span></tt> is the root of the LLVM build tree. <strong>Note: this is only
+available when building LLVM with CMake.</strong></li>
+</ul>
+<p>If LLVM is installed in your operating system’s normal installation prefix (e.g.
+on Linux this is usually <tt class="docutils literal"><span class="pre">/usr/</span></tt>) <tt class="docutils literal"><span class="pre">find_package(LLVM</span> <span class="pre">...)</span></tt> will
+automatically find LLVM if it is installed correctly. If LLVM is not installed
+or you wish to build directly against the LLVM build tree you can use
+<tt class="docutils literal"><span class="pre">LLVM_DIR</span></tt> as previously mentioned.</p>
+<p>The <tt class="docutils literal"><span class="pre">LLVMConfig.cmake</span></tt> file sets various useful variables. Notable variables
+include</p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><span class="pre">LLVM_CMAKE_DIR</span></tt></dt>
+<dd>The path to the LLVM CMake directory (i.e. the directory containing
+LLVMConfig.cmake).</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_DEFINITIONS</span></tt></dt>
+<dd>A list of preprocessor defines that should be used when building against LLVM.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_ASSERTIONS</span></tt></dt>
+<dd>This is set to ON if LLVM was built with assertions, otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_EH</span></tt></dt>
+<dd>This is set to ON if LLVM was built with exception handling (EH) enabled,
+otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_ENABLE_RTTI</span></tt></dt>
+<dd>This is set to ON if LLVM was built with run time type information (RTTI),
+otherwise OFF.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_INCLUDE_DIRS</span></tt></dt>
+<dd>A list of include paths to directories containing LLVM header files.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_PACKAGE_VERSION</span></tt></dt>
+<dd>The LLVM version. This string can be used with CMake conditionals, e.g., <tt class="docutils literal"><span class="pre">if</span>
+<span class="pre">(${LLVM_PACKAGE_VERSION}</span> <span class="pre">VERSION_LESS</span> <span class="pre">"3.5")</span></tt>.</dd>
+<dt><tt class="docutils literal"><span class="pre">LLVM_TOOLS_BINARY_DIR</span></tt></dt>
+<dd>The path to the directory containing the LLVM tools (e.g. <tt class="docutils literal"><span class="pre">llvm-as</span></tt>).</dd>
+</dl>
+<p>Notice that in the above example we link <tt class="docutils literal"><span class="pre">simple-tool</span></tt> against several LLVM
+libraries. The list of libraries is determined by using the
+<tt class="docutils literal"><span class="pre">llvm_map_components_to_libnames()</span></tt> CMake function. For a list of available
+components look at the output of running <tt class="docutils literal"><span class="pre">llvm-config</span> <span class="pre">--components</span></tt>.</p>
+<p>Note that for LLVM < 3.5 <tt class="docutils literal"><span class="pre">llvm_map_components_to_libraries()</span></tt> was
+used instead of <tt class="docutils literal"><span class="pre">llvm_map_components_to_libnames()</span></tt>. This is now deprecated
+and will be removed in a future version of LLVM.</p>
+<div class="section" id="developing-llvm-passes-out-of-source">
+<span id="cmake-out-of-source-pass"></span><h3><a class="toc-backref" href="#id15">Developing LLVM passes out of source</a><a class="headerlink" href="#developing-llvm-passes-out-of-source" title="Permalink to this headline">¶</a></h3>
+<p>It is possible to develop LLVM passes out of LLVM’s source tree (i.e. against an
+installed or built LLVM). An example of a project layout is provided below.</p>
+<div class="highlight-none"><div class="highlight"><pre><project dir>/
+ |
+ CMakeLists.txt
+ <pass name>/
+ |
+ CMakeLists.txt
+ Pass.cpp
+ ...
+</pre></div>
+</div>
+<p>Contents of <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/CMakeLists.txt</span></tt>:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">find_package</span><span class="p">(</span><span class="s">LLVM</span> <span class="s">REQUIRED</span> <span class="s">CONFIG</span><span class="p">)</span>
+
+<span class="nb">add_definitions</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_DEFINITIONS</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">include_directories</span><span class="p">(</span><span class="o">${</span><span class="nv">LLVM_INCLUDE_DIRS</span><span class="o">}</span><span class="p">)</span>
+
+<span class="nb">add_subdirectory</span><span class="p">(</span><span class="s"><pass</span> <span class="s">name></span><span class="p">)</span>
+</pre></div>
+</div>
+<p>Contents of <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/<pass</span> <span class="pre">name>/CMakeLists.txt</span></tt>:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">add_library</span><span class="p">(</span><span class="s">LLVMPassname</span> <span class="s">MODULE</span> <span class="s">Pass.cpp</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>Note if you intend for this pass to be merged into the LLVM source tree at some
+point in the future it might make more sense to use LLVM’s internal
+<tt class="docutils literal"><span class="pre">add_llvm_loadable_module</span></tt> function instead by...</p>
+<p>Adding the following to <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/CMakeLists.txt</span></tt> (after
+<tt class="docutils literal"><span class="pre">find_package(LLVM</span> <span class="pre">...)</span></tt>)</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">list</span><span class="p">(</span><span class="s">APPEND</span> <span class="s">CMAKE_MODULE_PATH</span> <span class="s2">"${LLVM_CMAKE_DIR}"</span><span class="p">)</span>
+<span class="nb">include</span><span class="p">(</span><span class="s">AddLLVM</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>And then changing <tt class="docutils literal"><span class="pre"><project</span> <span class="pre">dir>/<pass</span> <span class="pre">name>/CMakeLists.txt</span></tt> to</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">add_llvm_loadable_module</span><span class="p">(</span><span class="s">LLVMPassname</span>
+ <span class="s">Pass.cpp</span>
+ <span class="p">)</span>
+</pre></div>
+</div>
+<p>When you are done developing your pass, you may wish to integrate it
+into the LLVM source tree. You can achieve it in two easy steps:</p>
+<ol class="arabic simple">
+<li>Copying <tt class="docutils literal"><span class="pre"><pass</span> <span class="pre">name></span></tt> folder into <tt class="docutils literal"><span class="pre"><LLVM</span> <span class="pre">root>/lib/Transform</span></tt> directory.</li>
+<li>Adding <tt class="docutils literal"><span class="pre">add_subdirectory(<pass</span> <span class="pre">name>)</span></tt> line into
+<tt class="docutils literal"><span class="pre"><LLVM</span> <span class="pre">root>/lib/Transform/CMakeLists.txt</span></tt>.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="compiler-platform-specific-topics">
+<h2><a class="toc-backref" href="#id16">Compiler/Platform-specific topics</a><a class="headerlink" href="#compiler-platform-specific-topics" title="Permalink to this headline">¶</a></h2>
+<p>Notes for specific compilers and/or platforms.</p>
+<div class="section" id="microsoft-visual-c">
+<h3><a class="toc-backref" href="#id17">Microsoft Visual C++</a><a class="headerlink" href="#microsoft-visual-c" title="Permalink to this headline">¶</a></h3>
+<dl class="docutils">
+<dt><strong>LLVM_COMPILER_JOBS</strong>:STRING</dt>
+<dd>Specifies the maximum number of parallel compiler jobs to use per project
+when building with msbuild or Visual Studio. Only supported for the Visual
+Studio 2010 CMake generator. 0 means use all processors. Default is 0.</dd>
+</dl>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="CMakePrimer.html" title="CMake Primer"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="LangRef.html" title="LLVM Language Reference Manual"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CMakePrimer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CMakePrimer.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CMakePrimer.html (added)
+++ www-releases/trunk/7.0.1/docs/CMakePrimer.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,504 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>CMake Primer — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="Advanced Build Configurations" href="AdvancedBuilds.html" />
+ <link rel="prev" title="Building LLVM with CMake" href="CMake.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="AdvancedBuilds.html" title="Advanced Build Configurations"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="CMake.html" title="Building LLVM with CMake"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="cmake-primer">
+<h1>CMake Primer<a class="headerlink" href="#cmake-primer" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#ft-view" id="id2">10,000 ft View</a></li>
+<li><a class="reference internal" href="#scripting-overview" id="id3">Scripting Overview</a></li>
+<li><a class="reference internal" href="#variables-types-and-scope" id="id4">Variables, Types, and Scope</a><ul>
+<li><a class="reference internal" href="#dereferencing" id="id5">Dereferencing</a></li>
+<li><a class="reference internal" href="#lists" id="id6">Lists</a></li>
+<li><a class="reference internal" href="#lists-of-lists" id="id7">Lists of Lists</a></li>
+<li><a class="reference internal" href="#other-types" id="id8">Other Types</a></li>
+<li><a class="reference internal" href="#scope" id="id9">Scope</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#control-flow" id="id10">Control Flow</a><ul>
+<li><a class="reference internal" href="#if-elseif-else" id="id11">If, ElseIf, Else</a></li>
+<li><a class="reference internal" href="#loops" id="id12">Loops</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#modules-functions-and-macros" id="id13">Modules, Functions and Macros</a><ul>
+<li><a class="reference internal" href="#modules" id="id14">Modules</a></li>
+<li><a class="reference internal" href="#argument-handling" id="id15">Argument Handling</a></li>
+<li><a class="reference internal" href="#functions-vs-macros" id="id16">Functions Vs Macros</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#llvm-project-wrappers" id="id17">LLVM Project Wrappers</a></li>
+<li><a class="reference internal" href="#useful-built-in-commands" id="id18">Useful Built-in Commands</a></li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">Disclaimer: This documentation is written by LLVM project contributors <cite>not</cite>
+anyone affiliated with the CMake project. This document may contain
+inaccurate terminology, phrasing, or technical details. It is provided with
+the best intentions.</p>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM project and many of the core projects built on LLVM build using CMake.
+This document aims to provide a brief overview of CMake for developers modifying
+LLVM projects or building their own projects on top of LLVM.</p>
+<p>The official CMake language references is available in the cmake-language
+manpage and <a class="reference external" href="https://cmake.org/cmake/help/v3.4/manual/cmake-language.7.html">cmake-language online documentation</a>.</p>
+</div>
+<div class="section" id="ft-view">
+<h2><a class="toc-backref" href="#id2">10,000 ft View</a><a class="headerlink" href="#ft-view" title="Permalink to this headline">¶</a></h2>
+<p>CMake is a tool that reads script files in its own language that describe how a
+software project builds. As CMake evaluates the scripts it constructs an
+internal representation of the software project. Once the scripts have been
+fully processed, if there are no errors, CMake will generate build files to
+actually build the project. CMake supports generating build files for a variety
+of command line build tools as well as for popular IDEs.</p>
+<p>When a user runs CMake it performs a variety of checks similar to how autoconf
+worked historically. During the checks and the evaluation of the build
+description scripts CMake caches values into the CMakeCache. This is useful
+because it allows the build system to skip long-running checks during
+incremental development. CMake caching also has some drawbacks, but that will be
+discussed later.</p>
+</div>
+<div class="section" id="scripting-overview">
+<h2><a class="toc-backref" href="#id3">Scripting Overview</a><a class="headerlink" href="#scripting-overview" title="Permalink to this headline">¶</a></h2>
+<p>CMake’s scripting language has a very simple grammar. Every language construct
+is a command that matches the pattern _name_(_args_). Commands come in three
+primary types: language-defined (commands implemented in C++ in CMake), defined
+functions, and defined macros. The CMake distribution also contains a suite of
+CMake modules that contain definitions for useful functionality.</p>
+<p>The example below is the full CMake build for building a C++ “Hello World”
+program. The example uses only CMake language-defined functions.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.2</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">HelloWorld</span><span class="p">)</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>The CMake language provides control flow constructs in the form of foreach loops
+and if blocks. To make the example above more complicated you could add an if
+block to define “APPLE” when targeting Apple platforms:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">cmake_minimum_required</span><span class="p">(</span><span class="s">VERSION</span> <span class="s">3.2</span><span class="p">)</span>
+<span class="nb">project</span><span class="p">(</span><span class="s">HelloWorld</span><span class="p">)</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span><span class="p">)</span>
+<span class="nb">if</span><span class="p">(</span><span class="s">APPLE</span><span class="p">)</span>
+ <span class="nb">target_compile_definitions</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">PUBLIC</span> <span class="s">APPLE</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="variables-types-and-scope">
+<h2><a class="toc-backref" href="#id4">Variables, Types, and Scope</a><a class="headerlink" href="#variables-types-and-scope" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="dereferencing">
+<h3><a class="toc-backref" href="#id5">Dereferencing</a><a class="headerlink" href="#dereferencing" title="Permalink to this headline">¶</a></h3>
+<p>In CMake variables are “stringly” typed. All variables are represented as
+strings throughout evaluation. Wrapping a variable in <tt class="docutils literal"><span class="pre">${}</span></tt> dereferences it
+and results in a literal substitution of the name for the value. CMake refers to
+this as “variable evaluation” in their documentation. Dereferences are performed
+<em>before</em> the command being called receives the arguments. This means
+dereferencing a list results in multiple separate arguments being passed to the
+command.</p>
+<p>Variable dereferences can be nested and be used to model complex data. For
+example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">set</span><span class="p">(</span><span class="s">var_name</span> <span class="s">var1</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="o">${</span><span class="nv">var_name</span><span class="o">}</span> <span class="s">foo</span><span class="p">)</span> <span class="c"># same as "set(var1 foo)"</span>
+<span class="nb">set</span><span class="p">(</span><span class="o">${</span><span class="nv">${var_name</span><span class="o">}</span><span class="s">}_var</span> <span class="s">bar</span><span class="p">)</span> <span class="c"># same as "set(foo_var bar)"</span>
+</pre></div>
+</div>
+<p>Dereferencing an unset variable results in an empty expansion. It is a common
+pattern in CMake to conditionally set variables knowing that it will be used in
+code paths that the variable isn’t set. There are examples of this throughout
+the LLVM CMake build system.</p>
+<p>An example of variable empty expansion is:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">if</span><span class="p">(</span><span class="s">APPLE</span><span class="p">)</span>
+ <span class="nb">set</span><span class="p">(</span><span class="s">extra_sources</span> <span class="s">Apple.cpp</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+<span class="nb">add_executable</span><span class="p">(</span><span class="s">HelloWorld</span> <span class="s">HelloWorld.cpp</span> <span class="o">${</span><span class="nv">extra_sources</span><span class="o">}</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>In this example the <tt class="docutils literal"><span class="pre">extra_sources</span></tt> variable is only defined if you’re
+targeting an Apple platform. For all other targets the <tt class="docutils literal"><span class="pre">extra_sources</span></tt> will be
+evaluated as empty before add_executable is given its arguments.</p>
+</div>
+<div class="section" id="lists">
+<h3><a class="toc-backref" href="#id6">Lists</a><a class="headerlink" href="#lists" title="Permalink to this headline">¶</a></h3>
+<p>In CMake lists are semi-colon delimited strings, and it is strongly advised that
+you avoid using semi-colons in lists; it doesn’t go smoothly. A few examples of
+defining lists:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="c"># Creates a list with members a, b, c, and d</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span> <span class="s">d</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s2">"a;b;c;d"</span><span class="p">)</span>
+
+<span class="c"># Creates a string "a b c d"</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_string</span> <span class="s2">"a b c d"</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="lists-of-lists">
+<h3><a class="toc-backref" href="#id7">Lists of Lists</a><a class="headerlink" href="#lists-of-lists" title="Permalink to this headline">¶</a></h3>
+<p>One of the more complicated patterns in CMake is lists of lists. Because a list
+cannot contain an element with a semi-colon to construct a list of lists you
+make a list of variable names that refer to other lists. For example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">set</span><span class="p">(</span><span class="s">list_of_lists</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">a</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">b</span> <span class="s">4</span> <span class="s">5</span> <span class="s">6</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">c</span> <span class="s">7</span> <span class="s">8</span> <span class="s">9</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>With this layout you can iterate through the list of lists printing each value
+with the following code:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">list_name</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">list_of_lists</span><span class="p">)</span>
+ <span class="nb">foreach</span><span class="p">(</span><span class="s">value</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="o">${</span><span class="nv">list_name</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">value</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">endforeach</span><span class="p">()</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>You’ll notice that the inner foreach loop’s list is doubly dereferenced. This is
+because the first dereference turns <tt class="docutils literal"><span class="pre">list_name</span></tt> into the name of the sub-list
+(a, b, or c in the example), then the second dereference is to get the value of
+the list.</p>
+<p>This pattern is used throughout CMake, the most common example is the compiler
+flags options, which CMake refers to using the following variable expansions:
+CMAKE_${LANGUAGE}_FLAGS and CMAKE_${LANGUAGE}_FLAGS_${CMAKE_BUILD_TYPE}.</p>
+</div>
+<div class="section" id="other-types">
+<h3><a class="toc-backref" href="#id8">Other Types</a><a class="headerlink" href="#other-types" title="Permalink to this headline">¶</a></h3>
+<p>Variables that are cached or specified on the command line can have types
+associated with them. The variable’s type is used by CMake’s UI tool to display
+the right input field. A variable’s type generally doesn’t impact evaluation,
+however CMake does have special handling for some variables such as PATH.
+You can read more about the special handling in <a class="reference external" href="https://cmake.org/cmake/help/v3.5/command/set.html#set-cache-entry">CMake’s set documentation</a>.</p>
+</div>
+<div class="section" id="scope">
+<h3><a class="toc-backref" href="#id9">Scope</a><a class="headerlink" href="#scope" title="Permalink to this headline">¶</a></h3>
+<p>CMake inherently has a directory-based scoping. Setting a variable in a
+CMakeLists file, will set the variable for that file, and all subdirectories.
+Variables set in a CMake module that is included in a CMakeLists file will be
+set in the scope they are included from, and all subdirectories.</p>
+<p>When a variable that is already set is set again in a subdirectory it overrides
+the value in that scope and any deeper subdirectories.</p>
+<p>The CMake set command provides two scope-related options. PARENT_SCOPE sets a
+variable into the parent scope, and not the current scope. The CACHE option sets
+the variable in the CMakeCache, which results in it being set in all scopes. The
+CACHE option will not set a variable that already exists in the CACHE unless the
+FORCE option is specified.</p>
+<p>In addition to directory-based scope, CMake functions also have their own scope.
+This means variables set inside functions do not bleed into the parent scope.
+This is not true of macros, and it is for this reason LLVM prefers functions
+over macros whenever reasonable.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Unlike C-based languages, CMake’s loop and control flow blocks do not have
+their own scopes.</p>
+</div>
+</div>
+</div>
+<div class="section" id="control-flow">
+<h2><a class="toc-backref" href="#id10">Control Flow</a><a class="headerlink" href="#control-flow" title="Permalink to this headline">¶</a></h2>
+<p>CMake features the same basic control flow constructs you would expect in any
+scripting language, but there are a few quirks because, as with everything in
+CMake, control flow constructs are commands.</p>
+<div class="section" id="if-elseif-else">
+<h3><a class="toc-backref" href="#id11">If, ElseIf, Else</a><a class="headerlink" href="#if-elseif-else" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">For the full documentation on the CMake if command go
+<a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/if.html">here</a>. That resource is
+far more complete.</p>
+</div>
+<p>In general CMake if blocks work the way you’d expect:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">if</span><span class="p">(</span><span class="s"><condition></span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"do stuff"</span><span class="p">)</span>
+<span class="nb">elseif</span><span class="p">(</span><span class="s"><condition></span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"do other stuff"</span><span class="p">)</span>
+<span class="nb">else</span><span class="p">()</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"do other other stuff"</span><span class="p">)</span>
+<span class="nb">endif</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>The single most important thing to know about CMake’s if blocks coming from a C
+background is that they do not have their own scope. Variables set inside
+conditional blocks persist after the <tt class="docutils literal"><span class="pre">endif()</span></tt>.</p>
+</div>
+<div class="section" id="loops">
+<h3><a class="toc-backref" href="#id12">Loops</a><a class="headerlink" href="#loops" title="Permalink to this headline">¶</a></h3>
+<p>The most common form of the CMake <tt class="docutils literal"><span class="pre">foreach</span></tt> block is:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">...</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"do stuff"</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>The variable argument portion of the <tt class="docutils literal"><span class="pre">foreach</span></tt> block can contain dereferenced
+lists, values to iterate, or a mix of both:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">foo</span> <span class="s">bar</span> <span class="s">baz</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># foo</span>
+<span class="c"># bar</span>
+<span class="c"># baz</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="o">${</span><span class="nv">my_list</span><span class="o">}</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="o">${</span><span class="nv">my_list</span><span class="o">}</span> <span class="s">out_of_bounds</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+<span class="c"># out_of_bounds</span>
+</pre></div>
+</div>
+<p>There is also a more modern CMake foreach syntax. The code below is equivalent
+to the code above:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">ITEMS</span> <span class="s">foo</span> <span class="s">bar</span> <span class="s">baz</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># foo</span>
+<span class="c"># bar</span>
+<span class="c"># baz</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span><span class="p">)</span>
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+
+<span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span> <span class="s">ITEMS</span> <span class="s">out_of_bounds</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="o">${</span><span class="nv">var</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endforeach</span><span class="p">()</span>
+<span class="c"># prints:</span>
+<span class="c"># 1</span>
+<span class="c"># 2</span>
+<span class="c"># 3</span>
+<span class="c"># out_of_bounds</span>
+</pre></div>
+</div>
+<p>Similar to the conditional statements, these generally behave how you would
+expect, and they do not have their own scope.</p>
+<p>CMake also supports <tt class="docutils literal"><span class="pre">while</span></tt> loops, although they are not widely used in LLVM.</p>
+</div>
+</div>
+<div class="section" id="modules-functions-and-macros">
+<h2><a class="toc-backref" href="#id13">Modules, Functions and Macros</a><a class="headerlink" href="#modules-functions-and-macros" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="modules">
+<h3><a class="toc-backref" href="#id14">Modules</a><a class="headerlink" href="#modules" title="Permalink to this headline">¶</a></h3>
+<p>Modules are CMake’s vehicle for enabling code reuse. CMake modules are just
+CMake script files. They can contain code to execute on include as well as
+definitions for commands.</p>
+<p>In CMake macros and functions are universally referred to as commands, and they
+are the primary method of defining code that can be called multiple times.</p>
+<p>In LLVM we have several CMake modules that are included as part of our
+distribution for developers who don’t build our project from source. Those
+modules are the fundamental pieces needed to build LLVM-based projects with
+CMake. We also rely on modules as a way of organizing the build system’s
+functionality for maintainability and re-use within LLVM projects.</p>
+</div>
+<div class="section" id="argument-handling">
+<h3><a class="toc-backref" href="#id15">Argument Handling</a><a class="headerlink" href="#argument-handling" title="Permalink to this headline">¶</a></h3>
+<p>When defining a CMake command handling arguments is very useful. The examples
+in this section will all use the CMake <tt class="docutils literal"><span class="pre">function</span></tt> block, but this all applies
+to the <tt class="docutils literal"><span class="pre">macro</span></tt> block as well.</p>
+<p>CMake commands can have named arguments that are requried at every call site. In
+addition, all commands will implicitly accept a variable number of extra
+arguments (In C parlance, all commands are varargs functions). When a command is
+invoked with extra arguments (beyond the named ones) CMake will store the full
+list of arguments (both named and unnamed) in a list named <tt class="docutils literal"><span class="pre">ARGV</span></tt>, and the
+sublist of unnamed arguments in <tt class="docutils literal"><span class="pre">ARGN</span></tt>. Below is a trivial example of
+providing a wrapper function for CMake’s built in function <tt class="docutils literal"><span class="pre">add_dependencies</span></tt>.</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">function</span><span class="p">(</span><span class="s">add_deps</span> <span class="s">target</span><span class="p">)</span>
+ <span class="nb">add_dependencies</span><span class="p">(</span><span class="o">${</span><span class="nv">target</span><span class="o">}</span> <span class="o">${</span><span class="nv">ARGN</span><span class="o">}</span><span class="p">)</span>
+<span class="nb">endfunction</span><span class="p">()</span>
+</pre></div>
+</div>
+<p>This example defines a new macro named <tt class="docutils literal"><span class="pre">add_deps</span></tt> which takes a required first
+argument, and just calls another function passing through the first argument and
+all trailing arguments.</p>
+<p>CMake provides a module <tt class="docutils literal"><span class="pre">CMakeParseArguments</span></tt> which provides an implementation
+of advanced argument parsing. We use this all over LLVM, and it is recommended
+for any function that has complex argument-based behaviors or optional
+arguments. CMake’s official documentation for the module is in the
+<tt class="docutils literal"><span class="pre">cmake-modules</span></tt> manpage, and is also available at the
+<a class="reference external" href="https://cmake.org/cmake/help/v3.4/module/CMakeParseArguments.html">cmake-modules online documentation</a>.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">As of CMake 3.5 the cmake_parse_arguments command has become a native command
+and the CMakeParseArguments module is empty and only left around for
+compatibility.</p>
+</div>
+</div>
+<div class="section" id="functions-vs-macros">
+<h3><a class="toc-backref" href="#id16">Functions Vs Macros</a><a class="headerlink" href="#functions-vs-macros" title="Permalink to this headline">¶</a></h3>
+<p>Functions and Macros look very similar in how they are used, but there is one
+fundamental difference between the two. Functions have their own scope, and
+macros don’t. This means variables set in macros will bleed out into the calling
+scope. That makes macros suitable for defining very small bits of functionality
+only.</p>
+<p>The other difference between CMake functions and macros is how arguments are
+passed. Arguments to macros are not set as variables, instead dereferences to
+the parameters are resolved across the macro before executing it. This can
+result in some unexpected behavior if using unreferenced variables. For example:</p>
+<div class="highlight-cmake"><div class="highlight"><pre><span class="nb">macro</span><span class="p">(</span><span class="s">print_list</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">foreach</span><span class="p">(</span><span class="s">var</span> <span class="s">IN</span> <span class="s">LISTS</span> <span class="s">my_list</span><span class="p">)</span>
+ <span class="nb">message</span><span class="p">(</span><span class="s2">"${var}"</span><span class="p">)</span>
+ <span class="nb">endforeach</span><span class="p">()</span>
+<span class="nb">endmacro</span><span class="p">()</span>
+
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list</span> <span class="s">a</span> <span class="s">b</span> <span class="s">c</span> <span class="s">d</span><span class="p">)</span>
+<span class="nb">set</span><span class="p">(</span><span class="s">my_list_of_numbers</span> <span class="s">1</span> <span class="s">2</span> <span class="s">3</span> <span class="s">4</span><span class="p">)</span>
+<span class="nb">print_list</span><span class="p">(</span><span class="s">my_list_of_numbers</span><span class="p">)</span>
+<span class="c"># prints:</span>
+<span class="c"># a</span>
+<span class="c"># b</span>
+<span class="c"># c</span>
+<span class="c"># d</span>
+</pre></div>
+</div>
+<p>Generally speaking this issue is uncommon because it requires using
+non-dereferenced variables with names that overlap in the parent scope, but it
+is important to be aware of because it can lead to subtle bugs.</p>
+</div>
+</div>
+<div class="section" id="llvm-project-wrappers">
+<h2><a class="toc-backref" href="#id17">LLVM Project Wrappers</a><a class="headerlink" href="#llvm-project-wrappers" title="Permalink to this headline">¶</a></h2>
+<p>LLVM projects provide lots of wrappers around critical CMake built-in commands.
+We use these wrappers to provide consistent behaviors across LLVM components
+and to reduce code duplication.</p>
+<p>We generally (but not always) follow the convention that commands prefaced with
+<tt class="docutils literal"><span class="pre">llvm_</span></tt> are intended to be used only as building blocks for other commands.
+Wrapper commands that are intended for direct use are generally named following
+with the project in the middle of the command name (i.e. <tt class="docutils literal"><span class="pre">add_llvm_executable</span></tt>
+is the wrapper for <tt class="docutils literal"><span class="pre">add_executable</span></tt>). The LLVM <tt class="docutils literal"><span class="pre">add_*</span></tt> wrapper functions are
+all defined in <tt class="docutils literal"><span class="pre">AddLLVM.cmake</span></tt> which is installed as part of the LLVM
+distribution. It can be included and used by any LLVM sub-project that requires
+LLVM.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Not all LLVM projects require LLVM for all use cases. For example compiler-rt
+can be built without LLVM, and the compiler-rt sanitizer libraries are used
+with GCC.</p>
+</div>
+</div>
+<div class="section" id="useful-built-in-commands">
+<h2><a class="toc-backref" href="#id18">Useful Built-in Commands</a><a class="headerlink" href="#useful-built-in-commands" title="Permalink to this headline">¶</a></h2>
+<p>CMake has a bunch of useful built-in commands. This document isn’t going to
+go into details about them because The CMake project has excellent
+documentation. To highlight a few useful functions see:</p>
+<ul class="simple">
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/add_custom_command.html">add_custom_command</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/add_custom_target.html">add_custom_target</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/file.html">file</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/list.html">list</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/math.html">math</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/v3.4/command/string.html">string</a></li>
+</ul>
+<p>The full documentation for CMake commands is in the <tt class="docutils literal"><span class="pre">cmake-commands</span></tt> manpage
+and available on <a class="reference external" href="https://cmake.org/cmake/help/v3.4/manual/cmake-commands.7.html">CMake’s website</a></p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="AdvancedBuilds.html" title="Advanced Build Configurations"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="CMake.html" title="Building LLVM with CMake"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CodeGenerator.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CodeGenerator.html (added)
+++ www-releases/trunk/7.0.1/docs/CodeGenerator.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,2471 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>The LLVM Target-Independent Code Generator — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="Exception Handling in LLVM" href="ExceptionHandling.html" />
+ <link rel="prev" title="LLVM bugpoint tool: design and usage" href="Bugpoint.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="ExceptionHandling.html" title="Exception Handling in LLVM"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="the-llvm-target-independent-code-generator">
+<h1>The LLVM Target-Independent Code Generator<a class="headerlink" href="#the-llvm-target-independent-code-generator" title="Permalink to this headline">¶</a></h1>
+<style>
+ .unknown { background-color: #C0C0C0; text-align: center; }
+ .unknown:before { content: "?" }
+ .no { background-color: #C11B17 }
+ .no:before { content: "N" }
+ .partial { background-color: #F88017 }
+ .yes { background-color: #0F0; }
+ .yes:before { content: "Y" }
+ .na { background-color: #6666FF; }
+ .na:before { content: "N/A" }
+</style><div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id8">Introduction</a><ul>
+<li><a class="reference internal" href="#required-components-in-the-code-generator" id="id9">Required components in the code generator</a></li>
+<li><a class="reference internal" href="#the-high-level-design-of-the-code-generator" id="id10">The high-level design of the code generator</a></li>
+<li><a class="reference internal" href="#using-tablegen-for-target-description" id="id11">Using TableGen for target description</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-description-classes" id="id12">Target description classes</a><ul>
+<li><a class="reference internal" href="#the-targetmachine-class" id="id13">The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-datalayout-class" id="id14">The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetlowering-class" id="id15">The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetregisterinfo-class" id="id16">The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetinstrinfo-class" id="id17">The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetframelowering-class" id="id18">The <tt class="docutils literal"><span class="pre">TargetFrameLowering</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetsubtarget-class" id="id19">The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-targetjitinfo-class" id="id20">The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#machine-code-description-classes" id="id21">Machine code description classes</a><ul>
+<li><a class="reference internal" href="#the-machineinstr-class" id="id22">The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class</a><ul>
+<li><a class="reference internal" href="#using-the-machineinstrbuilder-h-functions" id="id23">Using the <tt class="docutils literal"><span class="pre">MachineInstrBuilder.h</span></tt> functions</a></li>
+<li><a class="reference internal" href="#fixed-preassigned-registers" id="id24">Fixed (preassigned) registers</a></li>
+<li><a class="reference internal" href="#call-clobbered-registers" id="id25">Call-clobbered registers</a></li>
+<li><a class="reference internal" href="#machine-code-in-ssa-form" id="id26">Machine code in SSA form</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-machinebasicblock-class" id="id27">The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-machinefunction-class" id="id28">The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class</a></li>
+<li><a class="reference internal" href="#machineinstr-bundles" id="id29"><tt class="docutils literal"><span class="pre">MachineInstr</span> <span class="pre">Bundles</span></tt></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-mc-layer" id="id30">The “MC” Layer</a><ul>
+<li><a class="reference internal" href="#the-mcstreamer-api" id="id31">The <tt class="docutils literal"><span class="pre">MCStreamer</span></tt> API</a></li>
+<li><a class="reference internal" href="#the-mccontext-class" id="id32">The <tt class="docutils literal"><span class="pre">MCContext</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcsymbol-class" id="id33">The <tt class="docutils literal"><span class="pre">MCSymbol</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcsection-class" id="id34">The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class</a></li>
+<li><a class="reference internal" href="#the-mcinst-class" id="id35">The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-independent-code-generation-algorithms" id="id36">Target-independent code generation algorithms</a><ul>
+<li><a class="reference internal" href="#instruction-selection-section" id="id37">Instruction Selection</a><ul>
+<li><a class="reference internal" href="#introduction-to-selectiondags" id="id38">Introduction to SelectionDAGs</a></li>
+<li><a class="reference internal" href="#selectiondag-instruction-selection-process" id="id39">SelectionDAG Instruction Selection Process</a></li>
+<li><a class="reference internal" href="#initial-selectiondag-construction" id="id40">Initial SelectionDAG Construction</a></li>
+<li><a class="reference internal" href="#selectiondag-legalizetypes-phase" id="id41">SelectionDAG LegalizeTypes Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-legalize-phase" id="id42">SelectionDAG Legalize Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-optimization-phase-the-dag-combiner" id="id43">SelectionDAG Optimization Phase: the DAG Combiner</a></li>
+<li><a class="reference internal" href="#selectiondag-select-phase" id="id44">SelectionDAG Select Phase</a></li>
+<li><a class="reference internal" href="#selectiondag-scheduling-and-formation-phase" id="id45">SelectionDAG Scheduling and Formation Phase</a></li>
+<li><a class="reference internal" href="#future-directions-for-the-selectiondag" id="id46">Future directions for the SelectionDAG</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#ssa-based-machine-code-optimizations" id="id47">SSA-based Machine Code Optimizations</a></li>
+<li><a class="reference internal" href="#live-intervals" id="id48">Live Intervals</a><ul>
+<li><a class="reference internal" href="#live-variable-analysis" id="id49">Live Variable Analysis</a></li>
+<li><a class="reference internal" href="#live-intervals-analysis" id="id50">Live Intervals Analysis</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#register-allocator" id="id51">Register Allocation</a><ul>
+<li><a class="reference internal" href="#how-registers-are-represented-in-llvm" id="id52">How registers are represented in LLVM</a></li>
+<li><a class="reference internal" href="#mapping-virtual-registers-to-physical-registers" id="id53">Mapping virtual registers to physical registers</a></li>
+<li><a class="reference internal" href="#handling-two-address-instructions" id="id54">Handling two address instructions</a></li>
+<li><a class="reference internal" href="#the-ssa-deconstruction-phase" id="id55">The SSA deconstruction phase</a></li>
+<li><a class="reference internal" href="#instruction-folding" id="id56">Instruction folding</a></li>
+<li><a class="reference internal" href="#built-in-register-allocators" id="id57">Built in register allocators</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#prolog-epilog-code-insertion" id="id58">Prolog/Epilog Code Insertion</a></li>
+<li><a class="reference internal" href="#late-machine-code-optimizations" id="id59">Late Machine Code Optimizations</a></li>
+<li><a class="reference internal" href="#code-emission" id="id60">Code Emission</a><ul>
+<li><a class="reference internal" href="#emitting-function-stack-size-information" id="id61">Emitting function stack size information</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#vliw-packetizer" id="id62">VLIW Packetizer</a><ul>
+<li><a class="reference internal" href="#mapping-from-instructions-to-functional-units" id="id63">Mapping from instructions to functional units</a></li>
+<li><a class="reference internal" href="#how-the-packetization-tables-are-generated-and-used" id="id64">How the packetization tables are generated and used</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#implementing-a-native-assembler" id="id65">Implementing a Native Assembler</a><ul>
+<li><a class="reference internal" href="#instruction-parsing" id="id66">Instruction Parsing</a></li>
+<li><a class="reference internal" href="#instruction-alias-processing" id="id67">Instruction Alias Processing</a><ul>
+<li><a class="reference internal" href="#mnemonic-aliases" id="id68">Mnemonic Aliases</a></li>
+<li><a class="reference internal" href="#instruction-aliases" id="id69">Instruction Aliases</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#instruction-matching" id="id70">Instruction Matching</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-specific-implementation-notes" id="id71">Target-specific Implementation Notes</a><ul>
+<li><a class="reference internal" href="#target-feature-matrix" id="id72">Target Feature Matrix</a><ul>
+<li><a class="reference internal" href="#is-generally-reliable" id="id73">Is Generally Reliable</a></li>
+<li><a class="reference internal" href="#assembly-parser" id="id74">Assembly Parser</a></li>
+<li><a class="reference internal" href="#disassembler" id="id75">Disassembler</a></li>
+<li><a class="reference internal" href="#inline-asm" id="id76">Inline Asm</a></li>
+<li><a class="reference internal" href="#jit-support" id="id77">JIT Support</a></li>
+<li><a class="reference internal" href="#o-file-writing" id="id78">.o File Writing</a></li>
+<li><a class="reference internal" href="#tail-calls" id="id79">Tail Calls</a></li>
+<li><a class="reference internal" href="#segmented-stacks" id="id80">Segmented Stacks</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#tail-call-optimization" id="id81">Tail call optimization</a></li>
+<li><a class="reference internal" href="#sibling-call-optimization" id="id82">Sibling call optimization</a></li>
+<li><a class="reference internal" href="#the-x86-backend" id="id83">The X86 backend</a><ul>
+<li><a class="reference internal" href="#x86-target-triples-supported" id="id84">X86 Target Triples supported</a></li>
+<li><a class="reference internal" href="#x86-calling-conventions-supported" id="id85">X86 Calling Conventions supported</a></li>
+<li><a class="reference internal" href="#representing-x86-addressing-modes-in-machineinstrs" id="id86">Representing X86 addressing modes in MachineInstrs</a></li>
+<li><a class="reference internal" href="#x86-address-spaces-supported" id="id87">X86 address spaces supported</a></li>
+<li><a class="reference internal" href="#instruction-naming" id="id88">Instruction naming</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-powerpc-backend" id="id89">The PowerPC backend</a><ul>
+<li><a class="reference internal" href="#llvm-powerpc-abi" id="id90">LLVM PowerPC ABI</a></li>
+<li><a class="reference internal" href="#frame-layout" id="id91">Frame Layout</a></li>
+<li><a class="reference internal" href="#prolog-epilog" id="id92">Prolog/Epilog</a></li>
+<li><a class="reference internal" href="#dynamic-allocation" id="id93">Dynamic Allocation</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-nvptx-backend" id="id94">The NVPTX backend</a></li>
+<li><a class="reference internal" href="#the-extended-berkeley-packet-filter-ebpf-backend" id="id95">The extended Berkeley Packet Filter (eBPF) backend</a><ul>
+<li><a class="reference internal" href="#instruction-encoding-arithmetic-and-jump" id="id96">Instruction encoding (arithmetic and jump)</a></li>
+<li><a class="reference internal" href="#instruction-encoding-load-store" id="id97">Instruction encoding (load, store)</a></li>
+<li><a class="reference internal" href="#packet-data-access-bpf-abs-bpf-ind" id="id98">Packet data access (BPF_ABS, BPF_IND)</a></li>
+<li><a class="reference internal" href="#ebpf-maps" id="id99">eBPF maps</a></li>
+<li><a class="reference internal" href="#function-calls" id="id100">Function calls</a></li>
+<li><a class="reference internal" href="#program-start" id="id101">Program start</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-amdgpu-backend" id="id102">The AMDGPU backend</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">This is a work in progress.</p>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id8">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM target-independent code generator is a framework that provides a suite
+of reusable components for translating the LLVM internal representation to the
+machine code for a specified target—either in assembly form (suitable for a
+static compiler) or in binary machine code format (usable for a JIT
+compiler). The LLVM target-independent code generator consists of six main
+components:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#abstract-target-description">Abstract target description</a> interfaces which capture important properties
+about various aspects of the machine, independently of how they will be used.
+These interfaces are defined in <tt class="docutils literal"><span class="pre">include/llvm/Target/</span></tt>.</li>
+<li>Classes used to represent the <a class="reference internal" href="#code-being-generated">code being generated</a> for a target. These
+classes are intended to be abstract enough to represent the machine code for
+<em>any</em> target machine. These classes are defined in
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen/</span></tt>. At this level, concepts like “constant pool
+entries” and “jump tables” are explicitly exposed.</li>
+<li>Classes and algorithms used to represent code at the object file level, the
+<a class="reference internal" href="#mc-layer">MC Layer</a>. These classes represent assembly level constructs like labels,
+sections, and instructions. At this level, concepts like “constant pool
+entries” and “jump tables” don’t exist.</li>
+<li><a class="reference internal" href="#target-independent-algorithms">Target-independent algorithms</a> used to implement various phases of native
+code generation (register allocation, scheduling, stack frame representation,
+etc). This code lives in <tt class="docutils literal"><span class="pre">lib/CodeGen/</span></tt>.</li>
+<li><a class="reference internal" href="#implementations-of-the-abstract-target-description-interfaces">Implementations of the abstract target description interfaces</a> for
+particular targets. These machine descriptions make use of the components
+provided by LLVM, and can optionally provide custom target-specific passes,
+to build complete code generators for a specific target. Target descriptions
+live in <tt class="docutils literal"><span class="pre">lib/Target/</span></tt>.</li>
+<li>The target-independent JIT components. The LLVM JIT is completely target
+independent (it uses the <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> structure to interface for
+target-specific issues. The code for the target-independent JIT lives in
+<tt class="docutils literal"><span class="pre">lib/ExecutionEngine/JIT</span></tt>.</li>
+</ol>
+<p>Depending on which part of the code generator you are interested in working on,
+different pieces of this will be useful to you. In any case, you should be
+familiar with the <a class="reference internal" href="#target-description">target description</a> and <a class="reference internal" href="#machine-code-representation">machine code representation</a>
+classes. If you want to add a backend for a new target, you will need to
+<a class="reference internal" href="#implement-the-target-description">implement the target description</a> classes for your new target and understand
+the <a class="reference internal" href="LangRef.html"><em>LLVM code representation</em></a>. If you are interested in
+implementing a new <a class="reference internal" href="#code-generation-algorithm">code generation algorithm</a>, it should only depend on the
+target-description and machine code representation classes, ensuring that it is
+portable.</p>
+<div class="section" id="required-components-in-the-code-generator">
+<h3><a class="toc-backref" href="#id9">Required components in the code generator</a><a class="headerlink" href="#required-components-in-the-code-generator" title="Permalink to this headline">¶</a></h3>
+<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
+target-specific backends. The two most important interfaces (<span class="raw-html"><tt></span>
+<a class="reference internal" href="#targetmachine">TargetMachine</a> <span class="raw-html"></tt></span> and <span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a>
+<span class="raw-html"></tt></span>) are the only ones that are required to be defined for a
+backend to fit into the LLVM system, but the others must be defined if the
+reusable code generator components are going to be used.</p>
+<p>This design has two important implications. The first is that LLVM can support
+completely non-traditional code generation targets. For example, the C backend
+does not require register allocation, instruction selection, or any of the other
+standard components provided by the system. As such, it only implements these
+two interfaces, and does its own thing. Note that C backend was removed from the
+trunk since LLVM 3.1 release. Another example of a code generator like this is a
+(purely hypothetical) backend that converts LLVM to the GCC RTL form and uses
+GCC to emit machine code for a target.</p>
+<p>This design also implies that it is possible to design and implement radically
+different code generators in the LLVM system that do not make use of any of the
+built-in components. Doing so is not recommended at all, but could be required
+for radically different targets that do not fit into the LLVM machine
+description model: FPGAs for example.</p>
+</div>
+<div class="section" id="the-high-level-design-of-the-code-generator">
+<span id="high-level-design-of-the-code-generator"></span><h3><a class="toc-backref" href="#id10">The high-level design of the code generator</a><a class="headerlink" href="#the-high-level-design-of-the-code-generator" title="Permalink to this headline">¶</a></h3>
+<p>The LLVM target-independent code generator is designed to support efficient and
+quality code generation for standard register-based microprocessors. Code
+generation in this model is divided into the following stages:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#instruction-selection">Instruction Selection</a> — This phase determines an efficient way to
+express the input LLVM code in the target instruction set. This stage
+produces the initial code for the program in the target instruction set, then
+makes use of virtual registers in SSA form and physical registers that
+represent any required register assignments due to target constraints or
+calling conventions. This step turns the LLVM code into a DAG of target
+instructions.</li>
+<li><a class="reference internal" href="#scheduling-and-formation">Scheduling and Formation</a> — This phase takes the DAG of target
+instructions produced by the instruction selection phase, determines an
+ordering of the instructions, then emits the instructions as <span class="raw-html"><tt></span>
+<a class="reference internal" href="#machineinstr">MachineInstr</a>s <span class="raw-html"></tt></span> with that ordering. Note that we
+describe this in the <a class="reference internal" href="#instruction-selection-section">instruction selection section</a> because it operates on
+a <a class="reference internal" href="#selectiondag">SelectionDAG</a>.</li>
+<li><a class="reference internal" href="#ssa-based-machine-code-optimizations">SSA-based Machine Code Optimizations</a> — This optional stage consists of a
+series of machine-code optimizations that operate on the SSA-form produced by
+the instruction selector. Optimizations like modulo-scheduling or peephole
+optimization work here.</li>
+<li><a class="reference internal" href="#register-allocation">Register Allocation</a> — The target code is transformed from an infinite
+virtual register file in SSA form to the concrete register file used by the
+target. This phase introduces spill code and eliminates all virtual register
+references from the program.</li>
+<li><a class="reference internal" href="#prolog-epilog-code-insertion">Prolog/Epilog Code Insertion</a> — Once the machine code has been generated
+for the function and the amount of stack space required is known (used for
+LLVM alloca’s and spill slots), the prolog and epilog code for the function
+can be inserted and “abstract stack location references” can be eliminated.
+This stage is responsible for implementing optimizations like frame-pointer
+elimination and stack packing.</li>
+<li><a class="reference internal" href="#late-machine-code-optimizations">Late Machine Code Optimizations</a> — Optimizations that operate on “final”
+machine code can go here, such as spill code scheduling and peephole
+optimizations.</li>
+<li><a class="reference internal" href="#code-emission">Code Emission</a> — The final stage actually puts out the code for the
+current function, either in the target assembler format or in machine
+code.</li>
+</ol>
+<p>The code generator is based on the assumption that the instruction selector will
+use an optimal pattern matching selector to create high-quality sequences of
+native instructions. Alternative code generator designs based on pattern
+expansion and aggressive iterative peephole optimization are much slower. This
+design permits efficient compilation (important for JIT environments) and
+aggressive optimization (used when generating code offline) by allowing
+components of varying levels of sophistication to be used for any step of
+compilation.</p>
+<p>In addition to these stages, target implementations can insert arbitrary
+target-specific passes into the flow. For example, the X86 target uses a
+special pass to handle the 80x87 floating point stack architecture. Other
+targets with unusual requirements can be supported with custom passes as needed.</p>
+</div>
+<div class="section" id="using-tablegen-for-target-description">
+<h3><a class="toc-backref" href="#id11">Using TableGen for target description</a><a class="headerlink" href="#using-tablegen-for-target-description" title="Permalink to this headline">¶</a></h3>
+<p>The target description classes require a detailed description of the target
+architecture. These target descriptions often have a large amount of common
+information (e.g., an <tt class="docutils literal"><span class="pre">add</span></tt> instruction is almost identical to a <tt class="docutils literal"><span class="pre">sub</span></tt>
+instruction). In order to allow the maximum amount of commonality to be
+factored out, the LLVM code generator uses the
+<a class="reference internal" href="TableGen/index.html"><em>TableGen</em></a> tool to describe big chunks of the
+target machine, which allows the use of domain-specific and target-specific
+abstractions to reduce the amount of repetition.</p>
+<p>As LLVM continues to be developed and refined, we plan to move more and more of
+the target description to the <tt class="docutils literal"><span class="pre">.td</span></tt> form. Doing so gives us a number of
+advantages. The most important is that it makes it easier to port LLVM because
+it reduces the amount of C++ code that has to be written, and the surface area
+of the code generator that needs to be understood before someone can get
+something working. Second, it makes it easier to change things. In particular,
+if tables and other things are all emitted by <tt class="docutils literal"><span class="pre">tblgen</span></tt>, we only need a change
+in one place (<tt class="docutils literal"><span class="pre">tblgen</span></tt>) to update all of the targets to a new interface.</p>
+</div>
+</div>
+<div class="section" id="target-description-classes">
+<span id="target-description"></span><span id="abstract-target-description"></span><h2><a class="toc-backref" href="#id12">Target description classes</a><a class="headerlink" href="#target-description-classes" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM target description classes (located in the <tt class="docutils literal"><span class="pre">include/llvm/Target</span></tt>
+directory) provide an abstract description of the target machine independent of
+any particular client. These classes are designed to capture the <em>abstract</em>
+properties of the target (such as the instructions and registers it has), and do
+not incorporate any particular pieces of code generation algorithms.</p>
+<p>All of the target description classes (except the <span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a>
+<span class="raw-html"></tt></span> class) are designed to be subclassed by the concrete target
+implementation, and have virtual methods implemented. To get to these
+implementations, the <span class="raw-html"><tt></span> <a class="reference internal" href="#targetmachine">TargetMachine</a> <span class="raw-html"></tt></span> class
+provides accessors that should be implemented by the target.</p>
+<div class="section" id="the-targetmachine-class">
+<span id="targetmachine"></span><h3><a class="toc-backref" href="#id13">The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class</a><a class="headerlink" href="#the-targetmachine-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class provides virtual methods that are used to access the
+target-specific implementations of the various target description classes via
+the <tt class="docutils literal"><span class="pre">get*Info</span></tt> methods (<tt class="docutils literal"><span class="pre">getInstrInfo</span></tt>, <tt class="docutils literal"><span class="pre">getRegisterInfo</span></tt>,
+<tt class="docutils literal"><span class="pre">getFrameInfo</span></tt>, etc.). This class is designed to be specialized by a concrete
+target implementation (e.g., <tt class="docutils literal"><span class="pre">X86TargetMachine</span></tt>) which implements the various
+virtual methods. The only required target description class is the
+<span class="raw-html"><tt></span> <a class="reference internal" href="#datalayout">DataLayout</a> <span class="raw-html"></tt></span> class, but if the code
+generator components are to be used, the other interfaces should be implemented
+as well.</p>
+</div>
+<div class="section" id="the-datalayout-class">
+<span id="datalayout"></span><h3><a class="toc-backref" href="#id14">The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class</a><a class="headerlink" href="#the-datalayout-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">DataLayout</span></tt> class is the only required target description class, and it
+is the only class that is not extensible (you cannot derive a new class from
+it). <tt class="docutils literal"><span class="pre">DataLayout</span></tt> specifies information about how the target lays out memory
+for structures, the alignment requirements for various data types, the size of
+pointers in the target, and whether the target is little-endian or
+big-endian.</p>
+</div>
+<div class="section" id="the-targetlowering-class">
+<span id="targetlowering"></span><h3><a class="toc-backref" href="#id15">The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class</a><a class="headerlink" href="#the-targetlowering-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> class is used by SelectionDAG based instruction selectors
+primarily to describe how LLVM code should be lowered to SelectionDAG
+operations. Among other things, this class indicates:</p>
+<ul class="simple">
+<li>an initial register class to use for various <tt class="docutils literal"><span class="pre">ValueType</span></tt>s,</li>
+<li>which operations are natively supported by the target machine,</li>
+<li>the return type of <tt class="docutils literal"><span class="pre">setcc</span></tt> operations,</li>
+<li>the type to use for shift amounts, and</li>
+<li>various high-level characteristics, like whether it is profitable to turn
+division by a constant into a multiplication sequence.</li>
+</ul>
+</div>
+<div class="section" id="the-targetregisterinfo-class">
+<span id="targetregisterinfo"></span><h3><a class="toc-backref" href="#id16">The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class</a><a class="headerlink" href="#the-targetregisterinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class is used to describe the register file of the
+target and any interactions between the registers.</p>
+<p>Registers are represented in the code generator by unsigned integers. Physical
+registers (those that actually exist in the target description) are unique
+small numbers, and virtual registers are generally large. Note that
+register <tt class="docutils literal"><span class="pre">#0</span></tt> is reserved as a flag value.</p>
+<p>Each register in the processor description has an associated
+<tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt> entry, which provides a textual name for the register
+(used for assembly output and debugging dumps) and a set of aliases (used to
+indicate whether one register overlaps with another).</p>
+<p>In addition to the per-register description, the <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> class
+exposes a set of processor specific register classes (instances of the
+<tt class="docutils literal"><span class="pre">TargetRegisterClass</span></tt> class). Each register class contains sets of registers
+that have the same properties (for example, they are all 32-bit integer
+registers). Each SSA virtual register created by the instruction selector has
+an associated register class. When the register allocator runs, it replaces
+virtual registers with a physical register in the set.</p>
+<p>The target-specific implementations of these classes is auto-generated from a
+<a class="reference internal" href="TableGen/index.html"><em>TableGen</em></a> description of the register file.</p>
+</div>
+<div class="section" id="the-targetinstrinfo-class">
+<span id="targetinstrinfo"></span><h3><a class="toc-backref" href="#id17">The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class</a><a class="headerlink" href="#the-targetinstrinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> class is used to describe the machine instructions
+supported by the target. Descriptions define things like the mnemonic for
+the opcode, the number of operands, the list of implicit register uses and defs,
+whether the instruction has certain target-independent properties (accesses
+memory, is commutable, etc), and holds any target-specific flags.</p>
+</div>
+<div class="section" id="the-targetframelowering-class">
+<h3><a class="toc-backref" href="#id18">The <tt class="docutils literal"><span class="pre">TargetFrameLowering</span></tt> class</a><a class="headerlink" href="#the-targetframelowering-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetFrameLowering</span></tt> class is used to provide information about the stack
+frame layout of the target. It holds the direction of stack growth, the known
+stack alignment on entry to each function, and the offset to the local area.
+The offset to the local area is the offset from the stack pointer on function
+entry to the first location where function data (local variables, spill
+locations) can be stored.</p>
+</div>
+<div class="section" id="the-targetsubtarget-class">
+<h3><a class="toc-backref" href="#id19">The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class</a><a class="headerlink" href="#the-targetsubtarget-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class is used to provide information about the specific
+chip set being targeted. A sub-target informs code generation of which
+instructions are supported, instruction latencies and instruction execution
+itinerary; i.e., which processing units are used, in what order, and for how
+long.</p>
+</div>
+<div class="section" id="the-targetjitinfo-class">
+<h3><a class="toc-backref" href="#id20">The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class</a><a class="headerlink" href="#the-targetjitinfo-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> class exposes an abstract interface used by the
+Just-In-Time code generator to perform target-specific activities, such as
+emitting stubs. If a <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> supports JIT code generation, it should
+provide one of these objects through the <tt class="docutils literal"><span class="pre">getJITInfo</span></tt> method.</p>
+</div>
+</div>
+<div class="section" id="machine-code-description-classes">
+<span id="machine-code-representation"></span><span id="code-being-generated"></span><h2><a class="toc-backref" href="#id21">Machine code description classes</a><a class="headerlink" href="#machine-code-description-classes" title="Permalink to this headline">¶</a></h2>
+<p>At the high-level, LLVM code is translated to a machine specific representation
+formed out of <span class="raw-html"><tt></span> <a class="reference internal" href="#machinefunction">MachineFunction</a> <span class="raw-html"></tt></span>,
+<span class="raw-html"><tt></span> <a class="reference internal" href="#machinebasicblock">MachineBasicBlock</a> <span class="raw-html"></tt></span>, and <span class="raw-html"><tt></span>
+<a class="reference internal" href="#machineinstr">MachineInstr</a> <span class="raw-html"></tt></span> instances (defined in
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen</span></tt>). This representation is completely target agnostic,
+representing instructions in their most abstract form: an opcode and a series of
+operands. This representation is designed to support both an SSA representation
+for machine code, as well as a register allocated, non-SSA form.</p>
+<div class="section" id="the-machineinstr-class">
+<span id="machineinstr"></span><h3><a class="toc-backref" href="#id22">The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class</a><a class="headerlink" href="#the-machineinstr-class" title="Permalink to this headline">¶</a></h3>
+<p>Target machine instructions are represented as instances of the <tt class="docutils literal"><span class="pre">MachineInstr</span></tt>
+class. This class is an extremely abstract way of representing machine
+instructions. In particular, it only keeps track of an opcode number and a set
+of operands.</p>
+<p>The opcode number is a simple unsigned integer that only has meaning to a
+specific backend. All of the instructions for a target should be defined in the
+<tt class="docutils literal"><span class="pre">*InstrInfo.td</span></tt> file for the target. The opcode enum values are auto-generated
+from this description. The <tt class="docutils literal"><span class="pre">MachineInstr</span></tt> class does not have any information
+about how to interpret the instruction (i.e., what the semantics of the
+instruction are); for that you must refer to the <span class="raw-html"><tt></span>
+<a class="reference internal" href="#targetinstrinfo">TargetInstrInfo</a> <span class="raw-html"></tt></span> class.</p>
+<p>The operands of a machine instruction can be of several different types: a
+register reference, a constant integer, a basic block reference, etc. In
+addition, a machine operand should be marked as a def or a use of the value
+(though only registers are allowed to be defs).</p>
+<p>By convention, the LLVM code generator orders instruction operands so that all
+register definitions come before the register uses, even on architectures that
+are normally printed in other orders. For example, the SPARC add instruction:
+“<tt class="docutils literal"><span class="pre">add</span> <span class="pre">%i1,</span> <span class="pre">%i2,</span> <span class="pre">%i3</span></tt>” adds the “%i1”, and “%i2” registers and stores the
+result into the “%i3” register. In the LLVM code generator, the operands should
+be stored as “<tt class="docutils literal"><span class="pre">%i3,</span> <span class="pre">%i1,</span> <span class="pre">%i2</span></tt>”: with the destination first.</p>
+<p>Keeping destination (definition) operands at the beginning of the operand list
+has several advantages. In particular, the debugging printer will print the
+instruction like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="nv">%r3</span> <span class="p">=</span> <span class="k">add</span> <span class="nv">%i1</span><span class="p">,</span> <span class="nv">%i2</span>
+</pre></div>
+</div>
+<p>Also if the first operand is a def, it is easier to <a class="reference internal" href="#create-instructions">create instructions</a> whose
+only def is the first operand.</p>
+<div class="section" id="using-the-machineinstrbuilder-h-functions">
+<span id="create-instructions"></span><h4><a class="toc-backref" href="#id23">Using the <tt class="docutils literal"><span class="pre">MachineInstrBuilder.h</span></tt> functions</a><a class="headerlink" href="#using-the-machineinstrbuilder-h-functions" title="Permalink to this headline">¶</a></h4>
+<p>Machine instructions are created by using the <tt class="docutils literal"><span class="pre">BuildMI</span></tt> functions, located in
+the <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/MachineInstrBuilder.h</span></tt> file. The <tt class="docutils literal"><span class="pre">BuildMI</span></tt>
+functions make it easy to build arbitrary machine instructions. Usage of the
+<tt class="docutils literal"><span class="pre">BuildMI</span></tt> functions look like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')</span>
+<span class="c1">// instruction and insert it at the end of the given MachineBasicBlock.</span>
+<span class="k">const</span> <span class="n">TargetInstrInfo</span> <span class="o">&</span><span class="n">TII</span> <span class="o">=</span> <span class="p">...</span>
+<span class="n">MachineBasicBlock</span> <span class="o">&</span><span class="n">MBB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="n">DebugLoc</span> <span class="n">DL</span><span class="p">;</span>
+<span class="n">MachineInstr</span> <span class="o">*</span><span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">MOV32ri</span><span class="p">),</span> <span class="n">DestReg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create the same instr, but insert it before a specified iterator point.</span>
+<span class="n">MachineBasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">MBBI</span> <span class="o">=</span> <span class="p">...</span>
+<span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">MBBI</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">MOV32ri</span><span class="p">),</span> <span class="n">DestReg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create a 'cmp Reg, 0' instruction, no destination reg.</span>
+<span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">CMP32ri8</span><span class="p">)).</span><span class="n">addReg</span><span class="p">(</span><span class="n">Reg</span><span class="p">).</span><span class="n">addImm</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+
+<span class="c1">// Create an 'sahf' instruction which takes no operands and stores nothing.</span>
+<span class="n">MI</span> <span class="o">=</span> <span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">SAHF</span><span class="p">));</span>
+
+<span class="c1">// Create a self looping branch instruction.</span>
+<span class="n">BuildMI</span><span class="p">(</span><span class="n">MBB</span><span class="p">,</span> <span class="n">DL</span><span class="p">,</span> <span class="n">TII</span><span class="p">.</span><span class="n">get</span><span class="p">(</span><span class="n">X86</span><span class="o">::</span><span class="n">JNE</span><span class="p">)).</span><span class="n">addMBB</span><span class="p">(</span><span class="o">&</span><span class="n">MBB</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>If you need to add a definition operand (other than the optional destination
+register), you must explicitly mark it as such:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">MI</span><span class="p">.</span><span class="n">addReg</span><span class="p">(</span><span class="n">Reg</span><span class="p">,</span> <span class="n">RegState</span><span class="o">::</span><span class="n">Define</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="fixed-preassigned-registers">
+<h4><a class="toc-backref" href="#id24">Fixed (preassigned) registers</a><a class="headerlink" href="#fixed-preassigned-registers" title="Permalink to this headline">¶</a></h4>
+<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 instruction
+stream where the register allocator <em>must</em> arrange for a particular value to be
+in a particular register. This can occur due to limitations of the instruction
+set (e.g., the X86 can only do a 32-bit divide with the <tt class="docutils literal"><span class="pre">EAX</span></tt>/<tt class="docutils literal"><span class="pre">EDX</span></tt>
+registers), or external factors like calling conventions. In any case, the
+instruction selector should emit code that copies a virtual register into or out
+of a physical register when needed.</p>
+<p>For example, consider this simple LLVM example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i32</span> <span class="vg">@test</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%X</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%Y</span><span class="p">)</span> <span class="p">{</span>
+ <span class="nv">%Z</span> <span class="p">=</span> <span class="k">sdiv</span> <span class="k">i32</span> <span class="nv">%X</span><span class="p">,</span> <span class="nv">%Y</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="nv">%Z</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The X86 instruction selector might produce this machine code for the <tt class="docutils literal"><span class="pre">div</span></tt> and
+<tt class="docutils literal"><span class="pre">ret</span></tt>:</p>
+<div class="highlight-text"><div class="highlight"><pre>;; Start of div
+%EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
+%reg1027 = sar %reg1024, 31
+%EDX = mov %reg1027 ;; Sign extend X into EDX
+idiv %reg1025 ;; Divide by Y (in reg1025)
+%reg1026 = mov %EAX ;; Read the result (Z) out of EAX
+
+;; Start of ret
+%EAX = mov %reg1026 ;; 32-bit return value goes in EAX
+ret
+</pre></div>
+</div>
+<p>By the end of code generation, the register allocator would coalesce the
+registers and delete the resultant identity moves producing the following
+code:</p>
+<div class="highlight-text"><div class="highlight"><pre>;; X is in EAX, Y is in ECX
+mov %EAX, %EDX
+sar %EDX, 31
+idiv %ECX
+ret
+</pre></div>
+</div>
+<p>This approach is extremely general (if it can handle the X86 architecture, it
+can handle anything!) and allows all of the target specific knowledge about the
+instruction stream to be isolated in the instruction selector. Note that
+physical registers should have a short lifetime for good code generation, and
+all physical registers are assumed dead on entry to and exit from basic blocks
+(before register allocation). Thus, if you need a value to be live across basic
+block boundaries, it <em>must</em> live in a virtual register.</p>
+</div>
+<div class="section" id="call-clobbered-registers">
+<h4><a class="toc-backref" href="#id25">Call-clobbered registers</a><a class="headerlink" href="#call-clobbered-registers" title="Permalink to this headline">¶</a></h4>
+<p>Some machine instructions, like calls, clobber a large number of physical
+registers. Rather than adding <tt class="docutils literal"><span class="pre"><def,dead></span></tt> operands for all of them, it is
+possible to use an <tt class="docutils literal"><span class="pre">MO_RegisterMask</span></tt> operand instead. The register mask
+operand holds a bit mask of preserved registers, and everything else is
+considered to be clobbered by the instruction.</p>
+</div>
+<div class="section" id="machine-code-in-ssa-form">
+<h4><a class="toc-backref" href="#id26">Machine code in SSA form</a><a class="headerlink" href="#machine-code-in-ssa-form" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">MachineInstr</span></tt>‘s are initially selected in SSA-form, and are maintained in
+SSA-form until register allocation happens. For the most part, this is
+trivially simple since LLVM is already in SSA form; LLVM PHI nodes become
+machine code PHI nodes, and virtual registers are only allowed to have a single
+definition.</p>
+<p>After register allocation, machine code is no longer in SSA-form because there
+are no virtual registers left in the code.</p>
+</div>
+</div>
+<div class="section" id="the-machinebasicblock-class">
+<span id="machinebasicblock"></span><h3><a class="toc-backref" href="#id27">The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class</a><a class="headerlink" href="#the-machinebasicblock-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class contains a list of machine instructions
+(<span class="raw-html"><tt></span> <a class="reference internal" href="#machineinstr">MachineInstr</a> <span class="raw-html"></tt></span> instances). It roughly
+corresponds to the LLVM code input to the instruction selector, but there can be
+a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
+basic blocks). The <tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> class has a “<tt class="docutils literal"><span class="pre">getBasicBlock</span></tt>” method,
+which returns the LLVM basic block that it comes from.</p>
+</div>
+<div class="section" id="the-machinefunction-class">
+<span id="machinefunction"></span><h3><a class="toc-backref" href="#id28">The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class</a><a class="headerlink" href="#the-machinefunction-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> class contains a list of machine basic blocks
+(<span class="raw-html"><tt></span> <a class="reference internal" href="#machinebasicblock">MachineBasicBlock</a> <span class="raw-html"></tt></span> instances). It
+corresponds one-to-one with the LLVM function input to the instruction selector.
+In addition to a list of basic blocks, the <tt class="docutils literal"><span class="pre">MachineFunction</span></tt> contains a a
+<tt class="docutils literal"><span class="pre">MachineConstantPool</span></tt>, a <tt class="docutils literal"><span class="pre">MachineFrameInfo</span></tt>, a <tt class="docutils literal"><span class="pre">MachineFunctionInfo</span></tt>, and
+a <tt class="docutils literal"><span class="pre">MachineRegisterInfo</span></tt>. See <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/MachineFunction.h</span></tt> for
+more information.</p>
+</div>
+<div class="section" id="machineinstr-bundles">
+<h3><a class="toc-backref" href="#id29"><tt class="docutils literal"><span class="pre">MachineInstr</span> <span class="pre">Bundles</span></tt></a><a class="headerlink" href="#machineinstr-bundles" title="Permalink to this headline">¶</a></h3>
+<p>LLVM code generator can model sequences of instructions as MachineInstr
+bundles. A MI bundle can model a VLIW group / pack which contains an arbitrary
+number of parallel instructions. It can also be used to model a sequential list
+of instructions (potentially with data dependencies) that cannot be legally
+separated (e.g. ARM Thumb2 IT blocks).</p>
+<p>Conceptually a MI bundle is a MI with a number of other MIs nested within:</p>
+<div class="highlight-python"><pre>--------------
+| Bundle | ---------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ |
+--------------
+| Bundle | --------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ...
+ |
+--------------
+| Bundle | --------
+-------------- \
+ |
+ ...</pre>
+</div>
+<p>MI bundle support does not change the physical representations of
+MachineBasicBlock and MachineInstr. All the MIs (including top level and nested
+ones) are stored as sequential list of MIs. The “bundled” MIs are marked with
+the ‘InsideBundle’ flag. A top level MI with the special BUNDLE opcode is used
+to represent the start of a bundle. It’s legal to mix BUNDLE MIs with individual
+MIs that are not inside bundles nor represent bundles.</p>
+<p>MachineInstr passes should operate on a MI bundle as a single unit. Member
+methods have been taught to correctly handle bundles and MIs inside bundles.
+The MachineBasicBlock iterator has been modified to skip over bundled MIs to
+enforce the bundle-as-a-single-unit concept. An alternative iterator
+instr_iterator has been added to MachineBasicBlock to allow passes to iterate
+over all of the MIs in a MachineBasicBlock, including those which are nested
+inside bundles. The top level BUNDLE instruction must have the correct set of
+register MachineOperand’s that represent the cumulative inputs and outputs of
+the bundled MIs.</p>
+<p>Packing / bundling of MachineInstr’s should be done as part of the register
+allocation super-pass. More specifically, the pass which determines what MIs
+should be bundled together must be done after code generator exits SSA form
+(i.e. after two-address pass, PHI elimination, and copy coalescing). Bundles
+should only be finalized (i.e. adding BUNDLE MIs and input and output register
+MachineOperands) after virtual registers have been rewritten into physical
+registers. This requirement eliminates the need to add virtual register operands
+to BUNDLE instructions which would effectively double the virtual register def
+and use lists.</p>
+</div>
+</div>
+<div class="section" id="the-mc-layer">
+<span id="mc-layer"></span><h2><a class="toc-backref" href="#id30">The “MC” Layer</a><a class="headerlink" href="#the-mc-layer" title="Permalink to this headline">¶</a></h2>
+<p>The MC Layer is used to represent and process code at the raw machine code
+level, devoid of “high level” information like “constant pools”, “jump tables”,
+“global variables” or anything like that. At this level, LLVM handles things
+like label names, machine instructions, and sections in the object file. The
+code in this layer is used for a number of important purposes: the tail end of
+the code generator uses it to write a .s or .o file, and it is also used by the
+llvm-mc tool to implement standalone machine code assemblers and disassemblers.</p>
+<p>This section describes some of the important classes. There are also a number
+of important subsystems that interact at this layer, they are described later in
+this manual.</p>
+<div class="section" id="the-mcstreamer-api">
+<span id="mcstreamer"></span><h3><a class="toc-backref" href="#id31">The <tt class="docutils literal"><span class="pre">MCStreamer</span></tt> API</a><a class="headerlink" href="#the-mcstreamer-api" title="Permalink to this headline">¶</a></h3>
+<p>MCStreamer is best thought of as an assembler API. It is an abstract API which
+is <em>implemented</em> in different ways (e.g. to output a .s file, output an ELF .o
+file, etc) but whose API correspond directly to what you see in a .s file.
+MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute,
+SwitchSection, EmitValue (for .byte, .word), etc, which directly correspond to
+assembly level directives. It also has an EmitInstruction method, which is used
+to output an MCInst to the streamer.</p>
+<p>This API is most important for two clients: the llvm-mc stand-alone assembler is
+effectively a parser that parses a line, then invokes a method on MCStreamer. In
+the code generator, the <a class="reference internal" href="#code-emission">Code Emission</a> phase of the code generator lowers
+higher level LLVM IR and Machine* constructs down to the MC layer, emitting
+directives through MCStreamer.</p>
+<p>On the implementation side of MCStreamer, there are two major implementations:
+one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
+file (MCObjectStreamer). MCAsmStreamer is a straightforward implementation
+that prints out a directive for each method (e.g. <tt class="docutils literal"><span class="pre">EmitValue</span> <span class="pre">-></span> <span class="pre">.byte</span></tt>), but
+MCObjectStreamer implements a full assembler.</p>
+<p>For target specific directives, the MCStreamer has a MCTargetStreamer instance.
+Each target that needs it defines a class that inherits from it and is a lot
+like MCStreamer itself: It has one method per directive and two classes that
+inherit from it, a target object streamer and a target asm streamer. The target
+asm streamer just prints it (<tt class="docutils literal"><span class="pre">emitFnStart</span> <span class="pre">-></span> <span class="pre">.fnstart</span></tt>), and the object
+streamer implement the assembler logic for it.</p>
+<p>To make llvm use these classes, the target initialization must call
+TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer
+passing callbacks that allocate the corresponding target streamer and pass it
+to createAsmStreamer or to the appropriate object streamer constructor.</p>
+</div>
+<div class="section" id="the-mccontext-class">
+<h3><a class="toc-backref" href="#id32">The <tt class="docutils literal"><span class="pre">MCContext</span></tt> class</a><a class="headerlink" href="#the-mccontext-class" title="Permalink to this headline">¶</a></h3>
+<p>The MCContext class is the owner of a variety of uniqued data structures at the
+MC layer, including symbols, sections, etc. As such, this is the class that you
+interact with to create symbols and sections. This class can not be subclassed.</p>
+</div>
+<div class="section" id="the-mcsymbol-class">
+<h3><a class="toc-backref" href="#id33">The <tt class="docutils literal"><span class="pre">MCSymbol</span></tt> class</a><a class="headerlink" href="#the-mcsymbol-class" title="Permalink to this headline">¶</a></h3>
+<p>The MCSymbol class represents a symbol (aka label) in the assembly file. There
+are two interesting kinds of symbols: assembler temporary symbols, and normal
+symbols. Assembler temporary symbols are used and processed by the assembler
+but are discarded when the object file is produced. The distinction is usually
+represented by adding a prefix to the label, for example “L” labels are
+assembler temporary labels in MachO.</p>
+<p>MCSymbols are created by MCContext and uniqued there. This means that MCSymbols
+can be compared for pointer equivalence to find out if they are the same symbol.
+Note that pointer inequality does not guarantee the labels will end up at
+different addresses though. It’s perfectly legal to output something like this
+to the .s file:</p>
+<div class="highlight-python"><pre>foo:
+bar:
+ .byte 4</pre>
+</div>
+<p>In this case, both the foo and bar symbols will have the same address.</p>
+</div>
+<div class="section" id="the-mcsection-class">
+<h3><a class="toc-backref" href="#id34">The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class</a><a class="headerlink" href="#the-mcsection-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MCSection</span></tt> class represents an object-file specific section. It is
+subclassed by object file specific implementations (e.g. <tt class="docutils literal"><span class="pre">MCSectionMachO</span></tt>,
+<tt class="docutils literal"><span class="pre">MCSectionCOFF</span></tt>, <tt class="docutils literal"><span class="pre">MCSectionELF</span></tt>) and these are created and uniqued by
+MCContext. The MCStreamer has a notion of the current section, which can be
+changed with the SwitchToSection method (which corresponds to a ”.section”
+directive in a .s file).</p>
+</div>
+<div class="section" id="the-mcinst-class">
+<span id="mcinst"></span><h3><a class="toc-backref" href="#id35">The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class</a><a class="headerlink" href="#the-mcinst-class" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">MCInst</span></tt> class is a target-independent representation of an instruction.
+It is a simple class (much more so than <a class="reference internal" href="#machineinstr">MachineInstr</a>) that holds a
+target-specific opcode and a vector of MCOperands. MCOperand, in turn, is a
+simple discriminated union of three cases: 1) a simple immediate, 2) a target
+register ID, 3) a symbolic expression (e.g. “<tt class="docutils literal"><span class="pre">Lfoo-Lbar+42</span></tt>”) as an MCExpr.</p>
+<p>MCInst is the common currency used to represent machine instructions at the MC
+layer. It is the type used by the instruction encoder, the instruction printer,
+and the type generated by the assembly parser and disassembler.</p>
+</div>
+</div>
+<div class="section" id="target-independent-code-generation-algorithms">
+<span id="code-generation-algorithm"></span><span id="target-independent-algorithms"></span><h2><a class="toc-backref" href="#id36">Target-independent code generation algorithms</a><a class="headerlink" href="#target-independent-code-generation-algorithms" title="Permalink to this headline">¶</a></h2>
+<p>This section documents the phases described in the <a class="reference internal" href="#high-level-design-of-the-code-generator">high-level design of the
+code generator</a>. It explains how they work and some of the rationale behind
+their design.</p>
+<div class="section" id="instruction-selection-section">
+<span id="instruction-selection"></span><span id="id1"></span><h3><a class="toc-backref" href="#id37">Instruction Selection</a><a class="headerlink" href="#instruction-selection-section" title="Permalink to this headline">¶</a></h3>
+<p>Instruction Selection is the process of translating LLVM code presented to the
+code generator into target-specific machine instructions. There are several
+well-known ways to do this in the literature. LLVM uses a SelectionDAG based
+instruction selector.</p>
+<p>Portions of the DAG instruction selector are generated from the target
+description (<tt class="docutils literal"><span class="pre">*.td</span></tt>) files. Our goal is for the entire instruction selector
+to be generated from these <tt class="docutils literal"><span class="pre">.td</span></tt> files, though currently there are still
+things that require custom C++ code.</p>
+<div class="section" id="introduction-to-selectiondags">
+<span id="selectiondag"></span><h4><a class="toc-backref" href="#id38">Introduction to SelectionDAGs</a><a class="headerlink" href="#introduction-to-selectiondags" title="Permalink to this headline">¶</a></h4>
+<p>The SelectionDAG provides an abstraction for code representation in a way that
+is amenable to instruction selection using automatic techniques
+(e.g. dynamic-programming based optimal pattern matching selectors). It is also
+well-suited to other phases of code generation; in particular, instruction
+scheduling (SelectionDAG’s are very close to scheduling DAGs post-selection).
+Additionally, the SelectionDAG provides a host representation where a large
+variety of very-low-level (but target-independent) <a class="reference internal" href="#optimizations">optimizations</a> may be
+performed; ones which require extensive information about the instructions
+efficiently supported by the target.</p>
+<p>The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+<tt class="docutils literal"><span class="pre">SDNode</span></tt> class. The primary payload of the <tt class="docutils literal"><span class="pre">SDNode</span></tt> is its operation code
+(Opcode) that indicates what operation the node performs and the operands to the
+operation. The various operation node types are described at the top of the
+<tt class="docutils literal"><span class="pre">include/llvm/CodeGen/ISDOpcodes.h</span></tt> file.</p>
+<p>Although most operations define a single value, each node in the graph may
+define multiple values. For example, a combined div/rem operation will define
+both the dividend and the remainder. Many other situations require multiple
+values as well. Each node also has some number of operands, which are edges to
+the node defining the used value. Because nodes may define multiple values,
+edges are represented by instances of the <tt class="docutils literal"><span class="pre">SDValue</span></tt> class, which is a
+<tt class="docutils literal"><span class="pre"><SDNode,</span> <span class="pre">unsigned></span></tt> pair, indicating the node and result value being used,
+respectively. Each value produced by an <tt class="docutils literal"><span class="pre">SDNode</span></tt> has an associated <tt class="docutils literal"><span class="pre">MVT</span></tt>
+(Machine Value Type) indicating what the type of the value is.</p>
+<p>SelectionDAGs contain two different kinds of values: those that represent data
+flow and those that represent control flow dependencies. Data values are simple
+edges with an integer or floating point value type. Control edges are
+represented as “chain” edges which are of type <tt class="docutils literal"><span class="pre">MVT::Other</span></tt>. These edges
+provide an ordering between nodes that have side effects (such as loads, stores,
+calls, returns, etc). All nodes that have side effects should take a token
+chain as input and produce a new one as output. By convention, token chain
+inputs are always operand #0, and chain results are always the last value
+produced by an operation. However, after instruction selection, the
+machine nodes have their chain after the instruction’s operands, and
+may be followed by glue nodes.</p>
+<p>A SelectionDAG has designated “Entry” and “Root” nodes. The Entry node is
+always a marker node with an Opcode of <tt class="docutils literal"><span class="pre">ISD::EntryToken</span></tt>. The Root node is
+the final side-effecting node in the token chain. For example, in a single basic
+block function it would be the return node.</p>
+<p>One important concept for SelectionDAGs is the notion of a “legal” vs.
+“illegal” DAG. A legal DAG for a target is one that only uses supported
+operations and supported types. On a 32-bit PowerPC, for example, a DAG with a
+value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a
+SREM or UREM operation. The <a class="reference internal" href="#legalize-types">legalize types</a> and <a class="reference internal" href="#legalize-operations">legalize operations</a> phases
+are responsible for turning an illegal DAG into a legal DAG.</p>
+</div>
+<div class="section" id="selectiondag-instruction-selection-process">
+<span id="selectiondag-process"></span><h4><a class="toc-backref" href="#id39">SelectionDAG Instruction Selection Process</a><a class="headerlink" href="#selectiondag-instruction-selection-process" title="Permalink to this headline">¶</a></h4>
+<p>SelectionDAG-based instruction selection consists of the following steps:</p>
+<ol class="arabic simple">
+<li><a class="reference internal" href="#build-initial-dag">Build initial DAG</a> — This stage performs a simple translation from the
+input LLVM code to an illegal SelectionDAG.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — This stage performs simple optimizations on the
+SelectionDAG to simplify it, and recognize meta instructions (like rotates
+and <tt class="docutils literal"><span class="pre">div</span></tt>/<tt class="docutils literal"><span class="pre">rem</span></tt> pairs) for targets that support these meta operations.
+This makes the resultant code more efficient and the <a class="reference internal" href="#select-instructions-from-dag">select instructions
+from DAG</a> phase (below) simpler.</li>
+<li><a class="reference internal" href="#legalize-selectiondag-types">Legalize SelectionDAG Types</a> — This stage transforms SelectionDAG nodes
+to eliminate any types that are unsupported on the target.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — The SelectionDAG optimizer is run to clean up
+redundancies exposed by type legalization.</li>
+<li><a class="reference internal" href="#legalize-selectiondag-ops">Legalize SelectionDAG Ops</a> — This stage transforms SelectionDAG nodes to
+eliminate any operations that are unsupported on the target.</li>
+<li><a class="reference internal" href="#optimize-selectiondag">Optimize SelectionDAG</a> — The SelectionDAG optimizer is run to eliminate
+inefficiencies introduced by operation legalization.</li>
+<li><a class="reference internal" href="#select-instructions-from-dag">Select instructions from DAG</a> — Finally, the target instruction selector
+matches the DAG operations to target instructions. This process translates
+the target-independent input DAG into another DAG of target instructions.</li>
+<li><a class="reference internal" href="#selectiondag-scheduling-and-formation">SelectionDAG Scheduling and Formation</a> — The last phase assigns a linear
+order to the instructions in the target-instruction DAG and emits them into
+the MachineFunction being compiled. This step uses traditional prepass
+scheduling techniques.</li>
+</ol>
+<p>After all of these steps are complete, the SelectionDAG is destroyed and the
+rest of the code generation passes are run.</p>
+<p>One great way to visualize what is going on here is to take advantage of a few
+LLC command line options. The following options pop up a window displaying the
+SelectionDAG at specific times (if you only get errors printed to the console
+while using this, you probably <a class="reference external" href="ProgrammersManual.html#viewing-graphs-while-debugging-code">need to configure your
+system</a> to add support for it).</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">-view-dag-combine1-dags</span></tt> displays the DAG after being built, before the
+first optimization pass.</li>
+<li><tt class="docutils literal"><span class="pre">-view-legalize-dags</span></tt> displays the DAG before Legalization.</li>
+<li><tt class="docutils literal"><span class="pre">-view-dag-combine2-dags</span></tt> displays the DAG before the second optimization
+pass.</li>
+<li><tt class="docutils literal"><span class="pre">-view-isel-dags</span></tt> displays the DAG before the Select phase.</li>
+<li><tt class="docutils literal"><span class="pre">-view-sched-dags</span></tt> displays the DAG before Scheduling.</li>
+</ul>
+<p>The <tt class="docutils literal"><span class="pre">-view-sunit-dags</span></tt> displays the Scheduler’s dependency graph. This graph
+is based on the final SelectionDAG, with nodes that must be scheduled together
+bundled into a single scheduling-unit node, and with immediate operands and
+other nodes that aren’t relevant for scheduling omitted.</p>
+<p>The option <tt class="docutils literal"><span class="pre">-filter-view-dags</span></tt> allows to select the name of the basic block
+that you are interested to visualize and filters all the previous
+<tt class="docutils literal"><span class="pre">view-*-dags</span></tt> options.</p>
+</div>
+<div class="section" id="initial-selectiondag-construction">
+<span id="build-initial-dag"></span><h4><a class="toc-backref" href="#id40">Initial SelectionDAG Construction</a><a class="headerlink" href="#initial-selectiondag-construction" title="Permalink to this headline">¶</a></h4>
+<p>The initial SelectionDAG is na<span class="raw-html">ï</span>vely peephole expanded from
+the LLVM input by the <tt class="docutils literal"><span class="pre">SelectionDAGBuilder</span></tt> class. The intent of this pass
+is to expose as much low-level, target-specific details to the SelectionDAG as
+possible. This pass is mostly hard-coded (e.g. an LLVM <tt class="docutils literal"><span class="pre">add</span></tt> turns into an
+<tt class="docutils literal"><span class="pre">SDNode</span> <span class="pre">add</span></tt> while a <tt class="docutils literal"><span class="pre">getelementptr</span></tt> is expanded into the obvious
+arithmetic). This pass requires target-specific hooks to lower calls, returns,
+varargs, etc. For these features, the <span class="raw-html"><tt></span> <a class="reference internal" href="#targetlowering">TargetLowering</a>
+<span class="raw-html"></tt></span> interface is used.</p>
+</div>
+<div class="section" id="selectiondag-legalizetypes-phase">
+<span id="legalize-selectiondag-ops"></span><span id="legalize-selectiondag-types"></span><span id="legalize-types"></span><h4><a class="toc-backref" href="#id41">SelectionDAG LegalizeTypes Phase</a><a class="headerlink" href="#selectiondag-legalizetypes-phase" title="Permalink to this headline">¶</a></h4>
+<p>The Legalize phase is in charge of converting a DAG to only use the types that
+are natively supported by the target.</p>
+<p>There are two main ways of converting values of unsupported scalar types to
+values of supported types: converting small types to larger types (“promoting”),
+and breaking up large integer types into smaller ones (“expanding”). For
+example, a target might require that all f32 values are promoted to f64 and that
+all i1/i8/i16 values are promoted to i32. The same target might require that
+all i64 values be expanded into pairs of i32 values. These changes can insert
+sign and zero extensions as needed to make sure that the final code has the same
+behavior as the input.</p>
+<p>There are two main ways of converting values of unsupported vector types to
+value of supported types: splitting vector types, multiple times if necessary,
+until a legal type is found, and extending vector types by adding elements to
+the end to round them out to legal types (“widening”). If a vector gets split
+all the way down to single-element parts with no supported vector type being
+found, the elements are converted to scalars (“scalarizing”).</p>
+<p>A target implementation tells the legalizer which types are supported (and which
+register class to use for them) by calling the <tt class="docutils literal"><span class="pre">addRegisterClass</span></tt> method in
+its <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> constructor.</p>
+</div>
+<div class="section" id="selectiondag-legalize-phase">
+<span id="legalizer"></span><span id="legalize-operations"></span><h4><a class="toc-backref" href="#id42">SelectionDAG Legalize Phase</a><a class="headerlink" href="#selectiondag-legalize-phase" title="Permalink to this headline">¶</a></h4>
+<p>The Legalize phase is in charge of converting a DAG to only use the operations
+that are natively supported by the target.</p>
+<p>Targets often have weird constraints, such as not supporting every operation on
+every supported datatype (e.g. X86 does not support byte conditional moves and
+PowerPC does not support sign-extending loads from a 16-bit memory location).
+Legalize takes care of this by open-coding another sequence of operations to
+emulate the operation (“expansion”), by promoting one type to a larger type that
+supports the operation (“promotion”), or by using a target-specific hook to
+implement the legalization (“custom”).</p>
+<p>A target implementation tells the legalizer which operations are not supported
+(and which of the above three actions to take) by calling the
+<tt class="docutils literal"><span class="pre">setOperationAction</span></tt> method in its <tt class="docutils literal"><span class="pre">TargetLowering</span></tt> constructor.</p>
+<p>Prior to the existence of the Legalize passes, we required that every target
+<a class="reference internal" href="#selector">selector</a> supported and handled every operator and type even if they are not
+natively supported. The introduction of the Legalize phases allows all of the
+canonicalization patterns to be shared across targets, and makes it very easy to
+optimize the canonicalized code because it is still in the form of a DAG.</p>
+</div>
+<div class="section" id="selectiondag-optimization-phase-the-dag-combiner">
+<span id="selector"></span><span id="optimize-selectiondag"></span><span id="optimizations"></span><h4><a class="toc-backref" href="#id43">SelectionDAG Optimization Phase: the DAG Combiner</a><a class="headerlink" href="#selectiondag-optimization-phase-the-dag-combiner" title="Permalink to this headline">¶</a></h4>
+<p>The SelectionDAG optimization phase is run multiple times for code generation,
+immediately after the DAG is built and once after each legalization. The first
+run of the pass allows the initial code to be cleaned up (e.g. performing
+optimizations that depend on knowing that the operators have restricted type
+inputs). Subsequent runs of the pass clean up the messy code generated by the
+Legalize passes, which allows Legalize to be very simple (it can focus on making
+code legal instead of focusing on generating <em>good</em> and legal code).</p>
+<p>One important class of optimizations performed is optimizing inserted sign and
+zero extension instructions. We currently use ad-hoc techniques, but could move
+to more rigorous techniques in the future. Here are some good papers on the
+subject:</p>
+<p>“<a class="reference external" href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening integer arithmetic</a>” <span class="raw-html"><br></span>
+Kevin Redwine and Norman Ramsey <span class="raw-html"><br></span>
+International Conference on Compiler Construction (CC) 2004</p>
+<p>“<a class="reference external" href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective sign extension elimination</a>” <span class="raw-html"><br></span>
+Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani <span class="raw-html"><br></span>
+Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+and Implementation.</p>
+</div>
+<div class="section" id="selectiondag-select-phase">
+<span id="select-instructions-from-dag"></span><h4><a class="toc-backref" href="#id44">SelectionDAG Select Phase</a><a class="headerlink" href="#selectiondag-select-phase" title="Permalink to this headline">¶</a></h4>
+<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 the
+instructions supported by the target to this DAG, and produces a new DAG of
+target code. For example, consider the following LLVM fragment:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="nv">%t1</span> <span class="p">=</span> <span class="k">fadd</span> <span class="kt">float</span> <span class="nv">%W</span><span class="p">,</span> <span class="nv">%X</span>
+<span class="nv">%t2</span> <span class="p">=</span> <span class="k">fmul</span> <span class="kt">float</span> <span class="nv">%t1</span><span class="p">,</span> <span class="nv">%Y</span>
+<span class="nv">%t3</span> <span class="p">=</span> <span class="k">fadd</span> <span class="kt">float</span> <span class="nv">%t2</span><span class="p">,</span> <span class="nv">%Z</span>
+</pre></div>
+</div>
+<p>This LLVM code corresponds to a SelectionDAG that looks basically like this:</p>
+<div class="highlight-text"><div class="highlight"><pre>(fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+</pre></div>
+</div>
+<p>If a target supports floating point multiply-and-add (FMA) operations, one of
+the adds can be merged with the multiply. On the PowerPC, for example, the
+output of the instruction selector might look like this DAG:</p>
+<div class="highlight-python"><pre>(FMADDS (FADDS W, X), Y, Z)</pre>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">FMADDS</span></tt> instruction is a ternary instruction that multiplies its first
+two operands and adds the third (as single-precision floating-point numbers).
+The <tt class="docutils literal"><span class="pre">FADDS</span></tt> instruction is a simple binary single-precision add instruction.
+To perform this pattern match, the PowerPC backend includes the following
+instruction definitions:</p>
+<div class="highlight-text"><div class="highlight"><pre>def FMADDS : AForm_1<59, 29,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+ "fmadds $FRT, $FRA, $FRC, $FRB",
+<span class="hll"> [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+</span><span class="hll"> F4RC:$FRB))]>;
+</span>def FADDS : AForm_2<59, 21,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+ "fadds $FRT, $FRA, $FRB",
+<span class="hll"> [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
+</span></pre></div>
+</div>
+<p>The highlighted portion of the instruction definitions indicates the pattern
+used to match the instructions. The DAG operators (like <tt class="docutils literal"><span class="pre">fmul</span></tt>/<tt class="docutils literal"><span class="pre">fadd</span></tt>)
+are defined in the <tt class="docutils literal"><span class="pre">include/llvm/Target/TargetSelectionDAG.td</span></tt> file.
+“<tt class="docutils literal"><span class="pre">F4RC</span></tt>” is the register class of the input and result values.</p>
+<p>The TableGen DAG instruction selector generator reads the instruction patterns
+in the <tt class="docutils literal"><span class="pre">.td</span></tt> file and automatically builds parts of the pattern matching code
+for your target. It has the following strengths:</p>
+<ul>
+<li><p class="first">At compiler-compile time, it analyzes your instruction patterns and tells you
+if your patterns make sense or not.</p>
+</li>
+<li><p class="first">It can handle arbitrary constraints on operands for the pattern match. In
+particular, it is straight-forward to say things like “match any immediate
+that is a 13-bit sign-extended value”. For examples, see the <tt class="docutils literal"><span class="pre">immSExt16</span></tt>
+and related <tt class="docutils literal"><span class="pre">tblgen</span></tt> classes in the PowerPC backend.</p>
+</li>
+<li><p class="first">It knows several important identities for the patterns defined. For example,
+it knows that addition is commutative, so it allows the <tt class="docutils literal"><span class="pre">FMADDS</span></tt> pattern
+above to match “<tt class="docutils literal"><span class="pre">(fadd</span> <span class="pre">X,</span> <span class="pre">(fmul</span> <span class="pre">Y,</span> <span class="pre">Z))</span></tt>” as well as “<tt class="docutils literal"><span class="pre">(fadd</span> <span class="pre">(fmul</span> <span class="pre">X,</span> <span class="pre">Y),</span>
+<span class="pre">Z)</span></tt>”, without the target author having to specially handle this case.</p>
+</li>
+<li><p class="first">It has a full-featured type-inferencing system. In particular, you should
+rarely have to explicitly tell the system what type parts of your patterns
+are. In the <tt class="docutils literal"><span class="pre">FMADDS</span></tt> case above, we didn’t have to tell <tt class="docutils literal"><span class="pre">tblgen</span></tt> that all
+of the nodes in the pattern are of type ‘f32’. It was able to infer and
+propagate this knowledge from the fact that <tt class="docutils literal"><span class="pre">F4RC</span></tt> has type ‘f32’.</p>
+</li>
+<li><p class="first">Targets can define their own (and rely on built-in) “pattern fragments”.
+Pattern fragments are chunks of reusable patterns that get inlined into your
+patterns during compiler-compile time. For example, the integer “<tt class="docutils literal"><span class="pre">(not</span>
+<span class="pre">x)</span></tt>” operation is actually defined as a pattern fragment that expands as
+“<tt class="docutils literal"><span class="pre">(xor</span> <span class="pre">x,</span> <span class="pre">-1)</span></tt>”, since the SelectionDAG does not have a native ‘<tt class="docutils literal"><span class="pre">not</span></tt>‘
+operation. Targets can define their own short-hand fragments as they see fit.
+See the definition of ‘<tt class="docutils literal"><span class="pre">not</span></tt>‘ and ‘<tt class="docutils literal"><span class="pre">ineg</span></tt>‘ for examples.</p>
+</li>
+<li><p class="first">In addition to instructions, targets can specify arbitrary patterns that map
+to one or more instructions using the ‘Pat’ class. For example, the PowerPC
+has no way to load an arbitrary integer immediate into a register in one
+instruction. To tell tblgen how to do this, it defines:</p>
+<div class="highlight-python"><pre>// Arbitrary immediate support. Implement in terms of LIS/ORI.
+def : Pat<(i32 imm:$imm),
+ (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;</pre>
+</div>
+<p>If none of the single-instruction patterns for loading an immediate into a
+register match, this will be used. This rule says “match an arbitrary i32
+immediate, turning it into an <tt class="docutils literal"><span class="pre">ORI</span></tt> (‘or a 16-bit immediate’) and an <tt class="docutils literal"><span class="pre">LIS</span></tt>
+(‘load 16-bit immediate, where the immediate is shifted to the left 16 bits’)
+instruction”. To make this work, the <tt class="docutils literal"><span class="pre">LO16</span></tt>/<tt class="docutils literal"><span class="pre">HI16</span></tt> node transformations
+are used to manipulate the input immediate (in this case, take the high or low
+16-bits of the immediate).</p>
+</li>
+<li><p class="first">When using the ‘Pat’ class to map a pattern to an instruction that has one
+or more complex operands (like e.g. <a class="reference internal" href="#x86-addressing-mode">X86 addressing mode</a>), the pattern may
+either specify the operand as a whole using a <tt class="docutils literal"><span class="pre">ComplexPattern</span></tt>, or else it
+may specify the components of the complex operand separately. The latter is
+done e.g. for pre-increment instructions by the PowerPC back end:</p>
+<div class="highlight-python"><pre>def STWU : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
+ "stwu $rS, $dst", LdStStoreUpd, []>,
+ RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;
+
+def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
+ (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;</pre>
+</div>
+<p>Here, the pair of <tt class="docutils literal"><span class="pre">ptroff</span></tt> and <tt class="docutils literal"><span class="pre">ptrreg</span></tt> operands is matched onto the
+complex operand <tt class="docutils literal"><span class="pre">dst</span></tt> of class <tt class="docutils literal"><span class="pre">memri</span></tt> in the <tt class="docutils literal"><span class="pre">STWU</span></tt> instruction.</p>
+</li>
+<li><p class="first">While the system does automate a lot, it still allows you to write custom C++
+code to match special cases if there is something that is hard to
+express.</p>
+</li>
+</ul>
+<p>While it has many strengths, the system currently has some limitations,
+primarily because it is a work in progress and is not yet finished:</p>
+<ul class="simple">
+<li>Overall, there is no way to define or match SelectionDAG nodes that define
+multiple values (e.g. <tt class="docutils literal"><span class="pre">SMUL_LOHI</span></tt>, <tt class="docutils literal"><span class="pre">LOAD</span></tt>, <tt class="docutils literal"><span class="pre">CALL</span></tt>, etc). This is the
+biggest reason that you currently still <em>have to</em> write custom C++ code
+for your instruction selector.</li>
+<li>There is no great way to support matching complex addressing modes yet. In
+the future, we will extend pattern fragments to allow them to define multiple
+values (e.g. the four operands of the <a class="reference internal" href="#x86-addressing-mode">X86 addressing mode</a>, which are
+currently matched with custom C++ code). In addition, we’ll extend fragments
+so that a fragment can match multiple different patterns.</li>
+<li>We don’t automatically infer flags like <tt class="docutils literal"><span class="pre">isStore</span></tt>/<tt class="docutils literal"><span class="pre">isLoad</span></tt> yet.</li>
+<li>We don’t automatically generate the set of supported registers and operations
+for the <a class="reference internal" href="#legalizer">Legalizer</a> yet.</li>
+<li>We don’t have a way of tying in custom legalized nodes yet.</li>
+</ul>
+<p>Despite these limitations, the instruction selector generator is still quite
+useful for most of the binary and logical operations in typical instruction
+sets. If you run into any problems or can’t figure out how to do something,
+please let Chris know!</p>
+</div>
+<div class="section" id="selectiondag-scheduling-and-formation-phase">
+<span id="selectiondag-scheduling-and-formation"></span><span id="scheduling-and-formation"></span><h4><a class="toc-backref" href="#id45">SelectionDAG Scheduling and Formation Phase</a><a class="headerlink" href="#selectiondag-scheduling-and-formation-phase" title="Permalink to this headline">¶</a></h4>
+<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
+various constraints of the machines (i.e. order for minimal register pressure or
+try to cover instruction latencies). Once an order is established, the DAG is
+converted to a list of <span class="raw-html"><tt></span> <a class="reference internal" href="#machineinstr">MachineInstr</a>s <span class="raw-html"></tt></span> and
+the SelectionDAG is destroyed.</p>
+<p>Note that this phase is logically separate from the instruction selection phase,
+but is tied to it closely in the code because it operates on SelectionDAGs.</p>
+</div>
+<div class="section" id="future-directions-for-the-selectiondag">
+<h4><a class="toc-backref" href="#id46">Future directions for the SelectionDAG</a><a class="headerlink" href="#future-directions-for-the-selectiondag" title="Permalink to this headline">¶</a></h4>
+<ol class="arabic simple">
+<li>Optional function-at-a-time selection.</li>
+<li>Auto-generate entire selector from <tt class="docutils literal"><span class="pre">.td</span></tt> file.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="ssa-based-machine-code-optimizations">
+<span id="id2"></span><h3><a class="toc-backref" href="#id47">SSA-based Machine Code Optimizations</a><a class="headerlink" href="#ssa-based-machine-code-optimizations" title="Permalink to this headline">¶</a></h3>
+<p>To Be Written</p>
+</div>
+<div class="section" id="live-intervals">
+<h3><a class="toc-backref" href="#id48">Live Intervals</a><a class="headerlink" href="#live-intervals" title="Permalink to this headline">¶</a></h3>
+<p>Live Intervals are the ranges (intervals) where a variable is <em>live</em>. They are
+used by some <a class="reference internal" href="#register-allocator">register allocator</a> passes to determine if two or more virtual
+registers which require the same physical register are live at the same point in
+the program (i.e., they conflict). When this situation occurs, one virtual
+register must be <em>spilled</em>.</p>
+<div class="section" id="live-variable-analysis">
+<h4><a class="toc-backref" href="#id49">Live Variable Analysis</a><a class="headerlink" href="#live-variable-analysis" title="Permalink to this headline">¶</a></h4>
+<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., the
+instruction calculates the value, but it is never used) and the set of registers
+that are used by the instruction, but are never used after the instruction
+(i.e., they are killed). Live variable information is computed for
+each <em>virtual</em> register and <em>register allocatable</em> physical register
+in the function. This is done in a very efficient manner because it uses SSA to
+sparsely compute lifetime information for virtual registers (which are in SSA
+form) and only has to track physical registers within a block. Before register
+allocation, LLVM can assume that physical registers are only live within a
+single basic block. This allows it to do a single, local analysis to resolve
+physical register lifetimes within each basic block. If a physical register is
+not register allocatable (e.g., a stack pointer or condition codes), it is not
+tracked.</p>
+<p>Physical registers may be live in to or out of a function. Live in values are
+typically arguments in registers. Live out values are typically return values in
+registers. Live in values are marked as such, and are given a dummy “defining”
+instruction during live intervals analysis. If the last basic block of a
+function is a <tt class="docutils literal"><span class="pre">return</span></tt>, then it’s marked as using all live out values in the
+function.</p>
+<p><tt class="docutils literal"><span class="pre">PHI</span></tt> nodes need to be handled specially, because the calculation of the live
+variable information from a depth first traversal of the CFG of the function
+won’t guarantee that a virtual register used by the <tt class="docutils literal"><span class="pre">PHI</span></tt> node is defined
+before it’s used. When a <tt class="docutils literal"><span class="pre">PHI</span></tt> node is encountered, only the definition is
+handled, because the uses will be handled in other basic blocks.</p>
+<p>For each <tt class="docutils literal"><span class="pre">PHI</span></tt> node of the current basic block, we simulate an assignment at
+the end of the current basic block and traverse the successor basic blocks. If a
+successor basic block has a <tt class="docutils literal"><span class="pre">PHI</span></tt> node and one of the <tt class="docutils literal"><span class="pre">PHI</span></tt> node’s operands
+is coming from the current basic block, then the variable is marked as <em>alive</em>
+within the current basic block and all of its predecessor basic blocks, until
+the basic block with the defining instruction is encountered.</p>
+</div>
+<div class="section" id="live-intervals-analysis">
+<h4><a class="toc-backref" href="#id50">Live Intervals Analysis</a><a class="headerlink" href="#live-intervals-analysis" title="Permalink to this headline">¶</a></h4>
+<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 blocks
+and machine instructions. We then handle the “live-in” values. These are in
+physical registers, so the physical register is assumed to be killed by the end
+of the basic block. Live intervals for virtual registers are computed for some
+ordering of the machine instructions <tt class="docutils literal"><span class="pre">[1,</span> <span class="pre">N]</span></tt>. A live interval is an interval
+<tt class="docutils literal"><span class="pre">[i,</span> <span class="pre">j)</span></tt>, where <tt class="docutils literal"><span class="pre">1</span> <span class="pre">>=</span> <span class="pre">i</span> <span class="pre">>=</span> <span class="pre">j</span> <span class="pre">></span> <span class="pre">N</span></tt>, for which a variable is live.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">More to come...</p>
+</div>
+</div>
+</div>
+<div class="section" id="register-allocator">
+<span id="register-allocation"></span><span id="id3"></span><h3><a class="toc-backref" href="#id51">Register Allocation</a><a class="headerlink" href="#register-allocator" title="Permalink to this headline">¶</a></h3>
+<p>The <em>Register Allocation problem</em> consists in mapping a program
+<span class="raw-html"><b><tt></span> P<sub>v</sub><span class="raw-html"></tt></b></span>, that can use an unbounded
+number of virtual registers, to a program <span class="raw-html"><b><tt></span> P<sub>p</sub><span class="raw-html"></tt></b></span> that contains a finite (possibly small) number of physical
+registers. Each target architecture has a different number of physical
+registers. If the number of physical registers is not enough to accommodate all
+the virtual registers, some of them will have to be mapped into memory. These
+virtuals are called <em>spilled virtuals</em>.</p>
+<div class="section" id="how-registers-are-represented-in-llvm">
+<h4><a class="toc-backref" href="#id52">How registers are represented in LLVM</a><a class="headerlink" href="#how-registers-are-represented-in-llvm" title="Permalink to this headline">¶</a></h4>
+<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
+architecture, you can read the <tt class="docutils literal"><span class="pre">GenRegisterNames.inc</span></tt> file for that
+architecture. For instance, by inspecting
+<tt class="docutils literal"><span class="pre">lib/Target/X86/X86GenRegisterInfo.inc</span></tt> we see that the 32-bit register
+<tt class="docutils literal"><span class="pre">EAX</span></tt> is denoted by 43, and the MMX register <tt class="docutils literal"><span class="pre">MM0</span></tt> is mapped to 65.</p>
+<p>Some architectures contain registers that share the same physical location. A
+notable example is the X86 platform. For instance, in the X86 architecture, the
+registers <tt class="docutils literal"><span class="pre">EAX</span></tt>, <tt class="docutils literal"><span class="pre">AX</span></tt> and <tt class="docutils literal"><span class="pre">AL</span></tt> share the first eight bits. These physical
+registers are marked as <em>aliased</em> in LLVM. Given a particular architecture, you
+can check which registers are aliased by inspecting its <tt class="docutils literal"><span class="pre">RegisterInfo.td</span></tt>
+file. Moreover, the class <tt class="docutils literal"><span class="pre">MCRegAliasIterator</span></tt> enumerates all the physical
+registers aliased to a register.</p>
+<p>Physical registers, in LLVM, are grouped in <em>Register Classes</em>. Elements in the
+same register class are functionally equivalent, and can be interchangeably
+used. Each virtual register can only be mapped to physical registers of a
+particular class. For instance, in the X86 architecture, some virtuals can only
+be allocated to 8 bit registers. A register class is described by
+<tt class="docutils literal"><span class="pre">TargetRegisterClass</span></tt> objects. To discover if a virtual register is
+compatible with a given physical, this code can be used:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">bool</span> <span class="n">RegMapping_Fer</span><span class="o">::</span><span class="n">compatible_class</span><span class="p">(</span><span class="n">MachineFunction</span> <span class="o">&</span><span class="n">mf</span><span class="p">,</span>
+ <span class="kt">unsigned</span> <span class="n">v_reg</span><span class="p">,</span>
+ <span class="kt">unsigned</span> <span class="n">p_reg</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">TargetRegisterInfo</span><span class="o">::</span><span class="n">isPhysicalRegister</span><span class="p">(</span><span class="n">p_reg</span><span class="p">)</span> <span class="o">&&</span>
+ <span class="s">"Target register must be physical"</span><span class="p">);</span>
+ <span class="k">const</span> <span class="n">TargetRegisterClass</span> <span class="o">*</span><span class="n">trc</span> <span class="o">=</span> <span class="n">mf</span><span class="p">.</span><span class="n">getRegInfo</span><span class="p">().</span><span class="n">getRegClass</span><span class="p">(</span><span class="n">v_reg</span><span class="p">);</span>
+ <span class="k">return</span> <span class="n">trc</span><span class="o">-></span><span class="n">contains</span><span class="p">(</span><span class="n">p_reg</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Sometimes, mostly for debugging purposes, it is useful to change the number of
+physical registers available in the target architecture. This must be done
+statically, inside the <tt class="docutils literal"><span class="pre">TargetRegsterInfo.td</span></tt> file. Just <tt class="docutils literal"><span class="pre">grep</span></tt> for
+<tt class="docutils literal"><span class="pre">RegisterClass</span></tt>, the last parameter of which is a list of registers. Just
+commenting some out is one simple way to avoid them being used. A more polite
+way is to explicitly exclude some registers from the <em>allocation order</em>. See the
+definition of the <tt class="docutils literal"><span class="pre">GR8</span></tt> register class in
+<tt class="docutils literal"><span class="pre">lib/Target/X86/X86RegisterInfo.td</span></tt> for an example of this.</p>
+<p>Virtual registers are also denoted by integer numbers. Contrary to physical
+registers, different virtual registers never share the same number. Whereas
+physical registers are statically defined in a <tt class="docutils literal"><span class="pre">TargetRegisterInfo.td</span></tt> file
+and cannot be created by the application developer, that is not the case with
+virtual registers. In order to create new virtual registers, use the method
+<tt class="docutils literal"><span class="pre">MachineRegisterInfo::createVirtualRegister()</span></tt>. This method will return a new
+virtual register. Use an <tt class="docutils literal"><span class="pre">IndexedMap<Foo,</span> <span class="pre">VirtReg2IndexFunctor></span></tt> to hold
+information per virtual register. If you need to enumerate all virtual
+registers, use the function <tt class="docutils literal"><span class="pre">TargetRegisterInfo::index2VirtReg()</span></tt> to find the
+virtual register numbers:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">e</span> <span class="o">=</span> <span class="n">MRI</span><span class="o">-></span><span class="n">getNumVirtRegs</span><span class="p">();</span> <span class="n">i</span> <span class="o">!=</span> <span class="n">e</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kt">unsigned</span> <span class="n">VirtReg</span> <span class="o">=</span> <span class="n">TargetRegisterInfo</span><span class="o">::</span><span class="n">index2VirtReg</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="n">stuff</span><span class="p">(</span><span class="n">VirtReg</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Before register allocation, the operands of an instruction are mostly virtual
+registers, although physical registers may also be used. In order to check if a
+given machine operand is a register, use the boolean function
+<tt class="docutils literal"><span class="pre">MachineOperand::isRegister()</span></tt>. To obtain the integer code of a register, use
+<tt class="docutils literal"><span class="pre">MachineOperand::getReg()</span></tt>. An instruction may define or use a register. For
+instance, <tt class="docutils literal"><span class="pre">ADD</span> <span class="pre">reg:1026</span> <span class="pre">:=</span> <span class="pre">reg:1025</span> <span class="pre">reg:1024</span></tt> defines the registers 1024, and
+uses registers 1025 and 1026. Given a register operand, the method
+<tt class="docutils literal"><span class="pre">MachineOperand::isUse()</span></tt> informs if that register is being used by the
+instruction. The method <tt class="docutils literal"><span class="pre">MachineOperand::isDef()</span></tt> informs if that registers is
+being defined.</p>
+<p>We will call physical registers present in the LLVM bitcode before register
+allocation <em>pre-colored registers</em>. Pre-colored registers are used in many
+different situations, for instance, to pass parameters of functions calls, and
+to store results of particular instructions. There are two types of pre-colored
+registers: the ones <em>implicitly</em> defined, and those <em>explicitly</em>
+defined. Explicitly defined registers are normal operands, and can be accessed
+with <tt class="docutils literal"><span class="pre">MachineInstr::getOperand(int)::getReg()</span></tt>. In order to check which
+registers are implicitly defined by an instruction, use the
+<tt class="docutils literal"><span class="pre">TargetInstrInfo::get(opcode)::ImplicitDefs</span></tt>, where <tt class="docutils literal"><span class="pre">opcode</span></tt> is the opcode
+of the target instruction. One important difference between explicit and
+implicit physical registers is that the latter are defined statically for each
+instruction, whereas the former may vary depending on the program being
+compiled. For example, an instruction that represents a function call will
+always implicitly define or use the same set of physical registers. To read the
+registers implicitly used by an instruction, use
+<tt class="docutils literal"><span class="pre">TargetInstrInfo::get(opcode)::ImplicitUses</span></tt>. Pre-colored registers impose
+constraints on any register allocation algorithm. The register allocator must
+make sure that none of them are overwritten by the values of virtual registers
+while still alive.</p>
+</div>
+<div class="section" id="mapping-virtual-registers-to-physical-registers">
+<h4><a class="toc-backref" href="#id53">Mapping virtual registers to physical registers</a><a class="headerlink" href="#mapping-virtual-registers-to-physical-registers" title="Permalink to this headline">¶</a></h4>
+<p>There are two ways to map virtual registers to physical registers (or to memory
+slots). The first way, that we will call <em>direct mapping</em>, is based on the use
+of methods of the classes <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt>, and <tt class="docutils literal"><span class="pre">MachineOperand</span></tt>. The
+second way, that we will call <em>indirect mapping</em>, relies on the <tt class="docutils literal"><span class="pre">VirtRegMap</span></tt>
+class in order to insert loads and stores sending and getting values to and from
+memory.</p>
+<p>The direct mapping provides more flexibility to the developer of the register
+allocator; however, it is more error prone, and demands more implementation
+work. Basically, the programmer will have to specify where load and store
+instructions should be inserted in the target function being compiled in order
+to get and store values in memory. To assign a physical register to a virtual
+register present in a given operand, use <tt class="docutils literal"><span class="pre">MachineOperand::setReg(p_reg)</span></tt>. To
+insert a store instruction, use <tt class="docutils literal"><span class="pre">TargetInstrInfo::storeRegToStackSlot(...)</span></tt>,
+and to insert a load instruction, use <tt class="docutils literal"><span class="pre">TargetInstrInfo::loadRegFromStackSlot</span></tt>.</p>
+<p>The indirect mapping shields the application developer from the complexities of
+inserting load and store instructions. In order to map a virtual register to a
+physical one, use <tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2Phys(vreg,</span> <span class="pre">preg)</span></tt>. In order to map
+a certain virtual register to memory, use
+<tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2StackSlot(vreg)</span></tt>. This method will return the stack
+slot where <tt class="docutils literal"><span class="pre">vreg</span></tt>‘s value will be located. If it is necessary to map another
+virtual register to the same stack slot, use
+<tt class="docutils literal"><span class="pre">VirtRegMap::assignVirt2StackSlot(vreg,</span> <span class="pre">stack_location)</span></tt>. One important point
+to consider when using the indirect mapping, is that even if a virtual register
+is mapped to memory, it still needs to be mapped to a physical register. This
+physical register is the location where the virtual register is supposed to be
+found before being stored or after being reloaded.</p>
+<p>If the indirect strategy is used, after all the virtual registers have been
+mapped to physical registers or stack slots, it is necessary to use a spiller
+object to place load and store instructions in the code. Every virtual that has
+been mapped to a stack slot will be stored to memory after being defined and will
+be loaded before being used. The implementation of the spiller tries to recycle
+load/store instructions, avoiding unnecessary instructions. For an example of
+how to invoke the spiller, see <tt class="docutils literal"><span class="pre">RegAllocLinearScan::runOnMachineFunction</span></tt> in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/RegAllocLinearScan.cpp</span></tt>.</p>
+</div>
+<div class="section" id="handling-two-address-instructions">
+<h4><a class="toc-backref" href="#id54">Handling two address instructions</a><a class="headerlink" href="#handling-two-address-instructions" title="Permalink to this headline">¶</a></h4>
+<p>With very rare exceptions (e.g., function calls), the LLVM machine code
+instructions are three address instructions. That is, each instruction is
+expected to define at most one register, and to use at most two registers.
+However, some architectures use two address instructions. In this case, the
+defined register is also one of the used registers. For instance, an instruction
+such as <tt class="docutils literal"><span class="pre">ADD</span> <span class="pre">%EAX,</span> <span class="pre">%EBX</span></tt>, in X86 is actually equivalent to <tt class="docutils literal"><span class="pre">%EAX</span> <span class="pre">=</span> <span class="pre">%EAX</span> <span class="pre">+</span>
+<span class="pre">%EBX</span></tt>.</p>
+<p>In order to produce correct code, LLVM must convert three address instructions
+that represent two address instructions into true two address instructions. LLVM
+provides the pass <tt class="docutils literal"><span class="pre">TwoAddressInstructionPass</span></tt> for this specific purpose. It
+must be run before register allocation takes place. After its execution, the
+resulting code may no longer be in SSA form. This happens, for instance, in
+situations where an instruction such as <tt class="docutils literal"><span class="pre">%a</span> <span class="pre">=</span> <span class="pre">ADD</span> <span class="pre">%b</span> <span class="pre">%c</span></tt> is converted to two
+instructions such as:</p>
+<div class="highlight-python"><pre>%a = MOVE %b
+%a = ADD %a %c</pre>
+</div>
+<p>Notice that, internally, the second instruction is represented as <tt class="docutils literal"><span class="pre">ADD</span>
+<span class="pre">%a[def/use]</span> <span class="pre">%c</span></tt>. I.e., the register operand <tt class="docutils literal"><span class="pre">%a</span></tt> is both used and defined by
+the instruction.</p>
+</div>
+<div class="section" id="the-ssa-deconstruction-phase">
+<h4><a class="toc-backref" href="#id55">The SSA deconstruction phase</a><a class="headerlink" href="#the-ssa-deconstruction-phase" title="Permalink to this headline">¶</a></h4>
+<p>An important transformation that happens during register allocation is called
+the <em>SSA Deconstruction Phase</em>. The SSA form simplifies many analyses that are
+performed on the control flow graph of programs. However, traditional
+instruction sets do not implement PHI instructions. Thus, in order to generate
+executable code, compilers must replace PHI instructions with other instructions
+that preserve their semantics.</p>
+<p>There are many ways in which PHI instructions can safely be removed from the
+target code. The most traditional PHI deconstruction algorithm replaces PHI
+instructions with copy instructions. That is the strategy adopted by LLVM. The
+SSA deconstruction algorithm is implemented in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/PHIElimination.cpp</span></tt>. In order to invoke this pass, the identifier
+<tt class="docutils literal"><span class="pre">PHIEliminationID</span></tt> must be marked as required in the code of the register
+allocator.</p>
+</div>
+<div class="section" id="instruction-folding">
+<h4><a class="toc-backref" href="#id56">Instruction folding</a><a class="headerlink" href="#instruction-folding" title="Permalink to this headline">¶</a></h4>
+<p><em>Instruction folding</em> is an optimization performed during register allocation
+that removes unnecessary copy instructions. For instance, a sequence of
+instructions such as:</p>
+<div class="highlight-python"><pre>%EBX = LOAD %mem_address
+%EAX = COPY %EBX</pre>
+</div>
+<p>can be safely substituted by the single instruction:</p>
+<div class="highlight-python"><pre>%EAX = LOAD %mem_address</pre>
+</div>
+<p>Instructions can be folded with the
+<tt class="docutils literal"><span class="pre">TargetRegisterInfo::foldMemoryOperand(...)</span></tt> method. Care must be taken when
+folding instructions; a folded instruction can be quite different from the
+original instruction. See <tt class="docutils literal"><span class="pre">LiveIntervals::addIntervalsForSpills</span></tt> in
+<tt class="docutils literal"><span class="pre">lib/CodeGen/LiveIntervalAnalysis.cpp</span></tt> for an example of its use.</p>
+</div>
+<div class="section" id="built-in-register-allocators">
+<h4><a class="toc-backref" href="#id57">Built in register allocators</a><a class="headerlink" href="#built-in-register-allocators" title="Permalink to this headline">¶</a></h4>
+<p>The LLVM infrastructure provides the application developer with three different
+register allocators:</p>
+<ul class="simple">
+<li><em>Fast</em> — This register allocator is the default for debug builds. It
+allocates registers on a basic block level, attempting to keep values in
+registers and reusing registers as appropriate.</li>
+<li><em>Basic</em> — This is an incremental approach to register allocation. Live
+ranges are assigned to registers one at a time in an order that is driven by
+heuristics. Since code can be rewritten on-the-fly during allocation, this
+framework allows interesting allocators to be developed as extensions. It is
+not itself a production register allocator but is a potentially useful
+stand-alone mode for triaging bugs and as a performance baseline.</li>
+<li><em>Greedy</em> — <em>The default allocator</em>. This is a highly tuned implementation of
+the <em>Basic</em> allocator that incorporates global live range splitting. This
+allocator works hard to minimize the cost of spill code.</li>
+<li><em>PBQP</em> — A Partitioned Boolean Quadratic Programming (PBQP) based register
+allocator. This allocator works by constructing a PBQP problem representing
+the register allocation problem under consideration, solving this using a PBQP
+solver, and mapping the solution back to a register assignment.</li>
+</ul>
+<p>The type of register allocator used in <tt class="docutils literal"><span class="pre">llc</span></tt> can be chosen with the command
+line option <tt class="docutils literal"><span class="pre">-regalloc=...</span></tt>:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llc -regalloc<span class="o">=</span>linearscan file.bc -o ln.s
+<span class="nv">$ </span>llc -regalloc<span class="o">=</span>fast file.bc -o fa.s
+<span class="nv">$ </span>llc -regalloc<span class="o">=</span>pbqp file.bc -o pbqp.s
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="prolog-epilog-code-insertion">
+<span id="id4"></span><h3><a class="toc-backref" href="#id58">Prolog/Epilog Code Insertion</a><a class="headerlink" href="#prolog-epilog-code-insertion" title="Permalink to this headline">¶</a></h3>
+<p>Compact Unwind</p>
+<p>Throwing an exception requires <em>unwinding</em> out of a function. The information on
+how to unwind a given function is traditionally expressed in DWARF unwind
+(a.k.a. frame) info. But that format was originally developed for debuggers to
+backtrace, and each Frame Description Entry (FDE) requires ~20-30 bytes per
+function. There is also the cost of mapping from an address in a function to the
+corresponding FDE at runtime. An alternative unwind encoding is called <em>compact
+unwind</em> and requires just 4-bytes per function.</p>
+<p>The compact unwind encoding is a 32-bit value, which is encoded in an
+architecture-specific way. It specifies which registers to restore and from
+where, and how to unwind out of the function. When the linker creates a final
+linked image, it will create a <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section. This section is
+a small and fast way for the runtime to access unwind info for any given
+function. If we emit compact unwind info for the function, that compact unwind
+info will be encoded in the <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section. If we emit DWARF
+unwind info, the <tt class="docutils literal"><span class="pre">__TEXT,__unwind_info</span></tt> section will contain the offset of the
+FDE in the <tt class="docutils literal"><span class="pre">__TEXT,__eh_frame</span></tt> section in the final linked image.</p>
+<p>For X86, there are three modes for the compact unwind encoding:</p>
+<dl class="docutils">
+<dt><em>Function with a Frame Pointer (``EBP`` or ``RBP``)</em></dt>
+<dd><p class="first"><tt class="docutils literal"><span class="pre">EBP/RBP</span></tt>-based frame, where <tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> is pushed onto the stack
+immediately after the return address, then <tt class="docutils literal"><span class="pre">ESP/RSP</span></tt> is moved to
+<tt class="docutils literal"><span class="pre">EBP/RBP</span></tt>. Thus to unwind, <tt class="docutils literal"><span class="pre">ESP/RSP</span></tt> is restored with the current
+<tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> value, then <tt class="docutils literal"><span class="pre">EBP/RBP</span></tt> is restored by popping the stack, and the
+return is done by popping the stack once more into the PC. All non-volatile
+registers that need to be restored must have been saved in a small range on
+the stack that starts <tt class="docutils literal"><span class="pre">EBP-4</span></tt> to <tt class="docutils literal"><span class="pre">EBP-1020</span></tt> (<tt class="docutils literal"><span class="pre">RBP-8</span></tt> to
+<tt class="docutils literal"><span class="pre">RBP-1020</span></tt>). The offset (divided by 4 in 32-bit mode and 8 in 64-bit mode)
+is encoded in bits 16-23 (mask: <tt class="docutils literal"><span class="pre">0x00FF0000</span></tt>). The registers saved are
+encoded in bits 0-14 (mask: <tt class="docutils literal"><span class="pre">0x00007FFF</span></tt>) as five 3-bit entries from the
+following table:</p>
+<blockquote class="last">
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="33%" />
+<col width="31%" />
+<col width="36%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Compact Number</th>
+<th class="head">i386 Register</th>
+<th class="head">x86-64 Register</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td><tt class="docutils literal"><span class="pre">EBX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">RBX</span></tt></td>
+</tr>
+<tr class="row-odd"><td>2</td>
+<td><tt class="docutils literal"><span class="pre">ECX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R12</span></tt></td>
+</tr>
+<tr class="row-even"><td>3</td>
+<td><tt class="docutils literal"><span class="pre">EDX</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R13</span></tt></td>
+</tr>
+<tr class="row-odd"><td>4</td>
+<td><tt class="docutils literal"><span class="pre">EDI</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R14</span></tt></td>
+</tr>
+<tr class="row-even"><td>5</td>
+<td><tt class="docutils literal"><span class="pre">ESI</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">R15</span></tt></td>
+</tr>
+<tr class="row-odd"><td>6</td>
+<td><tt class="docutils literal"><span class="pre">EBP</span></tt></td>
+<td><tt class="docutils literal"><span class="pre">RBP</span></tt></td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+</dd>
+<dt><em>Frameless with a Small Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)</em></dt>
+<dd>To return, a constant (encoded in the compact unwind encoding) is added to the
+<tt class="docutils literal"><span class="pre">ESP/RSP</span></tt>. Then the return is done by popping the stack into the PC. All
+non-volatile registers that need to be restored must have been saved on the
+stack immediately after the return address. The stack size (divided by 4 in
+32-bit mode and 8 in 64-bit mode) is encoded in bits 16-23 (mask:
+<tt class="docutils literal"><span class="pre">0x00FF0000</span></tt>). There is a maximum stack size of 1024 bytes in 32-bit mode
+and 2048 in 64-bit mode. The number of registers saved is encoded in bits 9-12
+(mask: <tt class="docutils literal"><span class="pre">0x00001C00</span></tt>). Bits 0-9 (mask: <tt class="docutils literal"><span class="pre">0x000003FF</span></tt>) contain which
+registers were saved and their order. (See the
+<tt class="docutils literal"><span class="pre">encodeCompactUnwindRegistersWithoutFrame()</span></tt> function in
+<tt class="docutils literal"><span class="pre">lib/Target/X86FrameLowering.cpp</span></tt> for the encoding algorithm.)</dd>
+<dt><em>Frameless with a Large Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)</em></dt>
+<dd>This case is like the “Frameless with a Small Constant Stack Size” case, but
+the stack size is too large to encode in the compact unwind encoding. Instead
+it requires that the function contains “<tt class="docutils literal"><span class="pre">subl</span> <span class="pre">$nnnnnn,</span> <span class="pre">%esp</span></tt>” in its
+prolog. The compact encoding contains the offset to the <tt class="docutils literal"><span class="pre">$nnnnnn</span></tt> value in
+the function in bits 9-12 (mask: <tt class="docutils literal"><span class="pre">0x00001C00</span></tt>).</dd>
+</dl>
+</div>
+<div class="section" id="late-machine-code-optimizations">
+<span id="id5"></span><h3><a class="toc-backref" href="#id59">Late Machine Code Optimizations</a><a class="headerlink" href="#late-machine-code-optimizations" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+<div class="section" id="code-emission">
+<span id="id6"></span><h3><a class="toc-backref" href="#id60">Code Emission</a><a class="headerlink" href="#code-emission" title="Permalink to this headline">¶</a></h3>
+<p>The code emission step of code generation is responsible for lowering from the
+code generator abstractions (like <a class="reference internal" href="#machinefunction">MachineFunction</a>, <a class="reference internal" href="#machineinstr">MachineInstr</a>, etc) down
+to the abstractions used by the MC layer (<a class="reference internal" href="#mcinst">MCInst</a>, <a class="reference internal" href="#mcstreamer">MCStreamer</a>, etc). This
+is done with a combination of several different classes: the (misnamed)
+target-independent AsmPrinter class, target-specific subclasses of AsmPrinter
+(such as SparcAsmPrinter), and the TargetLoweringObjectFile class.</p>
+<p>Since the MC layer works at the level of abstraction of object files, it doesn’t
+have a notion of functions, global variables etc. Instead, it thinks about
+labels, directives, and instructions. A key class used at this time is the
+MCStreamer class. This is an abstract API that is implemented in different ways
+(e.g. to output a .s file, output an ELF .o file, etc) that is effectively an
+“assembler API”. MCStreamer has one method per directive, such as EmitLabel,
+EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly
+level directives.</p>
+<p>If you are interested in implementing a code generator for a target, there are
+three important things that you have to implement for your target:</p>
+<ol class="arabic simple">
+<li>First, you need a subclass of AsmPrinter for your target. This class
+implements the general lowering process converting MachineFunction’s into MC
+label constructs. The AsmPrinter base class provides a number of useful
+methods and routines, and also allows you to override the lowering process in
+some important ways. You should get much of the lowering for free if you are
+implementing an ELF, COFF, or MachO target, because the
+TargetLoweringObjectFile class implements much of the common logic.</li>
+<li>Second, you need to implement an instruction printer for your target. The
+instruction printer takes an <a class="reference internal" href="#mcinst">MCInst</a> and renders it to a raw_ostream as
+text. Most of this is automatically generated from the .td file (when you
+specify something like “<tt class="docutils literal"><span class="pre">add</span> <span class="pre">$dst,</span> <span class="pre">$src1,</span> <span class="pre">$src2</span></tt>” in the instructions), but
+you need to implement routines to print operands.</li>
+<li>Third, you need to implement code that lowers a <a class="reference internal" href="#machineinstr">MachineInstr</a> to an MCInst,
+usually implemented in “<target>MCInstLower.cpp”. This lowering process is
+often target specific, and is responsible for turning jump table entries,
+constant pool indices, global variable addresses, etc into MCLabels as
+appropriate. This translation layer is also responsible for expanding pseudo
+ops used by the code generator into the actual machine instructions they
+correspond to. The MCInsts that are generated by this are fed into the
+instruction printer or the encoder.</li>
+</ol>
+<p>Finally, at your choosing, you can also implement a subclass of MCCodeEmitter
+which lowers MCInst’s into machine code bytes and relocations. This is
+important if you want to support direct .o file emission, or would like to
+implement an assembler for your target.</p>
+<div class="section" id="emitting-function-stack-size-information">
+<h4><a class="toc-backref" href="#id61">Emitting function stack size information</a><a class="headerlink" href="#emitting-function-stack-size-information" title="Permalink to this headline">¶</a></h4>
+<p>A section containing metadata on function stack sizes will be emitted when
+<tt class="docutils literal"><span class="pre">TargetLoweringObjectFile::StackSizesSection</span></tt> is not null, and
+<tt class="docutils literal"><span class="pre">TargetOptions::EmitStackSizeSection</span></tt> is set (-stack-size-section). The
+section will contain an array of pairs of function symbol values (pointer size)
+and stack sizes (unsigned LEB128). The stack size values only include the space
+allocated in the function prologue. Functions with dynamic stack allocations are
+not included.</p>
+</div>
+</div>
+<div class="section" id="vliw-packetizer">
+<h3><a class="toc-backref" href="#id62">VLIW Packetizer</a><a class="headerlink" href="#vliw-packetizer" title="Permalink to this headline">¶</a></h3>
+<p>In a Very Long Instruction Word (VLIW) architecture, the compiler is responsible
+for mapping instructions to functional-units available on the architecture. To
+that end, the compiler creates groups of instructions called <em>packets</em> or
+<em>bundles</em>. The VLIW packetizer in LLVM is a target-independent mechanism to
+enable the packetization of machine instructions.</p>
+<div class="section" id="mapping-from-instructions-to-functional-units">
+<h4><a class="toc-backref" href="#id63">Mapping from instructions to functional units</a><a class="headerlink" href="#mapping-from-instructions-to-functional-units" title="Permalink to this headline">¶</a></h4>
+<p>Instructions in a VLIW target can typically be mapped to multiple functional
+units. During the process of packetizing, the compiler must be able to reason
+about whether an instruction can be added to a packet. This decision can be
+complex since the compiler has to examine all possible mappings of instructions
+to functional units. Therefore to alleviate compilation-time complexity, the
+VLIW packetizer parses the instruction classes of a target and generates tables
+at compiler build time. These tables can then be queried by the provided
+machine-independent API to determine if an instruction can be accommodated in a
+packet.</p>
+</div>
+<div class="section" id="how-the-packetization-tables-are-generated-and-used">
+<h4><a class="toc-backref" href="#id64">How the packetization tables are generated and used</a><a class="headerlink" href="#how-the-packetization-tables-are-generated-and-used" title="Permalink to this headline">¶</a></h4>
+<p>The packetizer reads instruction classes from a target’s itineraries and creates
+a deterministic finite automaton (DFA) to represent the state of a packet. A DFA
+consists of three major elements: inputs, states, and transitions. The set of
+inputs for the generated DFA represents the instruction being added to a
+packet. The states represent the possible consumption of functional units by
+instructions in a packet. In the DFA, transitions from one state to another
+occur on the addition of an instruction to an existing packet. If there is a
+legal mapping of functional units to instructions, then the DFA contains a
+corresponding transition. The absence of a transition indicates that a legal
+mapping does not exist and that the instruction cannot be added to the packet.</p>
+<p>To generate tables for a VLIW target, add <em>Target</em>GenDFAPacketizer.inc as a
+target to the Makefile in the target directory. The exported API provides three
+functions: <tt class="docutils literal"><span class="pre">DFAPacketizer::clearResources()</span></tt>,
+<tt class="docutils literal"><span class="pre">DFAPacketizer::reserveResources(MachineInstr</span> <span class="pre">*MI)</span></tt>, and
+<tt class="docutils literal"><span class="pre">DFAPacketizer::canReserveResources(MachineInstr</span> <span class="pre">*MI)</span></tt>. These functions allow
+a target packetizer to add an instruction to an existing packet and to check
+whether an instruction can be added to a packet. See
+<tt class="docutils literal"><span class="pre">llvm/CodeGen/DFAPacketizer.h</span></tt> for more information.</p>
+</div>
+</div>
+</div>
+<div class="section" id="implementing-a-native-assembler">
+<h2><a class="toc-backref" href="#id65">Implementing a Native Assembler</a><a class="headerlink" href="#implementing-a-native-assembler" title="Permalink to this headline">¶</a></h2>
+<p>Though you’re probably reading this because you want to write or maintain a
+compiler backend, LLVM also fully supports building a native assembler.
+We’ve tried hard to automate the generation of the assembler from the .td files
+(in particular the instruction syntax and encodings), which means that a large
+part of the manual and repetitive data entry can be factored and shared with the
+compiler.</p>
+<div class="section" id="instruction-parsing">
+<h3><a class="toc-backref" href="#id66">Instruction Parsing</a><a class="headerlink" href="#instruction-parsing" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+<div class="section" id="instruction-alias-processing">
+<h3><a class="toc-backref" href="#id67">Instruction Alias Processing</a><a class="headerlink" href="#instruction-alias-processing" title="Permalink to this headline">¶</a></h3>
+<p>Once the instruction is parsed, it enters the MatchInstructionImpl function.
+The MatchInstructionImpl function performs alias processing and then does actual
+matching.</p>
+<p>Alias processing is the phase that canonicalizes different lexical forms of the
+same instructions down to one representation. There are several different kinds
+of alias that are possible to implement and they are listed below in the order
+that they are processed (which is in order from simplest/weakest to most
+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 class="section" id="mnemonic-aliases">
+<h4><a class="toc-backref" href="#id68">Mnemonic Aliases</a><a class="headerlink" href="#mnemonic-aliases" title="Permalink to this headline">¶</a></h4>
+<p>The first phase of alias processing is simple instruction mnemonic remapping for
+classes of instructions which are allowed with two different mnemonics. This
+phase is a simple and unconditionally remapping from one input mnemonic to one
+output mnemonic. It isn’t possible for this form of alias to look at the
+operands at all, so the remapping must apply for all forms of a given mnemonic.
+Mnemonic aliases are defined simply, for example X86 has:</p>
+<div class="highlight-python"><pre>def : MnemonicAlias<"cbw", "cbtw">;
+def : MnemonicAlias<"smovq", "movsq">;
+def : MnemonicAlias<"fldcww", "fldcw">;
+def : MnemonicAlias<"fucompi", "fucomip">;
+def : MnemonicAlias<"ud2a", "ud2">;</pre>
+</div>
+<p>... and many others. With a MnemonicAlias definition, the mnemonic is remapped
+simply and directly. Though MnemonicAlias’s can’t look at any aspect of the
+instruction (such as the operands) they can depend on global modes (the same
+ones supported by the matcher), through a Requires clause:</p>
+<div class="highlight-python"><pre>def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
+def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;</pre>
+</div>
+<p>In this example, the mnemonic gets mapped into a different one depending on
+the current instruction set.</p>
+</div>
+<div class="section" id="instruction-aliases">
+<h4><a class="toc-backref" href="#id69">Instruction Aliases</a><a class="headerlink" href="#instruction-aliases" title="Permalink to this headline">¶</a></h4>
+<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 instruction
+to generate. An instruction alias has two parts: the string to match and the
+instruction to generate. For example:</p>
+<div class="highlight-python"><pre>def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr8 GR32:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr8 GR64:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;</pre>
+</div>
+<p>This shows a powerful example of the instruction aliases, matching the same
+mnemonic in multiple different ways depending on what operands are present in
+the assembly. The result of instruction aliases can include operands in a
+different order than the destination instruction, and can use an input multiple
+times, for example:</p>
+<div class="highlight-python"><pre>def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>;
+def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
+def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
+def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;</pre>
+</div>
+<p>This example also shows that tied operands are only listed once. In the X86
+backend, XOR8rr has two input GR8’s and one output GR8 (where an input is tied
+to the output). InstAliases take a flattened operand list without duplicates
+for tied operands. The result of an instruction alias can also use immediates
+and fixed physical registers which are added as simple immediate operands in the
+result, for example:</p>
+<div class="highlight-python"><pre>// Fixed Immediate operand.
+def : InstAlias<"aad", (AAD8i8 10)>;
+
+// Fixed register operand.
+def : InstAlias<"fcomi", (COM_FIr ST1)>;
+
+// Simple alias.
+def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;</pre>
+</div>
+<p>Instruction aliases can also have a Requires clause to make them subtarget
+specific.</p>
+<p>If the back-end supports it, the instruction printer can automatically emit the
+alias rather than what’s being aliased. It typically leads to better, more
+readable code. If it’s better to print out what’s being aliased, then pass a ‘0’
+as the third parameter to the InstAlias definition.</p>
+</div>
+</div>
+<div class="section" id="instruction-matching">
+<h3><a class="toc-backref" href="#id70">Instruction Matching</a><a class="headerlink" href="#instruction-matching" title="Permalink to this headline">¶</a></h3>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">To Be Written</p>
+</div>
+</div>
+</div>
+<div class="section" id="target-specific-implementation-notes">
+<span id="implement-the-target-description"></span><span id="implementations-of-the-abstract-target-description-interfaces"></span><h2><a class="toc-backref" href="#id71">Target-specific Implementation Notes</a><a class="headerlink" href="#target-specific-implementation-notes" title="Permalink to this headline">¶</a></h2>
+<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 class="section" id="target-feature-matrix">
+<span id="id7"></span><h3><a class="toc-backref" href="#id72">Target Feature Matrix</a><a class="headerlink" href="#target-feature-matrix" title="Permalink to this headline">¶</a></h3>
+<p>Note that this table does not list features that are not supported fully by any
+target yet. It considers a feature to be supported if at least one subtarget
+supports it. A feature being supported means that it is useful and works for
+most cases, it does not indicate that there are zero known bugs in the
+implementation. Here is the key:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Unknown</th></span>
+<span class="raw-html"><th>Not Applicable</th></span>
+<span class="raw-html"><th>No support</th></span>
+<span class="raw-html"><th>Partial Support</th></span>
+<span class="raw-html"><th>Complete Support</th></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td class="unknown"></td></span>
+<span class="raw-html"><td class="na"></td></span>
+<span class="raw-html"><td class="no"></td></span>
+<span class="raw-html"><td class="partial"></td></span>
+<span class="raw-html"><td class="yes"></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>Here is the table:</p>
+<p><span class="raw-html"><table width="689" border="1" cellspacing="0"></span>
+<span class="raw-html"><tr><td></td></span>
+<span class="raw-html"><td colspan="13" align="center" style="background-color:#ffc">Target</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Feature</th></span>
+<span class="raw-html"><th>ARM</th></span>
+<span class="raw-html"><th>Hexagon</th></span>
+<span class="raw-html"><th>MSP430</th></span>
+<span class="raw-html"><th>Mips</th></span>
+<span class="raw-html"><th>NVPTX</th></span>
+<span class="raw-html"><th>PowerPC</th></span>
+<span class="raw-html"><th>Sparc</th></span>
+<span class="raw-html"><th>SystemZ</th></span>
+<span class="raw-html"><th>X86</th></span>
+<span class="raw-html"><th>XCore</th></span>
+<span class="raw-html"><th>eBPF</th></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_reliable">is generally reliable</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="yes"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="yes"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_asmparser">assembly parser</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="no"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_disassembler">disassembler</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="yes"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_inlineasm">inline asm</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="yes"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="no"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_jit">jit</a></td></span>
+<span class="raw-html"><td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="yes"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_objectwrite">.o file writing</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="na"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="yes"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="yes"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td></span>
+<span class="raw-html"><td class="yes"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="yes"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="yes"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="unknown"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="no"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="yes"></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="no"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"><tr></span>
+<span class="raw-html"><td><a href="#feat_segstacks">segmented stacks</a></td></span>
+<span class="raw-html"><td class="no"></td> <!-- ARM --></span>
+<span class="raw-html"><td class="no"></td> <!-- Hexagon --></span>
+<span class="raw-html"><td class="no"></td> <!-- MSP430 --></span>
+<span class="raw-html"><td class="no"></td> <!-- Mips --></span>
+<span class="raw-html"><td class="no"></td> <!-- NVPTX --></span>
+<span class="raw-html"><td class="no"></td> <!-- PowerPC --></span>
+<span class="raw-html"><td class="no"></td> <!-- Sparc --></span>
+<span class="raw-html"><td class="no"></td> <!-- SystemZ --></span>
+<span class="raw-html"><td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 --></span>
+<span class="raw-html"><td class="no"></td> <!-- XCore --></span>
+<span class="raw-html"><td class="no"></td> <!-- eBPF --></span>
+<span class="raw-html"></tr></span></p>
+<p><span class="raw-html"></table></span></p>
+<div class="section" id="is-generally-reliable">
+<span id="feat-reliable"></span><h4><a class="toc-backref" href="#id73">Is Generally Reliable</a><a class="headerlink" href="#is-generally-reliable" title="Permalink to this headline">¶</a></h4>
+<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 continuous use.</p>
+</div>
+<div class="section" id="assembly-parser">
+<span id="feat-asmparser"></span><h4><a class="toc-backref" href="#id74">Assembly Parser</a><a class="headerlink" href="#assembly-parser" title="Permalink to this headline">¶</a></h4>
+<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 support in
+the native .o file writer.</p>
+</div>
+<div class="section" id="disassembler">
+<span id="feat-disassembler"></span><h4><a class="toc-backref" href="#id75">Disassembler</a><a class="headerlink" href="#disassembler" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports the MCDisassembler API for
+disassembling machine opcode bytes into MCInst’s.</p>
+</div>
+<div class="section" id="inline-asm">
+<span id="feat-inlineasm"></span><h4><a class="toc-backref" href="#id76">Inline Asm</a><a class="headerlink" href="#inline-asm" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports most popular inline assembly
+constraints and modifiers.</p>
+</div>
+<div class="section" id="jit-support">
+<span id="feat-jit"></span><h4><a class="toc-backref" href="#id77">JIT Support</a><a class="headerlink" href="#jit-support" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports the JIT compiler through the
+ExecutionEngine interface.</p>
+<p id="feat-jit-arm">The ARM backend has basic support for integer code in ARM codegen mode, but
+lacks NEON and full Thumb support.</p>
+</div>
+<div class="section" id="o-file-writing">
+<span id="feat-objectwrite"></span><h4><a class="toc-backref" href="#id78">.o File Writing</a><a class="headerlink" href="#o-file-writing" title="Permalink to this headline">¶</a></h4>
+<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
+must include an assembly parser and general inline assembly support for full
+inline assembly support in the .o writer.</p>
+<p>Targets that don’t support this feature can obviously still write out .o files,
+they just rely on having an external assembler to translate from a .s file to a
+.o file (as is the case for many C compilers).</p>
+</div>
+<div class="section" id="tail-calls">
+<span id="feat-tailcall"></span><h4><a class="toc-backref" href="#id79">Tail Calls</a><a class="headerlink" href="#tail-calls" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports guaranteed tail calls. These are
+calls marked “<a class="reference external" href="LangRef.html#i_call">tail</a>” and use the fastcc calling
+convention. Please see the <a class="reference internal" href="#tail-call-section">tail call section</a> for more details.</p>
+</div>
+<div class="section" id="segmented-stacks">
+<span id="feat-segstacks"></span><h4><a class="toc-backref" href="#id80">Segmented Stacks</a><a class="headerlink" href="#segmented-stacks" title="Permalink to this headline">¶</a></h4>
+<p>This box indicates whether the target supports segmented stacks. This replaces
+the traditional large C stack with many linked segments. It is compatible with
+the <a class="reference external" href="http://gcc.gnu.org/wiki/SplitStacks">gcc implementation</a> used by the Go
+front end.</p>
+<p id="feat-segstacks-x86">Basic support exists on the X86 backend. Currently vararg doesn’t work and the
+object files are not marked the way the gold linker expects, but simple Go
+programs can be built by dragonegg.</p>
+</div>
+</div>
+<div class="section" id="tail-call-optimization">
+<span id="tail-call-section"></span><h3><a class="toc-backref" href="#id81">Tail call optimization</a><a class="headerlink" href="#tail-call-optimization" title="Permalink to this headline">¶</a></h3>
+<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>
+<ul class="simple">
+<li>Caller and callee have the calling convention <tt class="docutils literal"><span class="pre">fastcc</span></tt>, <tt class="docutils literal"><span class="pre">cc</span> <span class="pre">10</span></tt> (GHC
+calling convention) or <tt class="docutils literal"><span class="pre">cc</span> <span class="pre">11</span></tt> (HiPE calling convention).</li>
+<li>The call is a tail call - in tail position (ret immediately follows call and
+ret uses value of call or is void).</li>
+<li>Option <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt> is enabled.</li>
+<li>Platform-specific constraints are met.</li>
+</ul>
+<p>x86/x86-64 constraints:</p>
+<ul class="simple">
+<li>No variable argument lists are used.</li>
+<li>On x86-64 when generating GOT/PIC code only module-local calls (visibility =
+hidden or protected) are supported.</li>
+</ul>
+<p>PowerPC constraints:</p>
+<ul class="simple">
+<li>No variable argument lists are used.</li>
+<li>No byval parameters are used.</li>
+<li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected)
+are supported.</li>
+</ul>
+<p>Example:</p>
+<p>Call as <tt class="docutils literal"><span class="pre">llc</span> <span class="pre">-tailcallopt</span> <span class="pre">test.ll</span></tt>.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">declare</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcallee</span><span class="p">(</span><span class="k">i32</span> <span class="k">inreg</span> <span class="nv">%a1</span><span class="p">,</span> <span class="k">i32</span> <span class="k">inreg</span> <span class="nv">%a2</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%a3</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%a4</span><span class="p">)</span>
+
+<span class="k">define</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcaller</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in2</span><span class="p">)</span> <span class="p">{</span>
+ <span class="nv">%l1</span> <span class="p">=</span> <span class="k">add</span> <span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="nv">%in2</span>
+ <span class="nv">%tmp</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">fastcc</span> <span class="k">i32</span> <span class="vg">@tailcallee</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%in1</span> <span class="k">inreg</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in2</span> <span class="k">inreg</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%in1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%l1</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="nv">%tmp</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Implications of <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt>:</p>
+<p>To support tail call optimization in situations where the callee has more
+arguments than the caller a ‘callee pops arguments’ convention is used. This
+currently causes each <tt class="docutils literal"><span class="pre">fastcc</span></tt> call that is not tail call optimized (because
+one or more of above constraints are not met) to be followed by a readjustment
+of the stack. So performance might be worse in such cases.</p>
+</div>
+<div class="section" id="sibling-call-optimization">
+<h3><a class="toc-backref" href="#id82">Sibling call optimization</a><a class="headerlink" href="#sibling-call-optimization" title="Permalink to this headline">¶</a></h3>
+<p>Sibling call optimization is a restricted form of tail call optimization.
+Unlike tail call optimization described in the previous section, it can be
+performed automatically on any tail calls when <tt class="docutils literal"><span class="pre">-tailcallopt</span></tt> option is not
+specified.</p>
+<p>Sibling call optimization is currently performed on x86/x86-64 when the
+following constraints are met:</p>
+<ul class="simple">
+<li>Caller and callee have the same calling convention. It can be either <tt class="docutils literal"><span class="pre">c</span></tt> or
+<tt class="docutils literal"><span class="pre">fastcc</span></tt>.</li>
+<li>The call is a tail call - in tail position (ret immediately follows call and
+ret uses value of call or is void).</li>
+<li>Caller and callee have matching return type or the callee result is not used.</li>
+<li>If any of the callee arguments are being passed in stack, they must be
+available in caller’s own incoming argument stack and the frame offsets must
+be the same.</li>
+</ul>
+<p>Example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">declare</span> <span class="k">i32</span> <span class="vg">@bar</span><span class="p">(</span><span class="k">i32</span><span class="p">,</span> <span class="k">i32</span><span class="p">)</span>
+
+<span class="k">define</span> <span class="k">i32</span> <span class="vg">@foo</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%a</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%b</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%c</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+ <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i32</span> <span class="vg">@bar</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%a</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%b</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="nv-Anonymous">%0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-x86-backend">
+<h3><a class="toc-backref" href="#id83">The X86 backend</a><a class="headerlink" href="#the-x86-backend" title="Permalink to this headline">¶</a></h3>
+<p>The X86 code generator lives in the <tt class="docutils literal"><span class="pre">lib/Target/X86</span></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 class="section" id="x86-target-triples-supported">
+<h4><a class="toc-backref" href="#id84">X86 Target Triples supported</a><a class="headerlink" href="#x86-target-triples-supported" title="Permalink to this headline">¶</a></h4>
+<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
+that people test.</p>
+<ul class="simple">
+<li><strong>i686-pc-linux-gnu</strong> — Linux</li>
+<li><strong>i386-unknown-freebsd5.3</strong> — FreeBSD 5.3</li>
+<li><strong>i686-pc-cygwin</strong> — Cygwin on Win32</li>
+<li><strong>i686-pc-mingw32</strong> — MingW on Win32</li>
+<li><strong>i386-pc-mingw32msvc</strong> — MingW crosscompiler on Linux</li>
+<li><strong>i686-apple-darwin*</strong> — Apple Darwin on X86</li>
+<li><strong>x86_64-unknown-linux-gnu</strong> — Linux</li>
+</ul>
+</div>
+<div class="section" id="x86-calling-conventions-supported">
+<h4><a class="toc-backref" href="#id85">X86 Calling Conventions supported</a><a class="headerlink" href="#x86-calling-conventions-supported" title="Permalink to this headline">¶</a></h4>
+<p>The following target-specific calling conventions are known to backend:</p>
+<ul class="simple">
+<li><strong>x86_StdCall</strong> — stdcall calling convention seen on Microsoft Windows
+platform (CC ID = 64).</li>
+<li><strong>x86_FastCall</strong> — fastcall calling convention seen on Microsoft Windows
+platform (CC ID = 65).</li>
+<li><strong>x86_ThisCall</strong> — Similar to X86_StdCall. Passes first argument in ECX,
+others via stack. Callee is responsible for stack cleaning. This convention is
+used by MSVC by default for methods in its ABI (CC ID = 70).</li>
+</ul>
+</div>
+<div class="section" id="representing-x86-addressing-modes-in-machineinstrs">
+<span id="x86-addressing-mode"></span><h4><a class="toc-backref" href="#id86">Representing X86 addressing modes in MachineInstrs</a><a class="headerlink" href="#representing-x86-addressing-modes-in-machineinstrs" title="Permalink to this headline">¶</a></h4>
+<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 instructions
+(which use ModR/M addressing):</p>
+<div class="highlight-python"><pre>SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32</pre>
+</div>
+<p>In order to represent this, LLVM tracks no less than 5 operands for each memory
+operand of this form. This means that the “load” form of ‘<tt class="docutils literal"><span class="pre">mov</span></tt>‘ has the
+following <tt class="docutils literal"><span class="pre">MachineOperand</span></tt>s in this order:</p>
+<div class="highlight-python"><pre>Index: 0 | 1 2 3 4 5
+Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement Segment
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg</pre>
+</div>
+<p>Stores, and all other instructions, treat the four memory operands in the same
+way and in the same order. If the segment register is unspecified (regno = 0),
+then no segment override is generated. “Lea” operations do not have a segment
+register specified, so they only have 4 operands for their memory reference.</p>
+</div>
+<div class="section" id="x86-address-spaces-supported">
+<h4><a class="toc-backref" href="#id87">X86 address spaces supported</a><a class="headerlink" href="#x86-address-spaces-supported" title="Permalink to this headline">¶</a></h4>
+<p>x86 has a feature which provides the ability to perform loads and stores to
+different address spaces via the x86 segment registers. A segment override
+prefix byte on an instruction causes the instruction’s memory access to go to
+the specified segment. LLVM address space 0 is the default address space, which
+includes the stack, and any unqualified memory accesses in a program. Address
+spaces 1-255 are currently reserved for user-defined code. The GS-segment is
+represented by address space 256, the FS-segment is represented by address space
+257, and the SS-segment is represented by address space 258. Other x86 segments
+have yet to be allocated address space numbers.</p>
+<p>While these address spaces may seem similar to TLS via the <tt class="docutils literal"><span class="pre">thread_local</span></tt>
+keyword, and often use the same underlying hardware, there are some fundamental
+differences.</p>
+<p>The <tt class="docutils literal"><span class="pre">thread_local</span></tt> keyword applies to global variables and specifies that they
+are to be allocated in thread-local memory. There are no type qualifiers
+involved, and these variables can be pointed to with normal pointers and
+accessed with normal loads and stores. The <tt class="docutils literal"><span class="pre">thread_local</span></tt> keyword is
+target-independent at the LLVM IR level (though LLVM doesn’t yet have
+implementations of it for some configurations)</p>
+<p>Special address spaces, in contrast, apply to static types. Every load and store
+has a particular address space in its address operand type, and this is what
+determines which address space is accessed. LLVM ignores these special address
+space qualifiers on global variables, and does not provide a way to directly
+allocate storage in them. At the LLVM IR level, the behavior of these special
+address spaces depends in part on the underlying OS or runtime environment, and
+they are specific to x86 (and LLVM doesn’t yet handle them correctly in some
+cases).</p>
+<p>Some operating systems and runtime environments use (or may in the future use)
+the FS/GS-segment registers for various low-level purposes, so care should be
+taken when considering them.</p>
+</div>
+<div class="section" id="instruction-naming">
+<h4><a class="toc-backref" href="#id88">Instruction naming</a><a class="headerlink" href="#instruction-naming" title="Permalink to this headline">¶</a></h4>
+<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>
+<div class="highlight-python"><pre>ADD8rr -> add, 8-bit register, 8-bit register
+IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
+IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
+MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory</pre>
+</div>
+</div>
+</div>
+<div class="section" id="the-powerpc-backend">
+<h3><a class="toc-backref" href="#id89">The PowerPC backend</a><a class="headerlink" href="#the-powerpc-backend" title="Permalink to this headline">¶</a></h3>
+<p>The PowerPC code generator lives in the lib/Target/PowerPC directory. The code
+generation is retargetable to several variations or <em>subtargets</em> of the PowerPC
+ISA; including ppc32, ppc64 and altivec.</p>
+<div class="section" id="llvm-powerpc-abi">
+<h4><a class="toc-backref" href="#id90">LLVM PowerPC ABI</a><a class="headerlink" href="#llvm-powerpc-abi" title="Permalink to this headline">¶</a></h4>
+<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 (r2) is
+used. Second, r31 is used as a frame pointer to allow dynamic growth of a stack
+frame. LLVM takes advantage of having no TOC to provide space to save the frame
+pointer in the PowerPC linkage area of the caller frame. Other details of
+PowerPC ABI can be found at <a class="reference external" href="http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html">PowerPC ABI</a>. Note: This link describes the 32 bit ABI. The 64 bit ABI is similar except
+space for GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.</p>
+</div>
+<div class="section" id="frame-layout">
+<h4><a class="toc-backref" href="#id91">Frame Layout</a><a class="headerlink" href="#frame-layout" title="Permalink to this headline">¶</a></h4>
+<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 into the frame can be
+accessed via fixed offsets from the stack pointer. The exception to this is
+when dynamic alloca or variable sized arrays are present, then a base pointer
+(r31) is used as a proxy for the stack pointer and stack pointer is free to grow
+or shrink. A base pointer is also used if llvm-gcc is not passed the
+-fomit-frame-pointer flag. The stack pointer is always aligned to 16 bytes, so
+that space allocated for altivec vectors will be properly aligned.</p>
+<p>An invocation frame is laid out as follows (low memory at top):</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Linkage<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Parameter area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Dynamic area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Locals area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Saved registers area<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr style="border-style: none hidden none hidden;"></span>
+<span class="raw-html"><td><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>Previous Frame<br><br></td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>The <em>linkage</em> area is used by a callee to save special registers prior to
+allocating its own frame. Only three entries are relevant to LLVM. The first
+entry is the previous stack pointer (sp), aka link. This allows probing tools
+like gdb or exception handlers to quickly scan the frames in the stack. A
+function epilog can also use the link to pop the frame from the stack. The
+third entry in the linkage area is used to save the return address from the lr
+register. Finally, as mentioned above, the last entry is used to save the
+previous frame pointer (r31.) The entries in the linkage area are the size of a
+GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
+bit mode.</p>
+<p>32 bit linkage area:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>0</td></span>
+<span class="raw-html"><td>Saved SP (r1)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>4</td></span>
+<span class="raw-html"><td>Saved CR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>8</td></span>
+<span class="raw-html"><td>Saved LR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>12</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>16</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>20</td></span>
+<span class="raw-html"><td>Saved FP (r31)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>64 bit linkage area:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>0</td></span>
+<span class="raw-html"><td>Saved SP (r1)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>8</td></span>
+<span class="raw-html"><td>Saved CR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>16</td></span>
+<span class="raw-html"><td>Saved LR</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>24</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>32</td></span>
+<span class="raw-html"><td>Reserved</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>40</td></span>
+<span class="raw-html"><td>Saved FP (r31)</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+<p>The <em>parameter area</em> is used to store arguments being passed to a callee
+function. Following the PowerPC ABI, the first few arguments are actually
+passed in registers, with the space in the parameter area unused. However, if
+there are not enough registers or the callee is a thunk or vararg function,
+these register arguments can be spilled into the parameter area. Thus, the
+parameter area must be large enough to store all the parameters for the largest
+call sequence made by the caller. The size must also be minimally large enough
+to spill registers r3-r10. This allows callees blind to the call signature,
+such as thunks and vararg functions, enough space to cache the argument
+registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
+bit mode.) Also note that since the parameter area is a fixed offset from the
+top of the frame, that a callee can access its spilt arguments using fixed
+offsets from the stack pointer (or base pointer.)</p>
+<p>Combining the information about the linkage, parameter areas and alignment. A
+stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit mode.</p>
+<p>The <em>dynamic area</em> starts out as size zero. If a function uses dynamic alloca
+then space is added to the stack, the linkage and parameter areas are shifted to
+top of stack, and the new space is available immediately below the linkage and
+parameter areas. The cost of shifting the linkage and parameter areas is minor
+since only the link value needs to be copied. The link value can be easily
+fetched by adding the original frame size to the base pointer. Note that
+allocations in the dynamic space need to observe 16 byte alignment.</p>
+<p>The <em>locals area</em> is where the llvm compiler reserves space for local variables.</p>
+<p>The <em>saved registers area</em> is where the llvm compiler spills callee saved
+registers on entry to the callee.</p>
+</div>
+<div class="section" id="prolog-epilog">
+<h4><a class="toc-backref" href="#id92">Prolog/Epilog</a><a class="headerlink" href="#prolog-epilog" title="Permalink to this headline">¶</a></h4>
+<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 is
+created. This allows the llvm epilog/prolog support to be common with other
+targets. The base pointer callee saved register r31 is saved in the TOC slot of
+linkage area. This simplifies allocation of space for the base pointer and
+makes it convenient to locate programmatically and during debugging.</p>
+</div>
+<div class="section" id="dynamic-allocation">
+<h4><a class="toc-backref" href="#id93">Dynamic Allocation</a><a class="headerlink" href="#dynamic-allocation" title="Permalink to this headline">¶</a></h4>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">TODO - More to come.</p>
+</div>
+</div>
+</div>
+<div class="section" id="the-nvptx-backend">
+<h3><a class="toc-backref" href="#id94">The NVPTX backend</a><a class="headerlink" href="#the-nvptx-backend" title="Permalink to this headline">¶</a></h3>
+<p>The NVPTX code generator under lib/Target/NVPTX is an open-source version of
+the NVIDIA NVPTX code generator for LLVM. It is contributed by NVIDIA and is
+a port of the code generator used in the CUDA compiler (nvcc). It targets the
+PTX 3.0/3.1 ISA and can target any compute capability greater than or equal to
+2.0 (Fermi).</p>
+<p>This target is of production quality and should be completely compatible with
+the official NVIDIA toolchain.</p>
+<p>Code Generator Options:</p>
+<p><span class="raw-html"><table border="1" cellspacing="0"></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><th>Option</th></span>
+<span class="raw-html"><th>Description</th></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_20</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 2.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_21</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 2.1</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_30</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 3.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>sm_35</td></span>
+<span class="raw-html"><td align="left">Set shader model/compute capability to 3.5</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>ptx30</td></span>
+<span class="raw-html"><td align="left">Target PTX 3.0</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"><tr></span>
+<span class="raw-html"><td>ptx31</td></span>
+<span class="raw-html"><td align="left">Target PTX 3.1</td></span>
+<span class="raw-html"></tr></span>
+<span class="raw-html"></table></span></p>
+</div>
+<div class="section" id="the-extended-berkeley-packet-filter-ebpf-backend">
+<h3><a class="toc-backref" href="#id95">The extended Berkeley Packet Filter (eBPF) backend</a><a class="headerlink" href="#the-extended-berkeley-packet-filter-ebpf-backend" title="Permalink to this headline">¶</a></h3>
+<p>Extended BPF (or eBPF) is similar to the original (“classic”) BPF (cBPF) used
+to filter network packets. The
+<a class="reference external" href="http://man7.org/linux/man-pages/man2/bpf.2.html">bpf() system call</a>
+performs a range of operations related to eBPF. For both cBPF and eBPF
+programs, the Linux kernel statically analyzes the programs before loading
+them, in order to ensure that they cannot harm the running system. eBPF is
+a 64-bit RISC instruction set designed for one to one mapping to 64-bit CPUs.
+Opcodes are 8-bit encoded, and 87 instructions are defined. There are 10
+registers, grouped by function as outlined below.</p>
+<div class="highlight-python"><pre>R0 return value from in-kernel functions; exit value for eBPF program
+R1 - R5 function call arguments to in-kernel functions
+R6 - R9 callee-saved registers preserved by in-kernel functions
+R10 stack frame pointer (read only)</pre>
+</div>
+<div class="section" id="instruction-encoding-arithmetic-and-jump">
+<h4><a class="toc-backref" href="#id96">Instruction encoding (arithmetic and jump)</a><a class="headerlink" href="#instruction-encoding-arithmetic-and-jump" title="Permalink to this headline">¶</a></h4>
+<p>eBPF is reusing most of the opcode encoding from classic to simplify conversion
+of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit ‘code’
+field is divided into three parts:</p>
+<div class="highlight-python"><pre>+----------------+--------+--------------------+
+| 4 bits | 1 bit | 3 bits |
+| operation code | source | instruction class |
++----------------+--------+--------------------+
+(MSB) (LSB)</pre>
+</div>
+<p>Three LSB bits store instruction class which is one of:</p>
+<div class="highlight-python"><pre>BPF_LD 0x0
+BPF_LDX 0x1
+BPF_ST 0x2
+BPF_STX 0x3
+BPF_ALU 0x4
+BPF_JMP 0x5
+(unused) 0x6
+BPF_ALU64 0x7</pre>
+</div>
+<p>When BPF_CLASS(code) == BPF_ALU or BPF_ALU64 or BPF_JMP,
+4th bit encodes source operand</p>
+<div class="highlight-python"><pre>BPF_X 0x0 use src_reg register as source operand
+BPF_K 0x1 use 32 bit immediate as source operand</pre>
+</div>
+<p>and four MSB bits store operation code</p>
+<div class="highlight-python"><pre>BPF_ADD 0x0 add
+BPF_SUB 0x1 subtract
+BPF_MUL 0x2 multiply
+BPF_DIV 0x3 divide
+BPF_OR 0x4 bitwise logical OR
+BPF_AND 0x5 bitwise logical AND
+BPF_LSH 0x6 left shift
+BPF_RSH 0x7 right shift (zero extended)
+BPF_NEG 0x8 arithmetic negation
+BPF_MOD 0x9 modulo
+BPF_XOR 0xa bitwise logical XOR
+BPF_MOV 0xb move register to register
+BPF_ARSH 0xc right shift (sign extended)
+BPF_END 0xd endianness conversion</pre>
+</div>
+<p>If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of</p>
+<div class="highlight-python"><pre>BPF_JA 0x0 unconditional jump
+BPF_JEQ 0x1 jump ==
+BPF_JGT 0x2 jump >
+BPF_JGE 0x3 jump >=
+BPF_JSET 0x4 jump if (DST & SRC)
+BPF_JNE 0x5 jump !=
+BPF_JSGT 0x6 jump signed >
+BPF_JSGE 0x7 jump signed >=
+BPF_CALL 0x8 function call
+BPF_EXIT 0x9 function return</pre>
+</div>
+</div>
+<div class="section" id="instruction-encoding-load-store">
+<h4><a class="toc-backref" href="#id97">Instruction encoding (load, store)</a><a class="headerlink" href="#instruction-encoding-load-store" title="Permalink to this headline">¶</a></h4>
+<p>For load and store instructions the 8-bit ‘code’ field is divided as:</p>
+<div class="highlight-python"><pre>+--------+--------+-------------------+
+| 3 bits | 2 bits | 3 bits |
+| mode | size | instruction class |
++--------+--------+-------------------+
+(MSB) (LSB)</pre>
+</div>
+<p>Size modifier is one of</p>
+<div class="highlight-python"><pre>BPF_W 0x0 word
+BPF_H 0x1 half word
+BPF_B 0x2 byte
+BPF_DW 0x3 double word</pre>
+</div>
+<p>Mode modifier is one of</p>
+<div class="highlight-python"><pre>BPF_IMM 0x0 immediate
+BPF_ABS 0x1 used to access packet data
+BPF_IND 0x2 used to access packet data
+BPF_MEM 0x3 memory
+(reserved) 0x4
+(reserved) 0x5
+BPF_XADD 0x6 exclusive add</pre>
+</div>
+</div>
+<div class="section" id="packet-data-access-bpf-abs-bpf-ind">
+<h4><a class="toc-backref" href="#id98">Packet data access (BPF_ABS, BPF_IND)</a><a class="headerlink" href="#packet-data-access-bpf-abs-bpf-ind" title="Permalink to this headline">¶</a></h4>
+<p>Two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and
+(BPF_IND | <size> | BPF_LD) which are used to access packet data.
+Register R6 is an implicit input that must contain pointer to sk_buff.
+Register R0 is an implicit output which contains the data fetched
+from the packet. Registers R1-R5 are scratch registers and must not
+be used to store the data across BPF_ABS | BPF_LD or BPF_IND | BPF_LD
+instructions. These instructions have implicit program exit condition
+as well. When eBPF program is trying to access the data beyond
+the packet boundary, the interpreter will abort the execution of the program.</p>
+<dl class="docutils">
+<dt>BPF_IND | BPF_W | BPF_LD is equivalent to:</dt>
+<dd>R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))</dd>
+</dl>
+</div>
+<div class="section" id="ebpf-maps">
+<h4><a class="toc-backref" href="#id99">eBPF maps</a><a class="headerlink" href="#ebpf-maps" title="Permalink to this headline">¶</a></h4>
+<p>eBPF maps are provided for sharing data between kernel and user-space.
+Currently implemented types are hash and array, with potential extension to
+support bloom filters, radix trees, etc. A map is defined by its type,
+maximum number of elements, key size and value size in bytes. eBPF syscall
+supports create, update, find and delete functions on maps.</p>
+</div>
+<div class="section" id="function-calls">
+<h4><a class="toc-backref" href="#id100">Function calls</a><a class="headerlink" href="#function-calls" title="Permalink to this headline">¶</a></h4>
+<p>Function call arguments are passed using up to five registers (R1 - R5).
+The return value is passed in a dedicated register (R0). Four additional
+registers (R6 - R9) are callee-saved, and the values in these registers
+are preserved within kernel functions. R0 - R5 are scratch registers within
+kernel functions, and eBPF programs must therefor store/restore values in
+these registers if needed across function calls. The stack can be accessed
+using the read-only frame pointer R10. eBPF registers map 1:1 to hardware
+registers on x86_64 and other 64-bit architectures. For example, x86_64
+in-kernel JIT maps them as</p>
+<div class="highlight-python"><div class="highlight"><pre><span class="n">R0</span> <span class="o">-</span> <span class="n">rax</span>
+<span class="n">R1</span> <span class="o">-</span> <span class="n">rdi</span>
+<span class="n">R2</span> <span class="o">-</span> <span class="n">rsi</span>
+<span class="n">R3</span> <span class="o">-</span> <span class="n">rdx</span>
+<span class="n">R4</span> <span class="o">-</span> <span class="n">rcx</span>
+<span class="n">R5</span> <span class="o">-</span> <span class="n">r8</span>
+<span class="n">R6</span> <span class="o">-</span> <span class="n">rbx</span>
+<span class="n">R7</span> <span class="o">-</span> <span class="n">r13</span>
+<span class="n">R8</span> <span class="o">-</span> <span class="n">r14</span>
+<span class="n">R9</span> <span class="o">-</span> <span class="n">r15</span>
+<span class="n">R10</span> <span class="o">-</span> <span class="n">rbp</span>
+</pre></div>
+</div>
+<p>since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing
+and rbx, r12 - r15 are callee saved.</p>
+</div>
+<div class="section" id="program-start">
+<h4><a class="toc-backref" href="#id101">Program start</a><a class="headerlink" href="#program-start" title="Permalink to this headline">¶</a></h4>
+<p>An eBPF program receives a single argument and contains
+a single eBPF main routine; the program does not contain eBPF functions.
+Function calls are limited to a predefined set of kernel functions. The size
+of a program is limited to 4K instructions: this ensures fast termination and
+a limited number of kernel function calls. Prior to running an eBPF program,
+a verifier performs static analysis to prevent loops in the code and
+to ensure valid register usage and operand types.</p>
+</div>
+</div>
+<div class="section" id="the-amdgpu-backend">
+<h3><a class="toc-backref" href="#id102">The AMDGPU backend</a><a class="headerlink" href="#the-amdgpu-backend" title="Permalink to this headline">¶</a></h3>
+<p>The AMDGPU code generator lives in the <tt class="docutils literal"><span class="pre">lib/Target/AMDGPU</span></tt>
+directory. This code generator is capable of targeting a variety of
+AMD GPU processors. Refer to <a class="reference internal" href="AMDGPUUsage.html"><em>User Guide for AMDGPU Backend</em></a> for more information.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="ExceptionHandling.html" title="Exception Handling in LLVM"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="Bugpoint.html" title="LLVM bugpoint tool: design and usage"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CodeOfConduct.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CodeOfConduct.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CodeOfConduct.html (added)
+++ www-releases/trunk/7.0.1/docs/CodeOfConduct.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,193 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Community Code of Conduct — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="Moving LLVM Projects to GitHub" href="Proposals/GitHubMove.html" />
+ <link rel="prev" title="Code Reviews with Phabricator" href="Phabricator.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Proposals/GitHubMove.html" title="Moving LLVM Projects to GitHub"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-community-code-of-conduct">
+<h1>LLVM Community Code of Conduct<a class="headerlink" href="#llvm-community-code-of-conduct" title="Permalink to this headline">¶</a></h1>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This document is currently a <strong>DRAFT</strong> document while it is being discussed
+by the community.</p>
+</div>
+<p>The LLVM community has always worked to be a welcoming and respectful
+community, and we want to ensure that doesn’t change as we grow and evolve. To
+that end, we have a few ground rules that we ask people to adhere to:</p>
+<ul class="simple">
+<li><a class="reference internal" href="#be-friendly-and-patient">be friendly and patient</a>,</li>
+<li><a class="reference internal" href="#be-welcoming">be welcoming</a>,</li>
+<li><a class="reference internal" href="#be-considerate">be considerate</a>,</li>
+<li><a class="reference internal" href="#be-respectful">be respectful</a>,</li>
+<li><a class="reference internal" href="#be-careful-in-the-words-that-you-choose-and-be-kind-to-others">be careful in the words that you choose and be kind to others</a>, and</li>
+<li><a class="reference internal" href="#when-we-disagree-try-to-understand-why">when we disagree, try to understand why</a>.</li>
+</ul>
+<p>This isn’t an exhaustive list of things that you can’t do. Rather, take it in
+the spirit in which it’s intended - a guide to make it easier to communicate
+and participate in the community.</p>
+<p>This code of conduct applies to all spaces managed by the LLVM project or The
+LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM
+events such as the developer meetings and socials, and any other forums created
+by the project that the community uses for communication. It applies to all of
+your communication and conduct in these spaces, including emails, chats, things
+you say, slides, videos, posters, signs, or even t-shirts you display in these
+spaces. In addition, violations of this code outside these spaces may, in rare
+cases, affect a person’s ability to participate within them, when the conduct
+amounts to an egregious violation of this code.</p>
+<p>If you believe someone is violating the code of conduct, we ask that you report
+it by emailing <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>. For more details please see our
+<a class="reference internal" href="ReportingGuide.html"><em>Reporting Guide</em></a>.</p>
+<ul class="simple" id="be-friendly-and-patient">
+<li><strong>Be friendly and patient.</strong></li>
+</ul>
+<ul class="simple" id="be-welcoming">
+<li><strong>Be welcoming.</strong> We strive to be a community that welcomes and supports
+people of all backgrounds and identities. This includes, but is not limited
+to members of any race, ethnicity, culture, national origin, colour,
+immigration status, social and economic class, educational level, sex, sexual
+orientation, gender identity and expression, age, size, family status,
+political belief, religion or lack thereof, and mental and physical ability.</li>
+</ul>
+<ul class="simple" id="be-considerate">
+<li><strong>Be considerate.</strong> Your work will be used by other people, and you in turn
+will depend on the work of others. Any decision you take will affect users
+and colleagues, and you should take those consequences into account. Remember
+that we’re a world-wide community, so you might not be communicating in
+someone else’s primary language.</li>
+</ul>
+<ul class="simple" id="be-respectful">
+<li><strong>Be respectful.</strong> Not all of us will agree all the time, but disagreement is
+no excuse for poor behavior and poor manners. We might all experience some
+frustration now and then, but we cannot allow that frustration to turn into
+a personal attack. It’s important to remember that a community where people
+feel uncomfortable or threatened is not a productive one. Members of the LLVM
+community should be respectful when dealing with other members as well as
+with people outside the LLVM community.</li>
+</ul>
+<ul id="be-careful-in-the-words-that-you-choose-and-be-kind-to-others">
+<li><p class="first"><strong>Be careful in the words that you choose and be kind to others.</strong> Do not
+insult or put down other participants. Harassment and other exclusionary
+behavior aren’t acceptable. This includes, but is not limited to:</p>
+<ul class="simple">
+<li>Violent threats or language directed against another person.</li>
+<li>Discriminatory jokes and language.</li>
+<li>Posting sexually explicit or violent material.</li>
+<li>Posting (or threatening to post) other people’s personally identifying
+information (“doxing”).</li>
+<li>Personal insults, especially those using racist or sexist terms.</li>
+<li>Unwelcome sexual attention.</li>
+<li>Advocating for, or encouraging, any of the above behavior.</li>
+</ul>
+<p>In general, if someone asks you to stop, then stop. Persisting in such
+behavior after being asked to stop is considered harassment.</p>
+</li>
+</ul>
+<ul class="simple" id="when-we-disagree-try-to-understand-why">
+<li><strong>When we disagree, try to understand why.</strong> Disagreements, both social and
+technical, happen all the time and LLVM is no exception. It is important that
+we resolve disagreements and differing views constructively. Remember that
+we’re different. The strength of LLVM comes from its varied community, people
+from a wide range of backgrounds. Different people have different
+perspectives on issues. Being unable to understand why someone holds
+a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to
+err and blaming each other doesn’t get us anywhere. Instead, focus on helping
+to resolve issues and learning from mistakes.</li>
+</ul>
+<div class="section" id="questions">
+<h2>Questions?<a class="headerlink" href="#questions" title="Permalink to this headline">¶</a></h2>
+<p>If you have questions, please feel free to contact the LLVM Foundation Code of
+Conduct Advisory Committee by emailing <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>.</p>
+<p>(This text is based on the <a class="reference external" href="https://www.djangoproject.com/conduct/">Django Project</a> Code of Conduct, which is in turn
+based on wording from the <a class="reference external" href="http://speakup.io/coc.html">Speak Up! project</a>.)</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Proposals/GitHubMove.html" title="Moving LLVM Projects to GitHub"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CodingStandards.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CodingStandards.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CodingStandards.html (added)
+++ www-releases/trunk/7.0.1/docs/CodingStandards.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,1623 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Coding Standards — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="index.html" />
+ <link rel="next" title="CommandLine 2.0 Library Manual" href="CommandLine.html" />
+ <link rel="prev" title="LLVM Atomic Instructions and Concurrency Guide" href="Atomics.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="CommandLine.html" title="CommandLine 2.0 Library Manual"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="Atomics.html" title="LLVM Atomic Instructions and Concurrency Guide"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-coding-standards">
+<h1>LLVM Coding Standards<a class="headerlink" href="#llvm-coding-standards" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#languages-libraries-and-standards" id="id2">Languages, Libraries, and Standards</a><ul>
+<li><a class="reference internal" href="#c-standard-versions" id="id3">C++ Standard Versions</a></li>
+<li><a class="reference internal" href="#c-standard-library" id="id4">C++ Standard Library</a></li>
+<li><a class="reference internal" href="#supported-c-11-language-and-library-features" id="id5">Supported C++11 Language and Library Features</a></li>
+<li><a class="reference internal" href="#other-languages" id="id6">Other Languages</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#mechanical-source-issues" id="id7">Mechanical Source Issues</a><ul>
+<li><a class="reference internal" href="#source-code-formatting" id="id8">Source Code Formatting</a><ul>
+<li><a class="reference internal" href="#commenting" id="id9">Commenting</a><ul>
+<li><a class="reference internal" href="#file-headers" id="id10">File Headers</a></li>
+<li><a class="reference internal" href="#class-overviews" id="id11">Class overviews</a></li>
+<li><a class="reference internal" href="#method-information" id="id12">Method information</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#comment-formatting" id="id13">Comment Formatting</a></li>
+<li><a class="reference internal" href="#doxygen-use-in-documentation-comments" id="id14">Doxygen Use in Documentation Comments</a></li>
+<li><a class="reference internal" href="#include-style" id="id15"><tt class="docutils literal"><span class="pre">#include</span></tt> Style</a></li>
+<li><a class="reference internal" href="#source-code-width" id="id16">Source Code Width</a></li>
+<li><a class="reference internal" href="#use-spaces-instead-of-tabs" id="id17">Use Spaces Instead of Tabs</a></li>
+<li><a class="reference internal" href="#indent-code-consistently" id="id18">Indent Code Consistently</a><ul>
+<li><a class="reference internal" href="#format-lambdas-like-blocks-of-code" id="id19">Format Lambdas Like Blocks Of Code</a></li>
+<li><a class="reference internal" href="#braced-initializer-lists" id="id20">Braced Initializer Lists</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#language-and-compiler-issues" id="id21">Language and Compiler Issues</a><ul>
+<li><a class="reference internal" href="#treat-compiler-warnings-like-errors" id="id22">Treat Compiler Warnings Like Errors</a></li>
+<li><a class="reference internal" href="#write-portable-code" id="id23">Write Portable Code</a></li>
+<li><a class="reference internal" href="#do-not-use-rtti-or-exceptions" id="id24">Do not use RTTI or Exceptions</a></li>
+<li><a class="reference internal" href="#do-not-use-static-constructors" id="id25">Do not use Static Constructors</a></li>
+<li><a class="reference internal" href="#use-of-class-and-struct-keywords" id="id26">Use of <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> Keywords</a></li>
+<li><a class="reference internal" href="#do-not-use-braced-initializer-lists-to-call-a-constructor" id="id27">Do not use Braced Initializer Lists to Call a Constructor</a></li>
+<li><a class="reference internal" href="#use-auto-type-deduction-to-make-code-more-readable" id="id28">Use <tt class="docutils literal"><span class="pre">auto</span></tt> Type Deduction to Make Code More Readable</a></li>
+<li><a class="reference internal" href="#beware-unnecessary-copies-with-auto" id="id29">Beware unnecessary copies with <tt class="docutils literal"><span class="pre">auto</span></tt></a></li>
+<li><a class="reference internal" href="#beware-of-non-determinism-due-to-ordering-of-pointers" id="id30">Beware of non-determinism due to ordering of pointers</a></li>
+<li><a class="reference internal" href="#beware-of-non-deterministic-sorting-order-of-equal-elements" id="id31">Beware of non-deterministic sorting order of equal elements</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#style-issues" id="id32">Style Issues</a><ul>
+<li><a class="reference internal" href="#the-high-level-issues" id="id33">The High-Level Issues</a><ul>
+<li><a class="reference internal" href="#self-contained-headers" id="id34">Self-contained Headers</a></li>
+<li><a class="reference internal" href="#library-layering" id="id35">Library Layering</a></li>
+<li><a class="reference internal" href="#include-as-little-as-possible" id="id36"><tt class="docutils literal"><span class="pre">#include</span></tt> as Little as Possible</a></li>
+<li><a class="reference internal" href="#keep-internal-headers-private" id="id37">Keep “Internal” Headers Private</a></li>
+<li><a class="reference internal" href="#use-early-exits-and-continue-to-simplify-code" id="id38">Use Early Exits and <tt class="docutils literal"><span class="pre">continue</span></tt> to Simplify Code</a></li>
+<li><a class="reference internal" href="#don-t-use-else-after-a-return" id="id39">Don’t use <tt class="docutils literal"><span class="pre">else</span></tt> after a <tt class="docutils literal"><span class="pre">return</span></tt></a></li>
+<li><a class="reference internal" href="#turn-predicate-loops-into-predicate-functions" id="id40">Turn Predicate Loops into Predicate Functions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-low-level-issues" id="id41">The Low-Level Issues</a><ul>
+<li><a class="reference internal" href="#name-types-functions-variables-and-enumerators-properly" id="id42">Name Types, Functions, Variables, and Enumerators Properly</a></li>
+<li><a class="reference internal" href="#assert-liberally" id="id43">Assert Liberally</a></li>
+<li><a class="reference internal" href="#do-not-use-using-namespace-std" id="id44">Do Not Use <tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span> <span class="pre">std</span></tt></a></li>
+<li><a class="reference internal" href="#provide-a-virtual-method-anchor-for-classes-in-headers" id="id45">Provide a Virtual Method Anchor for Classes in Headers</a></li>
+<li><a class="reference internal" href="#don-t-use-default-labels-in-fully-covered-switches-over-enumerations" id="id46">Don’t use default labels in fully covered switches over enumerations</a></li>
+<li><a class="reference internal" href="#use-range-based-for-loops-wherever-possible" id="id47">Use range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops wherever possible</a></li>
+<li><a class="reference internal" href="#don-t-evaluate-end-every-time-through-a-loop" id="id48">Don’t evaluate <tt class="docutils literal"><span class="pre">end()</span></tt> every time through a loop</a></li>
+<li><a class="reference internal" href="#include-iostream-is-forbidden" id="id49"><tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> is Forbidden</a></li>
+<li><a class="reference internal" href="#use-raw-ostream" id="id50">Use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt></a></li>
+<li><a class="reference internal" href="#avoid-std-endl" id="id51">Avoid <tt class="docutils literal"><span class="pre">std::endl</span></tt></a></li>
+<li><a class="reference internal" href="#don-t-use-inline-when-defining-a-function-in-a-class-definition" id="id52">Don’t use <tt class="docutils literal"><span class="pre">inline</span></tt> when defining a function in a class definition</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#microscopic-details" id="id53">Microscopic Details</a><ul>
+<li><a class="reference internal" href="#spaces-before-parentheses" id="id54">Spaces Before Parentheses</a></li>
+<li><a class="reference internal" href="#prefer-preincrement" id="id55">Prefer Preincrement</a></li>
+<li><a class="reference internal" href="#namespace-indentation" id="id56">Namespace Indentation</a></li>
+<li><a class="reference internal" href="#anonymous-namespaces" id="id57">Anonymous Namespaces</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#see-also" id="id58">See Also</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<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
+absolute requirements to be followed in all instances, coding standards are
+particularly important for large-scale code bases that follow a library-based
+design (like LLVM).</p>
+<p>While this document may provide guidance for some mechanical formatting issues,
+whitespace, or other “microscopic details”, these are not fixed standards.
+Always follow the golden rule:</p>
+<blockquote id="golden-rule">
+<div><strong>If you are extending, enhancing, or bug fixing already implemented code,
+use the style that is already being used so that the source is uniform and
+easy to follow.</strong></div></blockquote>
+<p>Note that some code bases (e.g. <tt class="docutils literal"><span class="pre">libc++</span></tt>) have really good reasons to deviate
+from the coding standards. In the case of <tt class="docutils literal"><span class="pre">libc++</span></tt>, this is because the
+naming and other conventions are dictated by the C++ standard. If you think
+there is a specific good reason to deviate from the standards here, please bring
+it up on the LLVM-dev mailing list.</p>
+<p>There are some conventions that are not uniformly followed in the code base
+(e.g. the naming convention). This is because they are relatively new, and a
+lot of code was written before they were put in place. Our long term goal is
+for the entire codebase to follow the convention, but we explicitly <em>do not</em>
+want patches that do large-scale reformatting of existing code. On the other
+hand, it is reasonable to rename the methods of a class if you’re about to
+change it in some other way. Just do the reformatting as a separate commit
+from the functionality change.</p>
+<p>The ultimate goal of these guidelines is to increase the readability and
+maintainability of our common source base. If you have suggestions for topics to
+be included, please mail them to <a class="reference external" href="mailto:sabre%40nondot.org">Chris</a>.</p>
+</div>
+<div class="section" id="languages-libraries-and-standards">
+<h2><a class="toc-backref" href="#id2">Languages, Libraries, and Standards</a><a class="headerlink" href="#languages-libraries-and-standards" title="Permalink to this headline">¶</a></h2>
+<p>Most source code in LLVM and other LLVM projects using these coding standards
+is C++ code. There are some places where C code is used either due to
+environment restrictions, historical restrictions, or due to third-party source
+code imported into the tree. Generally, our preference is for standards
+conforming, modern, and portable C++ code as the implementation language of
+choice.</p>
+<div class="section" id="c-standard-versions">
+<h3><a class="toc-backref" href="#id3">C++ Standard Versions</a><a class="headerlink" href="#c-standard-versions" title="Permalink to this headline">¶</a></h3>
+<p>LLVM, Clang, and LLD are currently written using C++11 conforming code,
+although we restrict ourselves to features which are available in the major
+toolchains supported as host compilers. The LLDB project is even more
+aggressive in the set of host compilers supported and thus uses still more
+features. Regardless of the supported features, code is expected to (when
+reasonable) be standard, portable, and modern C++11 code. We avoid unnecessary
+vendor-specific extensions, etc.</p>
+</div>
+<div class="section" id="c-standard-library">
+<h3><a class="toc-backref" href="#id4">C++ Standard Library</a><a class="headerlink" href="#c-standard-library" title="Permalink to this headline">¶</a></h3>
+<p>Use the C++ standard library facilities whenever they are available for
+a particular task. LLVM and related projects emphasize and rely on the standard
+library facilities for as much as possible. Common support libraries providing
+functionality missing from the standard library for which there are standard
+interfaces or active work on adding standard interfaces will often be
+implemented in the LLVM namespace following the expected standard interface.</p>
+<p>There are some exceptions such as the standard I/O streams library which are
+avoided. Also, there is much more detailed information on these subjects in the
+<a class="reference internal" href="ProgrammersManual.html"><em>LLVM Programmer’s Manual</em></a>.</p>
+</div>
+<div class="section" id="supported-c-11-language-and-library-features">
+<h3><a class="toc-backref" href="#id5">Supported C++11 Language and Library Features</a><a class="headerlink" href="#supported-c-11-language-and-library-features" title="Permalink to this headline">¶</a></h3>
+<p>While LLVM, Clang, and LLD use C++11, not all features are available in all of
+the toolchains which we support. The set of features supported for use in LLVM
+is the intersection of those supported in the minimum requirements described
+in the <a class="reference internal" href="GettingStarted.html"><em>Getting Started with the LLVM System</em></a> page, section <cite>Software</cite>.
+The ultimate definition of this set is what build bots with those respective
+toolchains accept. Don’t argue with the build bots. However, we have some
+guidance below to help you know what to expect.</p>
+<p>Each toolchain provides a good reference for what it accepts:</p>
+<ul class="simple">
+<li>Clang: <a class="reference external" href="https://clang.llvm.org/cxx_status.html">https://clang.llvm.org/cxx_status.html</a></li>
+<li>GCC: <a class="reference external" href="https://gcc.gnu.org/projects/cxx-status.html#cxx11">https://gcc.gnu.org/projects/cxx-status.html#cxx11</a></li>
+<li>MSVC: <a class="reference external" href="https://msdn.microsoft.com/en-us/library/hh567368.aspx">https://msdn.microsoft.com/en-us/library/hh567368.aspx</a></li>
+</ul>
+<p>In most cases, the MSVC list will be the dominating factor. Here is a summary
+of the features that are expected to work. Features not on this list are
+unlikely to be supported by our host compilers.</p>
+<ul class="simple">
+<li>Rvalue references: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html">N2118</a><ul>
+<li>But <em>not</em> Rvalue references for <tt class="docutils literal"><span class="pre">*this</span></tt> or member qualifiers (<a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm">N2439</a>)</li>
+</ul>
+</li>
+<li>Static assert: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html">N1720</a></li>
+<li><tt class="docutils literal"><span class="pre">auto</span></tt> type deduction: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf">N1984</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf">N1737</a></li>
+<li>Trailing return types: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm">N2541</a></li>
+<li>Lambdas: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf">N2927</a><ul>
+<li>But <em>not</em> lambdas with default arguments.</li>
+</ul>
+</li>
+<li><tt class="docutils literal"><span class="pre">decltype</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf">N2343</a></li>
+<li>Nested closing right angle brackets: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html">N1757</a></li>
+<li>Extern templates: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm">N1987</a></li>
+<li><tt class="docutils literal"><span class="pre">nullptr</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a></li>
+<li>Strongly-typed and forward declarable enums: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf">N2764</a></li>
+<li>Local and unnamed types as template arguments: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm">N2657</a></li>
+<li>Range-based for-loop: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html">N2930</a><ul>
+<li>But <tt class="docutils literal"><span class="pre">{}</span></tt> are required around inner <tt class="docutils literal"><span class="pre">do</span> <span class="pre">{}</span> <span class="pre">while()</span></tt> loops. As a result,
+<tt class="docutils literal"><span class="pre">{}</span></tt> are required around function-like macros inside range-based for
+loops.</li>
+</ul>
+</li>
+<li><tt class="docutils literal"><span class="pre">override</span></tt> and <tt class="docutils literal"><span class="pre">final</span></tt>: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm">N2928</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm">N3206</a>, <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm">N3272</a></li>
+<li>Atomic operations and the C++11 memory model: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm">N2429</a></li>
+<li>Variadic templates: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf">N2242</a></li>
+<li>Explicit conversion operators: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf">N2437</a></li>
+<li>Defaulted and deleted functions: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm">N2346</a></li>
+<li>Initializer lists: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm">N2627</a></li>
+<li>Delegating constructors: <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf">N1986</a></li>
+<li>Default member initializers (non-static data member initializers): <a class="reference external" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm">N2756</a><ul>
+<li>Feel free to use these wherever they make sense and where the <cite>=</cite>
+syntax is allowed. Don’t use braced initialization syntax.</li>
+</ul>
+</li>
+</ul>
+<p>The supported features in the C++11 standard libraries are less well tracked,
+but also much greater. Most of the standard libraries implement most of C++11’s
+library. The most likely lowest common denominator is Linux support. For
+libc++, the support is just poorly tested and undocumented but expected to be
+largely complete. YMMV. For libstdc++, the support is documented in detail in
+<a class="reference external" href="https://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/manual/manual/status.html#status.iso.2011">the libstdc++ manual</a>. There are some very minor missing facilities that are
+unlikely to be common problems, and there are a few larger gaps that are worth
+being aware of:</p>
+<ul class="simple">
+<li>Not all of the type traits are implemented</li>
+<li>No regular expression library.</li>
+<li>While most of the atomics library is well implemented, the fences are
+missing. Fortunately, they are rarely needed.</li>
+<li>The locale support is incomplete.</li>
+</ul>
+<p>Other than these areas you should assume the standard library is available and
+working as expected until some build bot tells you otherwise. If you’re in an
+uncertain area of one of the above points, but you cannot test on a Linux
+system, your best approach is to minimize your use of these features, and watch
+the Linux build bots to find out if your usage triggered a bug. For example, if
+you hit a type trait which doesn’t work we can then add support to LLVM’s
+traits header to emulate it.</p>
+</div>
+<div class="section" id="other-languages">
+<h3><a class="toc-backref" href="#id6">Other Languages</a><a class="headerlink" href="#other-languages" title="Permalink to this headline">¶</a></h3>
+<p>Any code written in the Go programming language is not subject to the
+formatting rules below. Instead, we adopt the formatting rules enforced by
+the <a class="reference external" href="https://golang.org/cmd/gofmt/">gofmt</a> tool.</p>
+<p>Go code should strive to be idiomatic. Two good sets of guidelines for what
+this means are <a class="reference external" href="https://golang.org/doc/effective_go.html">Effective Go</a> and <a class="reference external" href="https://github.com/golang/go/wiki/CodeReviewComments">Go Code Review Comments</a>.</p>
+</div>
+</div>
+<div class="section" id="mechanical-source-issues">
+<h2><a class="toc-backref" href="#id7">Mechanical Source Issues</a><a class="headerlink" href="#mechanical-source-issues" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="source-code-formatting">
+<h3><a class="toc-backref" href="#id8">Source Code Formatting</a><a class="headerlink" href="#source-code-formatting" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="commenting">
+<h4><a class="toc-backref" href="#id9">Commenting</a><a class="headerlink" href="#commenting" title="Permalink to this headline">¶</a></h4>
+<p>Comments are one critical part of readability and maintainability. Everyone
+knows they should comment their code, and so should you. When writing comments,
+write them as English prose, which means they should use proper capitalization,
+punctuation, etc. Aim to describe what the code is trying to do and why, not
+<em>how</em> it does it at a micro level. Here are a few critical things to document:</p>
+<div class="section" id="file-headers">
+<span id="header-file-comment"></span><h5><a class="toc-backref" href="#id10">File Headers</a><a class="headerlink" href="#file-headers" title="Permalink to this headline">¶</a></h5>
+<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 checked into the
+tree. The standard header looks like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">//===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//</span>
+<span class="c1">//</span>
+<span class="c1">// The LLVM Compiler Infrastructure</span>
+<span class="c1">//</span>
+<span class="c1">// This file is distributed under the University of Illinois Open Source</span>
+<span class="c1">// License. See LICENSE.TXT for details.</span>
+<span class="c1">//</span>
+<span class="c1">//===----------------------------------------------------------------------===//</span>
+<span class="c1">///</span>
+<span class="c1">/// \file</span>
+<span class="c1">/// This file contains the declaration of the Instruction class, which is the</span>
+<span class="c1">/// base class for all of the VM instructions.</span>
+<span class="c1">///</span>
+<span class="c1">//===----------------------------------------------------------------------===//</span>
+</pre></div>
+</div>
+<p>A few things to note about this particular format: The “<tt class="docutils literal"><span class="pre">-*-</span> <span class="pre">C++</span> <span class="pre">-*-</span></tt>” string
+on the first line is there to tell Emacs that the source file is a C++ file, not
+a C file (Emacs assumes <tt class="docutils literal"><span class="pre">.h</span></tt> files are C files by default).</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This tag is not necessary in <tt class="docutils literal"><span class="pre">.cpp</span></tt> files. The name of the file is also
+on the first line, along with a very short description of the purpose of the
+file. This is important when printing out code and flipping though lots of
+pages.</p>
+</div>
+<p>The next section in the file is a concise note that defines the license that the
+file is released under. This makes it perfectly clear what terms the source
+code can be distributed under and should not be modified in any way.</p>
+<p>The main body is a <tt class="docutils literal"><span class="pre">doxygen</span></tt> comment (identified by the <tt class="docutils literal"><span class="pre">///</span></tt> comment
+marker instead of the usual <tt class="docutils literal"><span class="pre">//</span></tt>) describing the purpose of the file. The
+first sentence (or a passage beginning with <tt class="docutils literal"><span class="pre">\brief</span></tt>) is used as an abstract.
+Any additional information should be separated by a blank line. 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
+<em>gotchas</em> in the code to watch out for.</p>
+</div>
+<div class="section" id="class-overviews">
+<h5><a class="toc-backref" href="#id11">Class overviews</a><a class="headerlink" href="#class-overviews" title="Permalink to this headline">¶</a></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
+used for and how it works. Every non-trivial class is expected to have a
+<tt class="docutils literal"><span class="pre">doxygen</span></tt> comment block.</p>
+</div>
+<div class="section" id="method-information">
+<h5><a class="toc-backref" href="#id12">Method information</a><a class="headerlink" href="#method-information" title="Permalink to this headline">¶</a></h5>
+<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
+borderline behaviour is all that is necessary here (unless something
+particularly tricky or insidious is going on). The hope is that people can
+figure out how to use your interfaces without reading the code itself.</p>
+<p>Good things to talk about here are what happens when something unexpected
+happens: does the method return null? Abort? Format your hard disk?</p>
+</div>
+</div>
+<div class="section" id="comment-formatting">
+<h4><a class="toc-backref" href="#id13">Comment Formatting</a><a class="headerlink" href="#comment-formatting" title="Permalink to this headline">¶</a></h4>
+<p>In general, prefer C++ style comments (<tt class="docutils literal"><span class="pre">//</span></tt> for normal comments, <tt class="docutils literal"><span class="pre">///</span></tt> for
+<tt class="docutils literal"><span class="pre">doxygen</span></tt> documentation comments). They take less space, require
+less typing, don’t have nesting problems, etc. There are a few cases when it is
+useful to use C style (<tt class="docutils literal"><span class="pre">/*</span> <span class="pre">*/</span></tt>) comments however:</p>
+<ol class="arabic simple">
+<li>When writing C code: Obviously if you are writing C code, use C style
+comments.</li>
+<li>When writing a header file that may be <tt class="docutils literal"><span class="pre">#include</span></tt>d by a C source file.</li>
+<li>When writing a source file that is used by a tool that only accepts C style
+comments.</li>
+</ol>
+<p>Commenting out large blocks of code is discouraged, but if you really have to do
+this (for documentation purposes or as a suggestion for debug printing), use
+<tt class="docutils literal"><span class="pre">#if</span> <span class="pre">0</span></tt> and <tt class="docutils literal"><span class="pre">#endif</span></tt>. These nest properly and are better behaved in general
+than C style comments.</p>
+</div>
+<div class="section" id="doxygen-use-in-documentation-comments">
+<h4><a class="toc-backref" href="#id14">Doxygen Use in Documentation Comments</a><a class="headerlink" href="#doxygen-use-in-documentation-comments" title="Permalink to this headline">¶</a></h4>
+<p>Use the <tt class="docutils literal"><span class="pre">\file</span></tt> command to turn the standard file header into a file-level
+comment.</p>
+<p>Include descriptive paragraphs for all public interfaces (public classes,
+member and non-member functions). Don’t just restate the information that can
+be inferred from the API name. The first sentence (or a paragraph beginning
+with <tt class="docutils literal"><span class="pre">\brief</span></tt>) is used as an abstract. Try to use a single sentence as the
+<tt class="docutils literal"><span class="pre">\brief</span></tt> adds visual clutter. Put detailed discussion into separate
+paragraphs.</p>
+<p>To refer to parameter names inside a paragraph, use the <tt class="docutils literal"><span class="pre">\p</span> <span class="pre">name</span></tt> command.
+Don’t use the <tt class="docutils literal"><span class="pre">\arg</span> <span class="pre">name</span></tt> command since it starts a new paragraph that
+contains documentation for the parameter.</p>
+<p>Wrap non-inline code examples in <tt class="docutils literal"><span class="pre">\code</span> <span class="pre">...</span> <span class="pre">\endcode</span></tt>.</p>
+<p>To document a function parameter, start a new paragraph with the
+<tt class="docutils literal"><span class="pre">\param</span> <span class="pre">name</span></tt> command. If the parameter is used as an out or an in/out
+parameter, use the <tt class="docutils literal"><span class="pre">\param</span> <span class="pre">[out]</span> <span class="pre">name</span></tt> or <tt class="docutils literal"><span class="pre">\param</span> <span class="pre">[in,out]</span> <span class="pre">name</span></tt> command,
+respectively.</p>
+<p>To describe function return value, start a new paragraph with the <tt class="docutils literal"><span class="pre">\returns</span></tt>
+command.</p>
+<p>A minimal documentation comment:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// Sets the xyzzy property to \p Baz.</span>
+<span class="kt">void</span> <span class="n">setXyzzy</span><span class="p">(</span><span class="kt">bool</span> <span class="n">Baz</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>A documentation comment that uses all Doxygen features in a preferred way:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// Does foo and bar.</span>
+<span class="c1">///</span>
+<span class="c1">/// Does not do foo the usual way if \p Baz is true.</span>
+<span class="c1">///</span>
+<span class="c1">/// Typical usage:</span>
+<span class="c1">/// \code</span>
+<span class="c1">/// fooBar(false, "quux", Res);</span>
+<span class="c1">/// \endcode</span>
+<span class="c1">///</span>
+<span class="c1">/// \param Quux kind of foo to do.</span>
+<span class="c1">/// \param [out] Result filled with bar sequence on foo success.</span>
+<span class="c1">///</span>
+<span class="c1">/// \returns true on success.</span>
+<span class="kt">bool</span> <span class="n">fooBar</span><span class="p">(</span><span class="kt">bool</span> <span class="n">Baz</span><span class="p">,</span> <span class="n">StringRef</span> <span class="n">Quux</span><span class="p">,</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="kt">int</span><span class="o">></span> <span class="o">&</span><span class="n">Result</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>Don’t duplicate the documentation comment in the header file and in the
+implementation file. Put the documentation comments for public APIs into the
+header file. Documentation comments for private APIs can go to the
+implementation file. In any case, implementation files can include additional
+comments (not necessarily in Doxygen markup) to explain implementation details
+as needed.</p>
+<p>Don’t duplicate function or class name at the beginning of the comment.
+For humans it is obvious which function or class is being documented;
+automatic documentation processing tools are smart enough to bind the comment
+to the correct declaration.</p>
+<p>Wrong:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// In Something.h:</span>
+
+<span class="c1">/// Something - An abstraction for some complicated thing.</span>
+<span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="c1">/// fooBar - Does foo and bar.</span>
+ <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="c1">// In Something.cpp:</span>
+
+<span class="c1">/// fooBar - Does foo and bar.</span>
+<span class="kt">void</span> <span class="n">Something</span><span class="o">::</span><span class="n">fooBar</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+</pre></div>
+</div>
+<p>Correct:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// In Something.h:</span>
+
+<span class="c1">/// An abstraction for some complicated thing.</span>
+<span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="c1">/// Does foo and bar.</span>
+ <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="c1">// In Something.cpp:</span>
+
+<span class="c1">// Builds a B-tree in order to do foo. See paper by...</span>
+<span class="kt">void</span> <span class="n">Something</span><span class="o">::</span><span class="n">fooBar</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+</pre></div>
+</div>
+<p>It is not required to use additional Doxygen features, but sometimes it might
+be a good idea to do so.</p>
+<p>Consider:</p>
+<ul class="simple">
+<li>adding comments to any narrow namespace containing a collection of
+related functions or types;</li>
+<li>using top-level groups to organize a collection of related functions at
+namespace scope where the grouping is smaller than the namespace;</li>
+<li>using member groups and additional comments attached to member
+groups to organize within a class.</li>
+</ul>
+<p>For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Something</span> <span class="p">{</span>
+ <span class="c1">/// \name Functions that do Foo.</span>
+ <span class="c1">/// @{</span>
+ <span class="kt">void</span> <span class="n">fooBar</span><span class="p">();</span>
+ <span class="kt">void</span> <span class="n">fooBaz</span><span class="p">();</span>
+ <span class="c1">/// @}</span>
+ <span class="p">...</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="include-style">
+<h4><a class="toc-backref" href="#id15"><tt class="docutils literal"><span class="pre">#include</span></tt> Style</a><a class="headerlink" href="#include-style" title="Permalink to this headline">¶</a></h4>
+<p>Immediately after the <a class="reference internal" href="#header-file-comment">header file comment</a> (and include guards if working on a
+header file), the <a class="reference internal" href="#minimal-list-of-includes">minimal list of #includes</a> required by the file should be
+listed. We prefer these <tt class="docutils literal"><span class="pre">#include</span></tt>s to be listed in this order:</p>
+<ol class="arabic simple" id="local-private-headers">
+<span id="main-module-header"></span><li>Main Module Header</li>
+<li>Local/Private Headers</li>
+<li>LLVM project/subproject headers (<tt class="docutils literal"><span class="pre">clang/...</span></tt>, <tt class="docutils literal"><span class="pre">lldb/...</span></tt>, <tt class="docutils literal"><span class="pre">llvm/...</span></tt>, etc)</li>
+<li>System <tt class="docutils literal"><span class="pre">#include</span></tt>s</li>
+</ol>
+<p>and each category should be sorted lexicographically by the full path.</p>
+<p>The <a class="reference internal" href="#main-module-header">Main Module Header</a> file applies to <tt class="docutils literal"><span class="pre">.cpp</span></tt> files which implement an
+interface defined by a <tt class="docutils literal"><span class="pre">.h</span></tt> file. This <tt class="docutils literal"><span class="pre">#include</span></tt> should always be included
+<strong>first</strong> regardless of where it lives on the file system. By including a
+header file first in the <tt class="docutils literal"><span class="pre">.cpp</span></tt> files that implement the interfaces, we ensure
+that the header does not have any hidden dependencies which are not explicitly
+<tt class="docutils literal"><span class="pre">#include</span></tt>d in the header, but should be. It is also a form of documentation
+in the <tt class="docutils literal"><span class="pre">.cpp</span></tt> file to indicate where the interfaces it implements are defined.</p>
+<p>LLVM project and subproject headers should be grouped from most specific to least
+specific, for the same reasons described above. For example, LLDB depends on
+both clang and LLVM, and clang depends on LLVM. So an LLDB source file should
+include <tt class="docutils literal"><span class="pre">lldb</span></tt> headers first, followed by <tt class="docutils literal"><span class="pre">clang</span></tt> headers, followed by
+<tt class="docutils literal"><span class="pre">llvm</span></tt> headers, to reduce the possibility (for example) of an LLDB header
+accidentally picking up a missing include due to the previous inclusion of that
+header in the main source file or some earlier header file. clang should
+similarly include its own headers before including llvm headers. This rule
+applies to all LLVM subprojects.</p>
+</div>
+<div class="section" id="source-code-width">
+<span id="fit-into-80-columns"></span><h4><a class="toc-backref" href="#id16">Source Code Width</a><a class="headerlink" href="#source-code-width" title="Permalink to this headline">¶</a></h4>
+<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 <tt class="docutils literal"><span class="pre">xterm</span></tt> without resizing
+it.</p>
+<p>The longer answer is that there must be some limit to the width of the code in
+order to reasonably allow developers to have multiple files side-by-side in
+windows on a modest display. If you are going to pick a width limit, it is
+somewhat arbitrary but you might as well pick something standard. Going with 90
+columns (for example) instead of 80 columns wouldn’t add any significant value
+and would be detrimental to printing out code. Also many other projects have
+standardized on 80 columns, so some people have already configured their editors
+for it (vs something else, like 90 columns).</p>
+<p>This is one of many contentious issues in coding standards, but it is not up for
+debate.</p>
+</div>
+<div class="section" id="use-spaces-instead-of-tabs">
+<h4><a class="toc-backref" href="#id17">Use Spaces Instead of Tabs</a><a class="headerlink" href="#use-spaces-instead-of-tabs" title="Permalink to this headline">¶</a></h4>
+<p>In all cases, prefer spaces to tabs in source files. People have different
+preferred indentation levels, and different styles of indentation that they
+like; this is fine. What isn’t fine is that different editors/viewers expand
+tabs out to different tab stops. This can cause your code to look completely
+unreadable, and it is not worth dealing with.</p>
+<p>As always, follow the <a class="reference internal" href="#golden-rule">Golden Rule</a> above: follow the style of
+existing code if you are modifying and extending it. If you like four spaces of
+indentation, <strong>DO NOT</strong> do that in the middle of a chunk of code with two spaces
+of indentation. Also, do not reindent a whole source file: it makes for
+incredible diffs that are absolutely worthless.</p>
+</div>
+<div class="section" id="indent-code-consistently">
+<h4><a class="toc-backref" href="#id18">Indent Code Consistently</a><a class="headerlink" href="#indent-code-consistently" title="Permalink to this headline">¶</a></h4>
+<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.
+Just do it. With the introduction of C++11, there are some new formatting
+challenges that merit some suggestions to help have consistent, maintainable,
+and tool-friendly formatting and indentation.</p>
+<div class="section" id="format-lambdas-like-blocks-of-code">
+<h5><a class="toc-backref" href="#id19">Format Lambdas Like Blocks Of Code</a><a class="headerlink" href="#format-lambdas-like-blocks-of-code" title="Permalink to this headline">¶</a></h5>
+<p>When formatting a multi-line lambda, format it like a block of code, that’s
+what it is. If there is only one multi-line lambda in a statement, and there
+are no expressions lexically after it in the statement, drop the indent to the
+standard two space indent for a block of code, as if it were an if-block opened
+by the preceding part of the statement:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">std</span><span class="o">::</span><span class="n">sort</span><span class="p">(</span><span class="n">foo</span><span class="p">.</span><span class="n">begin</span><span class="p">(),</span> <span class="n">foo</span><span class="p">.</span><span class="n">end</span><span class="p">(),</span> <span class="p">[</span><span class="o">&</span><span class="p">](</span><span class="n">Foo</span> <span class="n">a</span><span class="p">,</span> <span class="n">Foo</span> <span class="n">b</span><span class="p">)</span> <span class="o">-></span> <span class="kt">bool</span> <span class="p">{</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">a</span><span class="p">.</span><span class="n">blah</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">blah</span><span class="p">)</span>
+ <span class="k">return</span> <span class="kc">true</span><span class="p">;</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">a</span><span class="p">.</span><span class="n">baz</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">baz</span><span class="p">)</span>
+ <span class="k">return</span> <span class="kc">true</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">a</span><span class="p">.</span><span class="n">bam</span> <span class="o"><</span> <span class="n">b</span><span class="p">.</span><span class="n">bam</span><span class="p">;</span>
+<span class="p">});</span>
+</pre></div>
+</div>
+<p>To take best advantage of this formatting, if you are designing an API which
+accepts a continuation or single callable argument (be it a functor, or
+a <tt class="docutils literal"><span class="pre">std::function</span></tt>), it should be the last argument if at all possible.</p>
+<p>If there are multiple multi-line lambdas in a statement, or there is anything
+interesting after the lambda in the statement, indent the block two spaces from
+the indent of the <tt class="docutils literal"><span class="pre">[]</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">dyn_switch</span><span class="p">(</span><span class="n">V</span><span class="o">-></span><span class="n">stripPointerCasts</span><span class="p">(),</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">PHINode</span> <span class="o">*</span><span class="n">PN</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process phis...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">SelectInst</span> <span class="o">*</span><span class="n">SI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process selects...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">LoadInst</span> <span class="o">*</span><span class="n">LI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process loads...</span>
+ <span class="p">},</span>
+ <span class="p">[]</span> <span class="p">(</span><span class="n">AllocaInst</span> <span class="o">*</span><span class="n">AI</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// process allocas...</span>
+ <span class="p">});</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="braced-initializer-lists">
+<h5><a class="toc-backref" href="#id20">Braced Initializer Lists</a><a class="headerlink" href="#braced-initializer-lists" title="Permalink to this headline">¶</a></h5>
+<p>With C++11, there are significantly more uses of braced lists to perform
+initialization. These allow you to easily construct aggregate temporaries in
+expressions among other niceness. They now have a natural way of ending up
+nested within each other and within function calls in order to build up
+aggregates (such as option structs) from local variables. To make matters
+worse, we also have many more uses of braces in an expression context that are
+<em>not</em> performing initialization.</p>
+<p>The historically common formatting of braced initialization of aggregate
+variables does not mix cleanly with deep nesting, general expression contexts,
+function arguments, and lambdas. We suggest new code use a simple rule for
+formatting braced initialization lists: act as-if the braces were parentheses
+in a function call. The formatting rules exactly match those already well
+understood for formatting nested function calls. Examples:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">foo</span><span class="p">({</span><span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">,</span> <span class="n">c</span><span class="p">},</span> <span class="p">{</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">});</span>
+
+<span class="n">llvm</span><span class="o">::</span><span class="n">Constant</span> <span class="o">*</span><span class="n">Mask</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">0</span><span class="p">),</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">1</span><span class="p">),</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">ConstantInt</span><span class="o">::</span><span class="n">get</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">Type</span><span class="o">::</span><span class="n">getInt32Ty</span><span class="p">(</span><span class="n">getLLVMContext</span><span class="p">()),</span> <span class="mi">2</span><span class="p">)};</span>
+</pre></div>
+</div>
+<p>This formatting scheme also makes it particularly easy to get predictable,
+consistent, and automatic formatting with tools like <a class="reference external" href="https://clang.llvm.org/docs/ClangFormat.html">Clang Format</a>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="language-and-compiler-issues">
+<h3><a class="toc-backref" href="#id21">Language and Compiler Issues</a><a class="headerlink" href="#language-and-compiler-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="treat-compiler-warnings-like-errors">
+<h4><a class="toc-backref" href="#id22">Treat Compiler Warnings Like Errors</a><a class="headerlink" href="#treat-compiler-warnings-like-errors" title="Permalink to this headline">¶</a></h4>
+<p>If your code has compiler warnings in it, something is wrong — you aren’t
+casting values correctly, you have “questionable” constructs in your code, or
+you are doing something legitimately wrong. Compiler warnings can cover up
+legitimate errors in output and make dealing with a translation unit difficult.</p>
+<p>It is not possible to prevent all warnings from all compilers, nor is it
+desirable. Instead, pick a standard compiler (like <tt class="docutils literal"><span class="pre">gcc</span></tt>) that provides a
+good thorough set of warnings, and stick to it. At least in the case of
+<tt class="docutils literal"><span class="pre">gcc</span></tt>, it is possible to work around any spurious errors by changing the
+syntax of the code slightly. For example, a warning that annoys me occurs when
+I write code like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">V</span> <span class="o">=</span> <span class="n">getValue</span><span class="p">())</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">gcc</span></tt> will warn me that I probably want to use the <tt class="docutils literal"><span class="pre">==</span></tt> operator, and that I
+probably mistyped it. In most cases, I haven’t, and I really don’t want the
+spurious errors. To fix this particular problem, I rewrite the code like
+this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">((</span><span class="n">V</span> <span class="o">=</span> <span class="n">getValue</span><span class="p">()))</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>which shuts <tt class="docutils literal"><span class="pre">gcc</span></tt> up. Any <tt class="docutils literal"><span class="pre">gcc</span></tt> warning that annoys you can be fixed by
+massaging the code appropriately.</p>
+</div>
+<div class="section" id="write-portable-code">
+<h4><a class="toc-backref" href="#id23">Write Portable Code</a><a class="headerlink" href="#write-portable-code" title="Permalink to this headline">¶</a></h4>
+<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
+code, isolate it behind a well defined (and well documented) interface.</p>
+<p>In practice, this means that you shouldn’t assume much about the host compiler
+(and Visual Studio tends to be the lowest common denominator). If advanced
+features are used, they should only be an implementation detail of a library
+which has a simple exposed API, and preferably be buried in <tt class="docutils literal"><span class="pre">libSystem</span></tt>.</p>
+</div>
+<div class="section" id="do-not-use-rtti-or-exceptions">
+<h4><a class="toc-backref" href="#id24">Do not use RTTI or Exceptions</a><a class="headerlink" href="#do-not-use-rtti-or-exceptions" title="Permalink to this headline">¶</a></h4>
+<p>In an effort to reduce code and executable size, LLVM does not use RTTI
+(e.g. <tt class="docutils literal"><span class="pre">dynamic_cast<>;</span></tt>) or exceptions. These two language features violate
+the general C++ principle of <em>“you only pay for what you use”</em>, causing
+executable bloat even if exceptions are never used in the code base, or if RTTI
+is never used for a class. Because of this, we turn them off globally in the
+code.</p>
+<p>That said, LLVM does make extensive use of a hand-rolled form of RTTI that use
+templates like <a class="reference internal" href="ProgrammersManual.html#isa"><em>isa<>, cast<>, and dyn_cast<></em></a>.
+This form of RTTI is opt-in and can be
+<a class="reference internal" href="HowToSetUpLLVMStyleRTTI.html"><em>added to any class</em></a>. It is also
+substantially more efficient than <tt class="docutils literal"><span class="pre">dynamic_cast<></span></tt>.</p>
+</div>
+<div class="section" id="do-not-use-static-constructors">
+<span id="static-constructor"></span><h4><a class="toc-backref" href="#id25">Do not use Static Constructors</a><a class="headerlink" href="#do-not-use-static-constructors" title="Permalink to this headline">¶</a></h4>
+<p>Static constructors and destructors (e.g. global variables whose types have a
+constructor or destructor) should not be added to the code base, and should be
+removed wherever possible. Besides <a class="reference external" href="https://yosefk.com/c++fqa/ctors.html#fqa-10.12">well known problems</a> where the order of
+initialization is undefined between globals in different source files, the
+entire concept of static constructors is at odds with the common use case of
+LLVM as a library linked into a larger application.</p>
+<p>Consider the use of LLVM as a JIT linked into another application (perhaps for
+<a class="reference external" href="https://llvm.org/Users.html">OpenGL, custom languages</a>, <a class="reference external" href="https://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf">shaders in movies</a>, etc). Due to the
+design of static constructors, they must be executed at startup time of the
+entire application, regardless of whether or how LLVM is used in that larger
+application. There are two problems with this:</p>
+<ul class="simple">
+<li>The time to run the static constructors impacts startup time of applications
+— a critical time for GUI apps, among others.</li>
+<li>The static constructors cause the app to pull many extra pages of memory off
+the disk: both the code for the constructor in each <tt class="docutils literal"><span class="pre">.o</span></tt> file and the small
+amount of data that gets touched. In addition, touched/dirty pages put more
+pressure on the VM system on low-memory machines.</li>
+</ul>
+<p>We would really like for there to be zero cost for linking in an additional LLVM
+target or other library into an application, but static constructors violate
+this goal.</p>
+<p>That said, LLVM unfortunately does contain static constructors. It would be a
+<a class="reference external" href="https://llvm.org/PR11944">great project</a> for someone to purge all static
+constructors from LLVM, and then enable the <tt class="docutils literal"><span class="pre">-Wglobal-constructors</span></tt> warning
+flag (when building with Clang) to ensure we do not regress in the future.</p>
+</div>
+<div class="section" id="use-of-class-and-struct-keywords">
+<h4><a class="toc-backref" href="#id26">Use of <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> Keywords</a><a class="headerlink" href="#use-of-class-and-struct-keywords" title="Permalink to this headline">¶</a></h4>
+<p>In C++, the <tt class="docutils literal"><span class="pre">class</span></tt> and <tt class="docutils literal"><span class="pre">struct</span></tt> keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+<tt class="docutils literal"><span class="pre">class</span></tt> makes all members private by default while <tt class="docutils literal"><span class="pre">struct</span></tt> makes all
+members public by default.</p>
+<p>Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether <tt class="docutils literal"><span class="pre">class</span></tt> or <tt class="docutils literal"><span class="pre">struct</span></tt> was used to declare
+the symbol (e.g., MSVC). This can lead to problems at link time.</p>
+<ul class="simple">
+<li>All declarations and definitions of a given <tt class="docutils literal"><span class="pre">class</span></tt> or <tt class="docutils literal"><span class="pre">struct</span></tt> must use
+the same keyword. For example:</li>
+</ul>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span><span class="p">;</span>
+
+<span class="c1">// Breaks mangling in MSVC.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span> <span class="p">};</span>
+</pre></div>
+</div>
+<ul class="simple">
+<li>As a rule of thumb, <tt class="docutils literal"><span class="pre">struct</span></tt> should be kept to structures where <em>all</em>
+members are declared public.</li>
+</ul>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Foo feels like a class... this is strange.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span>
+<span class="k">private</span><span class="o">:</span>
+ <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="n">Foo</span><span class="p">()</span> <span class="o">:</span> <span class="n">Data</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="p">}</span>
+ <span class="kt">int</span> <span class="n">getData</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="n">Data</span><span class="p">;</span> <span class="p">}</span>
+ <span class="kt">void</span> <span class="n">setData</span><span class="p">(</span><span class="kt">int</span> <span class="n">D</span><span class="p">)</span> <span class="p">{</span> <span class="n">Data</span> <span class="o">=</span> <span class="n">D</span><span class="p">;</span> <span class="p">}</span>
+<span class="p">};</span>
+
+<span class="c1">// Bar isn't POD, but it does look like a struct.</span>
+<span class="k">struct</span> <span class="n">Bar</span> <span class="p">{</span>
+ <span class="kt">int</span> <span class="n">Data</span><span class="p">;</span>
+ <span class="n">Bar</span><span class="p">()</span> <span class="o">:</span> <span class="n">Data</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="do-not-use-braced-initializer-lists-to-call-a-constructor">
+<h4><a class="toc-backref" href="#id27">Do not use Braced Initializer Lists to Call a Constructor</a><a class="headerlink" href="#do-not-use-braced-initializer-lists-to-call-a-constructor" title="Permalink to this headline">¶</a></h4>
+<p>In C++11 there is a “generalized initialization syntax” which allows calling
+constructors using braced initializer lists. Do not use these to call
+constructors with any interesting logic or if you care that you’re calling some
+<em>particular</em> constructor. Those should look like function calls using
+parentheses rather than like aggregate initialization. Similarly, if you need
+to explicitly name the type and call its constructor to create a temporary,
+don’t use a braced initializer list. Instead, use a braced initializer list
+(without any type for temporaries) when doing aggregate initialization or
+something notionally equivalent. Examples:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="c1">// Construct a Foo by reading data from the disk in the whizbang format, ...</span>
+ <span class="n">Foo</span><span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">filename</span><span class="p">);</span>
+
+ <span class="c1">// Construct a Foo by looking up the Nth element of some global data ...</span>
+ <span class="n">Foo</span><span class="p">(</span><span class="kt">int</span> <span class="n">N</span><span class="p">);</span>
+
+ <span class="c1">// ...</span>
+<span class="p">};</span>
+
+<span class="c1">// The Foo constructor call is very deliberate, no braces.</span>
+<span class="n">std</span><span class="o">::</span><span class="n">fill</span><span class="p">(</span><span class="n">foo</span><span class="p">.</span><span class="n">begin</span><span class="p">(),</span> <span class="n">foo</span><span class="p">.</span><span class="n">end</span><span class="p">(),</span> <span class="n">Foo</span><span class="p">(</span><span class="s">"name"</span><span class="p">));</span>
+
+<span class="c1">// The pair is just being constructed like an aggregate, use braces.</span>
+<span class="n">bar_map</span><span class="p">.</span><span class="n">insert</span><span class="p">({</span><span class="n">my_key</span><span class="p">,</span> <span class="n">my_value</span><span class="p">});</span>
+</pre></div>
+</div>
+<p>If you use a braced initializer list when initializing a variable, use an equals before the open curly brace:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">data</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span><span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="use-auto-type-deduction-to-make-code-more-readable">
+<h4><a class="toc-backref" href="#id28">Use <tt class="docutils literal"><span class="pre">auto</span></tt> Type Deduction to Make Code More Readable</a><a class="headerlink" href="#use-auto-type-deduction-to-make-code-more-readable" title="Permalink to this headline">¶</a></h4>
+<p>Some are advocating a policy of “almost always <tt class="docutils literal"><span class="pre">auto</span></tt>” in C++11, however LLVM
+uses a more moderate stance. Use <tt class="docutils literal"><span class="pre">auto</span></tt> if and only if it makes the code more
+readable or easier to maintain. Don’t “almost always” use <tt class="docutils literal"><span class="pre">auto</span></tt>, but do use
+<tt class="docutils literal"><span class="pre">auto</span></tt> with initializers like <tt class="docutils literal"><span class="pre">cast<Foo>(...)</span></tt> or other places where the
+type is already obvious from the context. Another time when <tt class="docutils literal"><span class="pre">auto</span></tt> works well
+for these purposes is when the type would have been abstracted away anyways,
+often behind a container’s typedef such as <tt class="docutils literal"><span class="pre">std::vector<T>::iterator</span></tt>.</p>
+</div>
+<div class="section" id="beware-unnecessary-copies-with-auto">
+<h4><a class="toc-backref" href="#id29">Beware unnecessary copies with <tt class="docutils literal"><span class="pre">auto</span></tt></a><a class="headerlink" href="#beware-unnecessary-copies-with-auto" title="Permalink to this headline">¶</a></h4>
+<p>The convenience of <tt class="docutils literal"><span class="pre">auto</span></tt> makes it easy to forget that its default behavior
+is a copy. Particularly in range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops, careless copies are
+expensive.</p>
+<p>As a rule of thumb, use <tt class="docutils literal"><span class="pre">auto</span> <span class="pre">&</span></tt> unless you need to copy the result, and use
+<tt class="docutils literal"><span class="pre">auto</span> <span class="pre">*</span></tt> when copying pointers.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Typically there's no reason to copy.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">const</span> <span class="k">auto</span> <span class="o">&</span><span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">observe</span><span class="p">(</span><span class="n">Val</span><span class="p">);</span> <span class="p">}</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="o">&</span><span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Val</span><span class="p">.</span><span class="n">change</span><span class="p">();</span> <span class="p">}</span>
+
+<span class="c1">// Remove the reference if you really want a new copy.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="n">Val</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Val</span><span class="p">.</span><span class="n">change</span><span class="p">();</span> <span class="n">saveSomewhere</span><span class="p">(</span><span class="n">Val</span><span class="p">);</span> <span class="p">}</span>
+
+<span class="c1">// Copy pointers, but make it clear that they're pointers.</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">const</span> <span class="k">auto</span> <span class="o">*</span><span class="n">Ptr</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">observe</span><span class="p">(</span><span class="o">*</span><span class="n">Ptr</span><span class="p">);</span> <span class="p">}</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="o">*</span><span class="n">Ptr</span> <span class="o">:</span> <span class="n">Container</span><span class="p">)</span> <span class="p">{</span> <span class="n">Ptr</span><span class="o">-></span><span class="n">change</span><span class="p">();</span> <span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="beware-of-non-determinism-due-to-ordering-of-pointers">
+<h4><a class="toc-backref" href="#id30">Beware of non-determinism due to ordering of pointers</a><a class="headerlink" href="#beware-of-non-determinism-due-to-ordering-of-pointers" title="Permalink to this headline">¶</a></h4>
+<p>In general, there is no relative ordering among pointers. As a result,
+when unordered containers like sets and maps are used with pointer keys
+the iteration order is undefined. Hence, iterating such containers may
+result in non-deterministic code generation. While the generated code
+might not necessarily be “wrong code”, this non-determinism might result
+in unexpected runtime crashes or simply hard to reproduce bugs on the
+customer side making it harder to debug and fix.</p>
+<p>As a rule of thumb, in case an ordered result is expected, remember to
+sort an unordered container before iteration. Or use ordered containers
+like vector/MapVector/SetVector if you want to iterate pointer keys.</p>
+</div>
+<div class="section" id="beware-of-non-deterministic-sorting-order-of-equal-elements">
+<h4><a class="toc-backref" href="#id31">Beware of non-deterministic sorting order of equal elements</a><a class="headerlink" href="#beware-of-non-deterministic-sorting-order-of-equal-elements" title="Permalink to this headline">¶</a></h4>
+<p>std::sort uses a non-stable sorting algorithm in which the order of equal
+elements is not guaranteed to be preserved. Thus using std::sort for a
+container having equal elements may result in non-determinstic behavior.
+To uncover such instances of non-determinism, LLVM has introduced a new
+llvm::sort wrapper function. For an EXPENSIVE_CHECKS build this will randomly
+shuffle the container before sorting. As a rule of thumb, always make sure to
+use llvm::sort instead of std::sort.</p>
+</div>
+</div>
+</div>
+<div class="section" id="style-issues">
+<h2><a class="toc-backref" href="#id32">Style Issues</a><a class="headerlink" href="#style-issues" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="the-high-level-issues">
+<h3><a class="toc-backref" href="#id33">The High-Level Issues</a><a class="headerlink" href="#the-high-level-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="self-contained-headers">
+<h4><a class="toc-backref" href="#id34">Self-contained Headers</a><a class="headerlink" href="#self-contained-headers" title="Permalink to this headline">¶</a></h4>
+<p>Header files should be self-contained (compile on their own) and end in .h.
+Non-header files that are meant for inclusion should end in .inc and be used
+sparingly.</p>
+<p>All header files should be self-contained. Users and refactoring tools should
+not have to adhere to special conditions to include the header. Specifically, a
+header should have header guards and include all other headers it needs.</p>
+<p>There are rare cases where a file designed to be included is not
+self-contained. These are typically intended to be included at unusual
+locations, such as the middle of another file. They might not use header
+guards, and might not include their prerequisites. Name such files with the
+.inc extension. Use sparingly, and prefer self-contained headers when possible.</p>
+<p>In general, a header should be implemented by one or more <tt class="docutils literal"><span class="pre">.cpp</span></tt> files. Each
+of these <tt class="docutils literal"><span class="pre">.cpp</span></tt> files should include the header that defines their interface
+first. This ensures that all of the dependences of the header have been
+properly added to the header itself, and are not implicit. System headers
+should be included after user headers for a translation unit.</p>
+</div>
+<div class="section" id="library-layering">
+<h4><a class="toc-backref" href="#id35">Library Layering</a><a class="headerlink" href="#library-layering" title="Permalink to this headline">¶</a></h4>
+<p>A directory of header files (for example <tt class="docutils literal"><span class="pre">include/llvm/Foo</span></tt>) defines a
+library (<tt class="docutils literal"><span class="pre">Foo</span></tt>). Dependencies between libraries are defined by the
+<tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> file in their implementation (<tt class="docutils literal"><span class="pre">lib/Foo</span></tt>). One library (both
+its headers and implementation) should only use things from the libraries
+listed in its dependencies.</p>
+<p>Some of this constraint can be enforced by classic Unix linkers (Mac & Windows
+linkers, as well as lld, do not enforce this constraint). A Unix linker
+searches left to right through the libraries specified on its command line and
+never revisits a library. In this way, no circular dependencies between
+libraries can exist.</p>
+<p>This doesn’t fully enforce all inter-library dependencies, and importantly
+doesn’t enforce header file circular dependencies created by inline functions.
+A good way to answer the “is this layered correctly” would be to consider
+whether a Unix linker would succeed at linking the program if all inline
+functions were defined out-of-line. (& for all valid orderings of dependencies
+- since linking resolution is linear, it’s possible that some implicit
+dependencies can sneak through: A depends on B and C, so valid orderings are
+“C B A” or “B C A”, in both cases the explicit dependencies come before their
+use. But in the first case, B could still link successfully if it implicitly
+depended on C, or the opposite in the second case)</p>
+</div>
+<div class="section" id="include-as-little-as-possible">
+<span id="minimal-list-of-includes"></span><h4><a class="toc-backref" href="#id36"><tt class="docutils literal"><span class="pre">#include</span></tt> as Little as Possible</a><a class="headerlink" href="#include-as-little-as-possible" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">#include</span></tt> hurts compile time performance. Don’t do it unless you have to,
+especially in header files.</p>
+<p>But wait! Sometimes you need to have the definition of a class to use it, or to
+inherit from it. In these cases go ahead and <tt class="docutils literal"><span class="pre">#include</span></tt> that header file. Be
+aware however that there are many cases where you don’t need to have the full
+definition of a class. If you are using a pointer or reference to a class, you
+don’t need the header file. If you are simply returning a class instance from a
+prototyped function or method, you don’t need it. In fact, for most cases, you
+simply don’t need the definition of a class. And not <tt class="docutils literal"><span class="pre">#include</span></tt>ing speeds up
+compilation.</p>
+<p>It is easy to try to go too overboard on this recommendation, however. You
+<strong>must</strong> include all of the header files that you are using — you can include
+them either directly or indirectly through another header file. To make sure
+that you don’t accidentally forget to include a header file in your module
+header, make sure to include your module header <strong>first</strong> in the implementation
+file (as mentioned above). This way there won’t be any hidden dependencies that
+you’ll find out about later.</p>
+</div>
+<div class="section" id="keep-internal-headers-private">
+<h4><a class="toc-backref" href="#id37">Keep “Internal” Headers Private</a><a class="headerlink" href="#keep-internal-headers-private" title="Permalink to this headline">¶</a></h4>
+<p>Many modules have a complex implementation that causes them to use more than one
+implementation (<tt class="docutils literal"><span class="pre">.cpp</span></tt>) file. It is often tempting to put the internal
+communication interface (helper classes, extra functions, etc) in the public
+module header file. Don’t do this!</p>
+<p>If you really need to do something like this, put a private header file in the
+same directory as the source files, and include it locally. This ensures that
+your private interface remains private and undisturbed by outsiders.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">It’s okay to put extra implementation methods in a public class itself. Just
+make them private (or protected) and all is well.</p>
+</div>
+</div>
+<div class="section" id="use-early-exits-and-continue-to-simplify-code">
+<span id="early-exits"></span><h4><a class="toc-backref" href="#id38">Use Early Exits and <tt class="docutils literal"><span class="pre">continue</span></tt> to Simplify Code</a><a class="headerlink" href="#use-early-exits-and-continue-to-simplify-code" title="Permalink to this headline">¶</a></h4>
+<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. Aim to
+reduce indentation where possible when it doesn’t make it more difficult to
+understand the code. One great way to do this is by making use of early exits
+and the <tt class="docutils literal"><span class="pre">continue</span></tt> keyword in long loops. As an example of using an early
+exit from a function, consider this “bad” code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">Value</span> <span class="o">*</span><span class="n">doSomething</span><span class="p">(</span><span class="n">Instruction</span> <span class="o">*</span><span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">isa</span><span class="o"><</span><span class="n">TerminatorInst</span><span class="o">></span><span class="p">(</span><span class="n">I</span><span class="p">)</span> <span class="o">&&</span>
+ <span class="n">I</span><span class="o">-></span><span class="n">hasOneUse</span><span class="p">()</span> <span class="o">&&</span> <span class="n">doOtherThing</span><span class="p">(</span><span class="n">I</span><span class="p">))</span> <span class="p">{</span>
+ <span class="p">...</span> <span class="n">some</span> <span class="kt">long</span> <span class="n">code</span> <span class="p">....</span>
+ <span class="p">}</span>
+
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This code has several problems if the body of the <tt class="docutils literal"><span class="pre">'if'</span></tt> is large. When
+you’re looking at the top of the function, it isn’t immediately clear that this
+<em>only</em> does interesting things with non-terminator instructions, and only
+applies to things with the other predicates. Second, it is relatively difficult
+to describe (in comments) why these predicates are important because the <tt class="docutils literal"><span class="pre">if</span></tt>
+statement makes it difficult to lay out the comments. Third, when you’re deep
+within the body of the code, it is indented an extra level. Finally, when
+reading the top of the function, it isn’t clear what the result is if the
+predicate isn’t true; you have to read to the end of the function to know that
+it returns null.</p>
+<p>It is much preferred to format the code like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">Value</span> <span class="o">*</span><span class="n">doSomething</span><span class="p">(</span><span class="n">Instruction</span> <span class="o">*</span><span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// Terminators never need 'something' done to them because ...</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">isa</span><span class="o"><</span><span class="n">TerminatorInst</span><span class="o">></span><span class="p">(</span><span class="n">I</span><span class="p">))</span>
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+ <span class="c1">// We conservatively avoid transforming instructions with multiple uses</span>
+ <span class="c1">// because goats like cheese.</span>
+ <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">I</span><span class="o">-></span><span class="n">hasOneUse</span><span class="p">())</span>
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+ <span class="c1">// This is really just here for example.</span>
+ <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">doOtherThing</span><span class="p">(</span><span class="n">I</span><span class="p">))</span>
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+
+ <span class="p">...</span> <span class="n">some</span> <span class="kt">long</span> <span class="n">code</span> <span class="p">....</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This fixes these problems. A similar problem frequently happens in <tt class="docutils literal"><span class="pre">for</span></tt>
+loops. A silly example is something like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="n">Instruction</span> <span class="o">&</span><span class="n">I</span> <span class="o">:</span> <span class="n">BB</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">if</span> <span class="p">(</span><span class="k">auto</span> <span class="o">*</span><span class="n">BO</span> <span class="o">=</span> <span class="n">dyn_cast</span><span class="o"><</span><span class="n">BinaryOperator</span><span class="o">></span><span class="p">(</span><span class="o">&</span><span class="n">I</span><span class="p">))</span> <span class="p">{</span>
+ <span class="n">Value</span> <span class="o">*</span><span class="n">LHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+ <span class="n">Value</span> <span class="o">*</span><span class="n">RHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">LHS</span> <span class="o">!=</span> <span class="n">RHS</span><span class="p">)</span> <span class="p">{</span>
+ <span class="p">...</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>When you have very, very small loops, this sort of structure is fine. But if it
+exceeds more than 10-15 lines, it becomes difficult for people to read and
+understand at a glance. The problem with this sort of code is that it gets very
+nested very quickly. Meaning that the reader of the code has to keep a lot of
+context in their brain to remember what is going immediately on in the loop,
+because they don’t know if/when the <tt class="docutils literal"><span class="pre">if</span></tt> conditions will have <tt class="docutils literal"><span class="pre">else</span></tt>s etc.
+It is strongly preferred to structure the loop like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">for</span> <span class="p">(</span><span class="n">Instruction</span> <span class="o">&</span><span class="n">I</span> <span class="o">:</span> <span class="n">BB</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">auto</span> <span class="o">*</span><span class="n">BO</span> <span class="o">=</span> <span class="n">dyn_cast</span><span class="o"><</span><span class="n">BinaryOperator</span><span class="o">></span><span class="p">(</span><span class="o">&</span><span class="n">I</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">BO</span><span class="p">)</span> <span class="k">continue</span><span class="p">;</span>
+
+ <span class="n">Value</span> <span class="o">*</span><span class="n">LHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+ <span class="n">Value</span> <span class="o">*</span><span class="n">RHS</span> <span class="o">=</span> <span class="n">BO</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">LHS</span> <span class="o">==</span> <span class="n">RHS</span><span class="p">)</span> <span class="k">continue</span><span class="p">;</span>
+
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This has all the benefits of using early exits for functions: it reduces nesting
+of the loop, it makes it easier to describe why the conditions are true, and it
+makes it obvious to the reader that there is no <tt class="docutils literal"><span class="pre">else</span></tt> coming up that they
+have to push context into their brain for. If a loop is large, this can be a
+big understandability win.</p>
+</div>
+<div class="section" id="don-t-use-else-after-a-return">
+<h4><a class="toc-backref" href="#id39">Don’t use <tt class="docutils literal"><span class="pre">else</span></tt> after a <tt class="docutils literal"><span class="pre">return</span></tt></a><a class="headerlink" href="#don-t-use-else-after-a-return" title="Permalink to this headline">¶</a></h4>
+<p>For similar reasons above (reduction of indentation and easier reading), please
+do not use <tt class="docutils literal"><span class="pre">'else'</span></tt> or <tt class="docutils literal"><span class="pre">'else</span> <span class="pre">if'</span></tt> after something that interrupts control
+flow — like <tt class="docutils literal"><span class="pre">return</span></tt>, <tt class="docutils literal"><span class="pre">break</span></tt>, <tt class="docutils literal"><span class="pre">continue</span></tt>, <tt class="docutils literal"><span class="pre">goto</span></tt>, etc. For
+example, this is <em>bad</em>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span><span class="o">:</span> <span class="p">{</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">QualType</span><span class="p">();</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="k">break</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">QualType</span><span class="p">();</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="k">break</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>It is better to write it like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span><span class="o">:</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">QualType</span><span class="p">();</span>
+ <span class="p">}</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">Error</span> <span class="o">=</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">QualType</span><span class="p">();</span>
+ <span class="p">}</span>
+ <span class="p">}</span>
+ <span class="k">break</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>Or better yet (in this case) as:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="sc">'J'</span><span class="o">:</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Signed</span><span class="p">)</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getsigjmp_bufType</span><span class="p">();</span>
+ <span class="k">else</span>
+ <span class="n">Type</span> <span class="o">=</span> <span class="n">Context</span><span class="p">.</span><span class="n">getjmp_bufType</span><span class="p">();</span>
+
+ <span class="k">if</span> <span class="p">(</span><span class="n">Type</span><span class="p">.</span><span class="n">isNull</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">Error</span> <span class="o">=</span> <span class="n">Signed</span> <span class="o">?</span> <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_sigjmp_buf</span> <span class="o">:</span>
+ <span class="n">ASTContext</span><span class="o">::</span><span class="n">GE_Missing_jmp_buf</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">QualType</span><span class="p">();</span>
+ <span class="p">}</span>
+ <span class="k">break</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The idea is to reduce indentation and the amount of code you have to keep track
+of when reading the code.</p>
+</div>
+<div class="section" id="turn-predicate-loops-into-predicate-functions">
+<h4><a class="toc-backref" href="#id40">Turn Predicate Loops into Predicate Functions</a><a class="headerlink" href="#turn-predicate-loops-into-predicate-functions" title="Permalink to this headline">¶</a></h4>
+<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 this
+sort of thing is:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">bool</span> <span class="n">FoundFoo</span> <span class="o">=</span> <span class="kc">false</span><span class="p">;</span>
+<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BarList</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">BarList</span><span class="p">[</span><span class="n">I</span><span class="p">]</span><span class="o">-></span><span class="n">isFoo</span><span class="p">())</span> <span class="p">{</span>
+ <span class="n">FoundFoo</span> <span class="o">=</span> <span class="kc">true</span><span class="p">;</span>
+ <span class="k">break</span><span class="p">;</span>
+ <span class="p">}</span>
+
+<span class="k">if</span> <span class="p">(</span><span class="n">FoundFoo</span><span class="p">)</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This sort of code is awkward to write, and is almost always a bad sign. Instead
+of this sort of loop, we strongly prefer to use a predicate function (which may
+be <a class="reference internal" href="#static">static</a>) that uses <a class="reference internal" href="#early-exits">early exits</a> to compute the predicate. We prefer the
+code to be structured like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">/// \returns true if the specified list has an element that is a foo.</span>
+<span class="k">static</span> <span class="kt">bool</span> <span class="n">containsFoo</span><span class="p">(</span><span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="n">Bar</span><span class="o">*></span> <span class="o">&</span><span class="n">List</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">E</span> <span class="o">=</span> <span class="n">List</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">List</span><span class="p">[</span><span class="n">I</span><span class="p">]</span><span class="o">-></span><span class="n">isFoo</span><span class="p">())</span>
+ <span class="k">return</span> <span class="kc">true</span><span class="p">;</span>
+ <span class="k">return</span> <span class="kc">false</span><span class="p">;</span>
+<span class="p">}</span>
+<span class="p">...</span>
+
+<span class="k">if</span> <span class="p">(</span><span class="n">containsFoo</span><span class="p">(</span><span class="n">BarList</span><span class="p">))</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>There are many reasons for doing this: it reduces indentation and factors out
+code which can often be shared by other code that checks for the same predicate.
+More importantly, it <em>forces you to pick a name</em> for the function, and forces
+you to write a comment for it. In this silly example, this doesn’t add much
+value. However, if the condition is complex, this can make it a lot easier for
+the reader to understand the code that queries for this predicate. Instead of
+being faced with the in-line details of how we check to see if the BarList
+contains a foo, we can trust the function name and continue reading with better
+locality.</p>
+</div>
+</div>
+<div class="section" id="the-low-level-issues">
+<h3><a class="toc-backref" href="#id41">The Low-Level Issues</a><a class="headerlink" href="#the-low-level-issues" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="name-types-functions-variables-and-enumerators-properly">
+<h4><a class="toc-backref" href="#id42">Name Types, Functions, Variables, and Enumerators Properly</a><a class="headerlink" href="#name-types-functions-variables-and-enumerators-properly" title="Permalink to this headline">¶</a></h4>
+<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 match
+the semantics and role of the underlying entities, within reason. Avoid
+abbreviations unless they are well known. After picking a good name, make sure
+to use consistent capitalization for the name, as inconsistency requires clients
+to either memorize the APIs or to look it up to find the exact spelling.</p>
+<p>In general, names should be in camel case (e.g. <tt class="docutils literal"><span class="pre">TextFileReader</span></tt> and
+<tt class="docutils literal"><span class="pre">isLValue()</span></tt>). Different kinds of declarations have different rules:</p>
+<ul>
+<li><p class="first"><strong>Type names</strong> (including classes, structs, enums, typedefs, etc) should be
+nouns and start with an upper-case letter (e.g. <tt class="docutils literal"><span class="pre">TextFileReader</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Variable names</strong> should be nouns (as they represent state). The name should
+be camel case, and start with an upper case letter (e.g. <tt class="docutils literal"><span class="pre">Leader</span></tt> or
+<tt class="docutils literal"><span class="pre">Boats</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Function names</strong> should be verb phrases (as they represent actions), and
+command-like function should be imperative. The name should be camel case,
+and start with a lower case letter (e.g. <tt class="docutils literal"><span class="pre">openFile()</span></tt> or <tt class="docutils literal"><span class="pre">isFoo()</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Enum declarations</strong> (e.g. <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">Foo</span> <span class="pre">{...}</span></tt>) are types, so they should
+follow the naming conventions for types. A common use for enums is as a
+discriminator for a union, or an indicator of a subclass. When an enum is
+used for something like this, it should have a <tt class="docutils literal"><span class="pre">Kind</span></tt> suffix
+(e.g. <tt class="docutils literal"><span class="pre">ValueKind</span></tt>).</p>
+</li>
+<li><p class="first"><strong>Enumerators</strong> (e.g. <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">{</span> <span class="pre">Foo,</span> <span class="pre">Bar</span> <span class="pre">}</span></tt>) and <strong>public member variables</strong>
+should start with an upper-case letter, just like types. Unless the
+enumerators are defined in their own small namespace or inside a class,
+enumerators should have a prefix corresponding to the enum declaration name.
+For example, <tt class="docutils literal"><span class="pre">enum</span> <span class="pre">ValueKind</span> <span class="pre">{</span> <span class="pre">...</span> <span class="pre">};</span></tt> may contain enumerators like
+<tt class="docutils literal"><span class="pre">VK_Argument</span></tt>, <tt class="docutils literal"><span class="pre">VK_BasicBlock</span></tt>, etc. Enumerators that are just
+convenience constants are exempt from the requirement for a prefix. For
+instance:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">enum</span> <span class="p">{</span>
+ <span class="n">MaxSize</span> <span class="o">=</span> <span class="mi">42</span><span class="p">,</span>
+ <span class="n">Density</span> <span class="o">=</span> <span class="mi">12</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</li>
+</ul>
+<p>As an exception, classes that mimic STL classes can have member names in STL’s
+style of lower-case words separated by underscores (e.g. <tt class="docutils literal"><span class="pre">begin()</span></tt>,
+<tt class="docutils literal"><span class="pre">push_back()</span></tt>, and <tt class="docutils literal"><span class="pre">empty()</span></tt>). Classes that provide multiple
+iterators should add a singular prefix to <tt class="docutils literal"><span class="pre">begin()</span></tt> and <tt class="docutils literal"><span class="pre">end()</span></tt>
+(e.g. <tt class="docutils literal"><span class="pre">global_begin()</span></tt> and <tt class="docutils literal"><span class="pre">use_begin()</span></tt>).</p>
+<p>Here are some examples of good and bad names:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">VehicleMaker</span> <span class="p">{</span>
+ <span class="p">...</span>
+ <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">F</span><span class="p">;</span> <span class="c1">// Bad -- abbreviation and non-descriptive.</span>
+ <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">Factory</span><span class="p">;</span> <span class="c1">// Better.</span>
+ <span class="n">Factory</span><span class="o"><</span><span class="n">Tire</span><span class="o">></span> <span class="n">TireFactory</span><span class="p">;</span> <span class="c1">// Even better -- if VehicleMaker has more than one</span>
+ <span class="c1">// kind of factories.</span>
+<span class="p">};</span>
+
+<span class="n">Vehicle</span> <span class="n">makeVehicle</span><span class="p">(</span><span class="n">VehicleType</span> <span class="n">Type</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">VehicleMaker</span> <span class="n">M</span><span class="p">;</span> <span class="c1">// Might be OK if having a short life-span.</span>
+ <span class="n">Tire</span> <span class="n">Tmp1</span> <span class="o">=</span> <span class="n">M</span><span class="p">.</span><span class="n">makeTire</span><span class="p">();</span> <span class="c1">// Bad -- 'Tmp1' provides no information.</span>
+ <span class="n">Light</span> <span class="n">Headlight</span> <span class="o">=</span> <span class="n">M</span><span class="p">.</span><span class="n">makeLight</span><span class="p">(</span><span class="s">"head"</span><span class="p">);</span> <span class="c1">// Good -- descriptive.</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="assert-liberally">
+<h4><a class="toc-backref" href="#id43">Assert Liberally</a><a class="headerlink" href="#assert-liberally" title="Permalink to this headline">¶</a></h4>
+<p>Use the “<tt class="docutils literal"><span class="pre">assert</span></tt>” macro to its fullest. Check all of your preconditions and
+assumptions, you never know when a bug (not necessarily even yours) might be
+caught early by an assertion, which reduces debugging time dramatically. The
+“<tt class="docutils literal"><span class="pre"><cassert></span></tt>” header file is probably already included by the header files you
+are using, so it doesn’t cost anything to use it.</p>
+<p>To further assist with debugging, make sure to put some kind of error message in
+the assertion statement, which is printed if the assertion is tripped. This
+helps the poor debugger make sense of why an assertion is being made and
+enforced, and hopefully what to do about it. Here is one complete example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kr">inline</span> <span class="n">Value</span> <span class="o">*</span><span class="n">getOperand</span><span class="p">(</span><span class="kt">unsigned</span> <span class="n">I</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">I</span> <span class="o"><</span> <span class="n">Operands</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"getOperand() out of range!"</span><span class="p">);</span>
+ <span class="k">return</span> <span class="n">Operands</span><span class="p">[</span><span class="n">I</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Here are more examples:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="n">Ty</span><span class="o">-></span><span class="n">isPointerType</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Can't allocate a non-pointer type!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">((</span><span class="n">Opcode</span> <span class="o">==</span> <span class="n">Shl</span> <span class="o">||</span> <span class="n">Opcode</span> <span class="o">==</span> <span class="n">Shr</span><span class="p">)</span> <span class="o">&&</span> <span class="s">"ShiftInst Opcode invalid!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">idx</span> <span class="o"><</span> <span class="n">getNumSuccessors</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Successor # out of range!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">V1</span><span class="p">.</span><span class="n">getType</span><span class="p">()</span> <span class="o">==</span> <span class="n">V2</span><span class="p">.</span><span class="n">getType</span><span class="p">()</span> <span class="o">&&</span> <span class="s">"Constant types must be identical!"</span><span class="p">);</span>
+
+<span class="n">assert</span><span class="p">(</span><span class="n">isa</span><span class="o"><</span><span class="n">PHINode</span><span class="o">></span><span class="p">(</span><span class="n">Succ</span><span class="o">-></span><span class="n">front</span><span class="p">())</span> <span class="o">&&</span> <span class="s">"Only works on PHId BBs!"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>You get the idea.</p>
+<p>In the past, asserts were used to indicate a piece of code that should not be
+reached. These were typically of the form:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="mi">0</span> <span class="o">&&</span> <span class="s">"Invalid radix for integer literal"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>This has a few issues, the main one being that some compilers might not
+understand the assertion, or warn about a missing return in builds where
+assertions are compiled out.</p>
+<p>Today, we have something much better: <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">llvm_unreachable</span><span class="p">(</span><span class="s">"Invalid radix for integer literal"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>When assertions are enabled, this will print the message if it’s ever reached
+and then exit the program. When assertions are disabled (i.e. in release
+builds), <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt> becomes a hint to compilers to skip generating
+code for this branch. If the compiler does not support this, it will fall back
+to the “abort” implementation.</p>
+<p>Neither assertions or <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt> will abort the program on a release
+build. If the error condition can be triggered by user input then the
+recoverable error mechanism described in <a class="reference internal" href="ProgrammersManual.html"><em>LLVM Programmer’s Manual</em></a> should be
+used instead. In cases where this is not practical, <tt class="docutils literal"><span class="pre">report_fatal_error</span></tt> may
+be used.</p>
+<p>Another issue is that values used only by assertions will produce an “unused
+value” warning when assertions are disabled. For example, this code will warn:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">unsigned</span> <span class="n">Size</span> <span class="o">=</span> <span class="n">V</span><span class="p">.</span><span class="n">size</span><span class="p">();</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">Size</span> <span class="o">></span> <span class="mi">42</span> <span class="o">&&</span> <span class="s">"Vector smaller than it should be"</span><span class="p">);</span>
+
+<span class="kt">bool</span> <span class="n">NewToSet</span> <span class="o">=</span> <span class="n">Myset</span><span class="p">.</span><span class="n">insert</span><span class="p">(</span><span class="n">Value</span><span class="p">);</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">NewToSet</span> <span class="o">&&</span> <span class="s">"The value shouldn't be in the set yet"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>These are two interesting different cases. In the first case, the call to
+<tt class="docutils literal"><span class="pre">V.size()</span></tt> is only useful for the assert, and we don’t want it executed when
+assertions are disabled. Code like this should move the call into the assert
+itself. In the second case, the side effects of the call must happen whether
+the assert is enabled or not. In this case, the value should be cast to void to
+disable the warning. To be specific, it is preferred to write the code like
+this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">assert</span><span class="p">(</span><span class="n">V</span><span class="p">.</span><span class="n">size</span><span class="p">()</span> <span class="o">></span> <span class="mi">42</span> <span class="o">&&</span> <span class="s">"Vector smaller than it should be"</span><span class="p">);</span>
+
+<span class="kt">bool</span> <span class="n">NewToSet</span> <span class="o">=</span> <span class="n">Myset</span><span class="p">.</span><span class="n">insert</span><span class="p">(</span><span class="n">Value</span><span class="p">);</span> <span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="n">NewToSet</span><span class="p">;</span>
+<span class="n">assert</span><span class="p">(</span><span class="n">NewToSet</span> <span class="o">&&</span> <span class="s">"The value shouldn't be in the set yet"</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="do-not-use-using-namespace-std">
+<h4><a class="toc-backref" href="#id44">Do Not Use <tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span> <span class="pre">std</span></tt></a><a class="headerlink" href="#do-not-use-using-namespace-std" title="Permalink to this headline">¶</a></h4>
+<p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
+namespace with an “<tt class="docutils literal"><span class="pre">std::</span></tt>” prefix, rather than rely on “<tt class="docutils literal"><span class="pre">using</span> <span class="pre">namespace</span>
+<span class="pre">std;</span></tt>”.</p>
+<p>In header files, adding a <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span> <span class="pre">XXX'</span></tt> directive pollutes the
+namespace of any source file that <tt class="docutils literal"><span class="pre">#include</span></tt>s the header. This is clearly a
+bad thing.</p>
+<p>In implementation files (e.g. <tt class="docutils literal"><span class="pre">.cpp</span></tt> files), the rule is more of a stylistic
+rule, but is still important. Basically, using explicit namespace prefixes
+makes the code <strong>clearer</strong>, because it is immediately obvious what facilities
+are being used and where they are coming from. And <strong>more portable</strong>, because
+namespace clashes cannot occur between LLVM code and other namespaces. The
+portability rule is important because different standard library implementations
+expose different symbols (potentially ones they shouldn’t), and future revisions
+to the C++ standard will add more symbols to the <tt class="docutils literal"><span class="pre">std</span></tt> namespace. As such, we
+never use <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span> <span class="pre">std;'</span></tt> in LLVM.</p>
+<p>The exception to the general rule (i.e. it’s not an exception for the <tt class="docutils literal"><span class="pre">std</span></tt>
+namespace) is for implementation files. For example, all of the code in the
+LLVM project implements code that lives in the ‘llvm’ namespace. As such, it is
+ok, and actually clearer, for the <tt class="docutils literal"><span class="pre">.cpp</span></tt> files to have a <tt class="docutils literal"><span class="pre">'using</span> <span class="pre">namespace</span>
+<span class="pre">llvm;'</span></tt> directive at the top, after the <tt class="docutils literal"><span class="pre">#include</span></tt>s. This reduces
+indentation in the body of the file for source editors that indent based on
+braces, and keeps the conceptual context cleaner. The general form of this rule
+is that any <tt class="docutils literal"><span class="pre">.cpp</span></tt> file that implements code in any namespace may use that
+namespace (and its parents’), but should not use any others.</p>
+</div>
+<div class="section" id="provide-a-virtual-method-anchor-for-classes-in-headers">
+<h4><a class="toc-backref" href="#id45">Provide a Virtual Method Anchor for Classes in Headers</a><a class="headerlink" href="#provide-a-virtual-method-anchor-for-classes-in-headers" title="Permalink to this headline">¶</a></h4>
+<p>If a class is defined in a header file and has a vtable (either it has virtual
+methods or it derives from classes with virtual methods), it must always have at
+least one out-of-line virtual method in the class. Without this, the compiler
+will copy the vtable and RTTI into every <tt class="docutils literal"><span class="pre">.o</span></tt> file that <tt class="docutils literal"><span class="pre">#include</span></tt>s the
+header, bloating <tt class="docutils literal"><span class="pre">.o</span></tt> file sizes and increasing link times.</p>
+</div>
+<div class="section" id="don-t-use-default-labels-in-fully-covered-switches-over-enumerations">
+<h4><a class="toc-backref" href="#id46">Don’t use default labels in fully covered switches over enumerations</a><a class="headerlink" href="#don-t-use-default-labels-in-fully-covered-switches-over-enumerations" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">-Wswitch</span></tt> warns if a switch, without a default label, over an enumeration
+does not cover every enumeration value. If you write a default label on a fully
+covered switch over an enumeration then the <tt class="docutils literal"><span class="pre">-Wswitch</span></tt> warning won’t fire
+when new elements are added to that enumeration. To help avoid adding these
+kinds of defaults, Clang has the warning <tt class="docutils literal"><span class="pre">-Wcovered-switch-default</span></tt> which is
+off by default but turned on when building LLVM with a version of Clang that
+supports the warning.</p>
+<p>A knock-on effect of this stylistic requirement is that when building LLVM with
+GCC you may get warnings related to “control may reach end of non-void function”
+if you return from each case of a covered switch-over-enum because GCC assumes
+that the enum expression may take any representable value, not just those of
+individual enumerators. To suppress this warning, use <tt class="docutils literal"><span class="pre">llvm_unreachable</span></tt> after
+the switch.</p>
+</div>
+<div class="section" id="use-range-based-for-loops-wherever-possible">
+<h4><a class="toc-backref" href="#id47">Use range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops wherever possible</a><a class="headerlink" href="#use-range-based-for-loops-wherever-possible" title="Permalink to this headline">¶</a></h4>
+<p>The introduction of range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops in C++11 means that explicit
+manipulation of iterators is rarely necessary. We use range-based <tt class="docutils literal"><span class="pre">for</span></tt>
+loops wherever possible for all newly added code. For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">BasicBlock</span> <span class="o">*</span><span class="n">BB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">Instruction</span> <span class="o">&</span><span class="n">I</span> <span class="o">:</span> <span class="o">*</span><span class="n">BB</span><span class="p">)</span>
+ <span class="p">...</span> <span class="n">use</span> <span class="n">I</span> <span class="p">...</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="don-t-evaluate-end-every-time-through-a-loop">
+<h4><a class="toc-backref" href="#id48">Don’t evaluate <tt class="docutils literal"><span class="pre">end()</span></tt> every time through a loop</a><a class="headerlink" href="#don-t-evaluate-end-every-time-through-a-loop" title="Permalink to this headline">¶</a></h4>
+<p>In cases where range-based <tt class="docutils literal"><span class="pre">for</span></tt> loops can’t be used and it is necessary
+to write an explicit iterator-based loop, pay close attention to whether
+<tt class="docutils literal"><span class="pre">end()</span></tt> is re-evaluted on each loop iteration. One common mistake is to
+write a loop in this style:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">BasicBlock</span> <span class="o">*</span><span class="n">BB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="n">I</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+ <span class="p">...</span> <span class="n">use</span> <span class="n">I</span> <span class="p">...</span>
+</pre></div>
+</div>
+<p>The problem with this construct is that it evaluates “<tt class="docutils literal"><span class="pre">BB->end()</span></tt>” every time
+through the loop. Instead of writing the loop like this, we strongly prefer
+loops to be written so that they evaluate it once before the loop starts. A
+convenient way to do this is like so:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">BasicBlock</span> <span class="o">*</span><span class="n">BB</span> <span class="o">=</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="n">I</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">begin</span><span class="p">(),</span> <span class="n">E</span> <span class="o">=</span> <span class="n">BB</span><span class="o">-></span><span class="n">end</span><span class="p">();</span> <span class="n">I</span> <span class="o">!=</span> <span class="n">E</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span>
+ <span class="p">...</span> <span class="n">use</span> <span class="n">I</span> <span class="p">...</span>
+</pre></div>
+</div>
+<p>The observant may quickly point out that these two loops may have different
+semantics: if the container (a basic block in this case) is being mutated, then
+“<tt class="docutils literal"><span class="pre">BB->end()</span></tt>” may change its value every time through the loop and the second
+loop may not in fact be correct. If you actually do depend on this behavior,
+please write the loop in the first form and add a comment indicating that you
+did it intentionally.</p>
+<p>Why do we prefer the second form (when correct)? Writing the loop in the first
+form has two problems. First it may be less efficient than evaluating it at the
+start of the loop. In this case, the cost is probably minor — a few extra
+loads every time through the loop. However, if the base expression is more
+complex, then the cost can rise quickly. I’ve seen loops where the end
+expression was actually something like: “<tt class="docutils literal"><span class="pre">SomeMap[X]->end()</span></tt>” and map lookups
+really aren’t cheap. By writing it in the second form consistently, you
+eliminate the issue entirely and don’t even have to think about it.</p>
+<p>The second (even bigger) issue is that writing the loop in the first form hints
+to the reader that the loop is mutating the container (a fact that a comment
+would handily confirm!). If you write the loop in the second form, it is
+immediately obvious without even looking at the body of the loop that the
+container isn’t being modified, which makes it easier to read the code and
+understand what it does.</p>
+<p>While the second form of the loop is a few extra keystrokes, we do strongly
+prefer it.</p>
+</div>
+<div class="section" id="include-iostream-is-forbidden">
+<h4><a class="toc-backref" href="#id49"><tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> is Forbidden</a><a class="headerlink" href="#include-iostream-is-forbidden" title="Permalink to this headline">¶</a></h4>
+<p>The use of <tt class="docutils literal"><span class="pre">#include</span> <span class="pre"><iostream></span></tt> in library files is hereby <strong>forbidden</strong>,
+because many common implementations transparently inject a <a class="reference internal" href="#static-constructor">static constructor</a>
+into every translation unit that includes it.</p>
+<p>Note that using the other stream headers (<tt class="docutils literal"><span class="pre"><sstream></span></tt> for example) is not
+problematic in this regard — just <tt class="docutils literal"><span class="pre"><iostream></span></tt>. However, <tt class="docutils literal"><span class="pre">raw_ostream</span></tt>
+provides various APIs that are better performing for almost every use than
+<tt class="docutils literal"><span class="pre">std::ostream</span></tt> style APIs.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">New code should always use <a class="reference internal" href="#raw-ostream">raw_ostream</a> for writing, or the
+<tt class="docutils literal"><span class="pre">llvm::MemoryBuffer</span></tt> API for reading files.</p>
+</div>
+</div>
+<div class="section" id="use-raw-ostream">
+<span id="raw-ostream"></span><h4><a class="toc-backref" href="#id50">Use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt></a><a class="headerlink" href="#use-raw-ostream" title="Permalink to this headline">¶</a></h4>
+<p>LLVM includes a lightweight, simple, and efficient stream implementation in
+<tt class="docutils literal"><span class="pre">llvm/Support/raw_ostream.h</span></tt>, which provides all of the common features of
+<tt class="docutils literal"><span class="pre">std::ostream</span></tt>. All new code should use <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> instead of
+<tt class="docutils literal"><span class="pre">ostream</span></tt>.</p>
+<p>Unlike <tt class="docutils literal"><span class="pre">std::ostream</span></tt>, <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> is not a template and can be forward
+declared as <tt class="docutils literal"><span class="pre">class</span> <span class="pre">raw_ostream</span></tt>. Public headers should generally not include
+the <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> header, but use forward declarations and constant references
+to <tt class="docutils literal"><span class="pre">raw_ostream</span></tt> instances.</p>
+</div>
+<div class="section" id="avoid-std-endl">
+<h4><a class="toc-backref" href="#id51">Avoid <tt class="docutils literal"><span class="pre">std::endl</span></tt></a><a class="headerlink" href="#avoid-std-endl" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">std::endl</span></tt> modifier, when used with <tt class="docutils literal"><span class="pre">iostreams</span></tt> outputs a newline to
+the output stream specified. In addition to doing this, however, it also
+flushes the output stream. In other words, these are equivalent:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">std</span><span class="o">::</span><span class="n">cout</span> <span class="o"><<</span> <span class="n">std</span><span class="o">::</span><span class="n">endl</span><span class="p">;</span>
+<span class="n">std</span><span class="o">::</span><span class="n">cout</span> <span class="o"><<</span> <span class="sc">'\n'</span> <span class="o"><<</span> <span class="n">std</span><span class="o">::</span><span class="n">flush</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>Most of the time, you probably have no reason to flush the output stream, so
+it’s better to use a literal <tt class="docutils literal"><span class="pre">'\n'</span></tt>.</p>
+</div>
+<div class="section" id="don-t-use-inline-when-defining-a-function-in-a-class-definition">
+<h4><a class="toc-backref" href="#id52">Don’t use <tt class="docutils literal"><span class="pre">inline</span></tt> when defining a function in a class definition</a><a class="headerlink" href="#don-t-use-inline-when-defining-a-function-in-a-class-definition" title="Permalink to this headline">¶</a></h4>
+<p>A member function defined in a class definition is implicitly inline, so don’t
+put the <tt class="docutils literal"><span class="pre">inline</span></tt> keyword in this case.</p>
+<p>Don’t:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="kr">inline</span> <span class="kt">void</span> <span class="n">bar</span><span class="p">()</span> <span class="p">{</span>
+ <span class="c1">// ...</span>
+ <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>Do:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="kt">void</span> <span class="n">bar</span><span class="p">()</span> <span class="p">{</span>
+ <span class="c1">// ...</span>
+ <span class="p">}</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="microscopic-details">
+<h3><a class="toc-backref" href="#id53">Microscopic Details</a><a class="headerlink" href="#microscopic-details" title="Permalink to this headline">¶</a></h3>
+<p>This section describes preferred low-level formatting guidelines along with
+reasoning on why we prefer them.</p>
+<div class="section" id="spaces-before-parentheses">
+<h4><a class="toc-backref" href="#id54">Spaces Before Parentheses</a><a class="headerlink" href="#spaces-before-parentheses" title="Permalink to this headline">¶</a></h4>
+<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
+macros. For example, this is good:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">X</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">I</span> <span class="o">!=</span> <span class="mi">100</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">while</span> <span class="p">(</span><span class="n">LLVMRocks</span><span class="p">)</span> <span class="p">...</span>
+
+<span class="n">somefunc</span><span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+<span class="n">assert</span><span class="p">(</span><span class="mi">3</span> <span class="o">!=</span> <span class="mi">4</span> <span class="o">&&</span> <span class="s">"laws of math are failing me"</span><span class="p">);</span>
+
+<span class="n">A</span> <span class="o">=</span> <span class="n">foo</span><span class="p">(</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span><span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>and this is bad:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span><span class="p">(</span><span class="n">X</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">for</span><span class="p">(</span><span class="n">I</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">I</span> <span class="o">!=</span> <span class="mi">100</span><span class="p">;</span> <span class="o">++</span><span class="n">I</span><span class="p">)</span> <span class="p">...</span>
+<span class="k">while</span><span class="p">(</span><span class="n">LLVMRocks</span><span class="p">)</span> <span class="p">...</span>
+
+<span class="n">somefunc</span> <span class="p">(</span><span class="mi">42</span><span class="p">);</span>
+<span class="n">assert</span> <span class="p">(</span><span class="mi">3</span> <span class="o">!=</span> <span class="mi">4</span> <span class="o">&&</span> <span class="s">"laws of math are failing me"</span><span class="p">);</span>
+
+<span class="n">A</span> <span class="o">=</span> <span class="n">foo</span> <span class="p">(</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span> <span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The reason for doing this is not completely arbitrary. This style makes control
+flow operators stand out more, and makes expressions flow better. The function
+call operator binds very tightly as a postfix operator. Putting a space after a
+function name (as in the last example) makes it appear that the code might bind
+the arguments of the left-hand-side of a binary operator with the argument list
+of a function and the name of the right side. More specifically, it is easy to
+misread the “<tt class="docutils literal"><span class="pre">A</span></tt>” example as:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">A</span> <span class="o">=</span> <span class="n">foo</span> <span class="p">((</span><span class="mi">42</span><span class="p">,</span> <span class="mi">92</span><span class="p">)</span> <span class="o">+</span> <span class="n">bar</span><span class="p">)</span> <span class="p">(</span><span class="n">X</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>when skimming through the code. By avoiding a space in a function, we avoid
+this misinterpretation.</p>
+</div>
+<div class="section" id="prefer-preincrement">
+<h4><a class="toc-backref" href="#id55">Prefer Preincrement</a><a class="headerlink" href="#prefer-preincrement" title="Permalink to this headline">¶</a></h4>
+<p>Hard fast rule: Preincrement (<tt class="docutils literal"><span class="pre">++X</span></tt>) may be no slower than postincrement
+(<tt class="docutils literal"><span class="pre">X++</span></tt>) and could very well be a lot faster than it. Use preincrementation
+whenever possible.</p>
+<p>The semantics of postincrement include making a copy of the value being
+incremented, returning it, and then preincrementing the “work value”. For
+primitive types, this isn’t a big deal. But for iterators, it can be a huge
+issue (for example, some iterators contains stack and set objects in them...
+copying an iterator could invoke the copy ctor’s of these as well). In general,
+get in the habit of always using preincrement, and you won’t have a problem.</p>
+</div>
+<div class="section" id="namespace-indentation">
+<h4><a class="toc-backref" href="#id56">Namespace Indentation</a><a class="headerlink" href="#namespace-indentation" title="Permalink to this headline">¶</a></h4>
+<p>In general, we strive to reduce indentation wherever possible. This is useful
+because we want code to <a class="reference internal" href="#fit-into-80-columns">fit into 80 columns</a> without wrapping horribly, but
+also because it makes it easier to understand the code. To facilitate this and
+avoid some insanely deep nesting on occasion, don’t indent namespaces. If it
+helps readability, feel free to add a comment indicating what namespace is
+being closed by a <tt class="docutils literal"><span class="pre">}</span></tt>. For example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="n">llvm</span> <span class="p">{</span>
+<span class="k">namespace</span> <span class="n">knowledge</span> <span class="p">{</span>
+
+<span class="c1">/// This class represents things that Smith can have an intimate</span>
+<span class="c1">/// understanding of and contains the data associated with it.</span>
+<span class="k">class</span> <span class="nc">Grokable</span> <span class="p">{</span>
+<span class="p">...</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="k">explicit</span> <span class="n">Grokable</span><span class="p">()</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
+ <span class="k">virtual</span> <span class="o">~</span><span class="n">Grokable</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+
+ <span class="p">...</span>
+
+<span class="p">};</span>
+
+<span class="p">}</span> <span class="c1">// end namespace knowledge</span>
+<span class="p">}</span> <span class="c1">// end namespace llvm</span>
+</pre></div>
+</div>
+<p>Feel free to skip the closing comment when the namespace being closed is
+obvious for any reason. For example, the outer-most namespace in a header file
+is rarely a source of confusion. But namespaces both anonymous and named in
+source files that are being closed half way through the file probably could use
+clarification.</p>
+</div>
+<div class="section" id="anonymous-namespaces">
+<span id="static"></span><h4><a class="toc-backref" href="#id57">Anonymous Namespaces</a><a class="headerlink" href="#anonymous-namespaces" title="Permalink to this headline">¶</a></h4>
+<p>After talking about namespaces in general, you may be wondering about anonymous
+namespaces in particular. Anonymous namespaces are a great language feature
+that tells the C++ compiler that the contents of the namespace are only visible
+within the current translation unit, allowing more aggressive optimization and
+eliminating the possibility of symbol name collisions. Anonymous namespaces are
+to C++ as “static” is to C functions and global variables. While “<tt class="docutils literal"><span class="pre">static</span></tt>”
+is available in C++, anonymous namespaces are more general: they can make entire
+classes private to a file.</p>
+<p>The problem with anonymous namespaces is that they naturally want to encourage
+indentation of their body, and they reduce locality of reference: if you see a
+random function definition in a C++ file, it is easy to see if it is marked
+static, but seeing if it is in an anonymous namespace requires scanning a big
+chunk of the file.</p>
+<p>Because of this, we have a simple guideline: make anonymous namespaces as small
+as possible, and only use them for class declarations. For example, this is
+good:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="p">{</span>
+<span class="k">class</span> <span class="nc">StringSort</span> <span class="p">{</span>
+<span class="p">...</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="n">StringSort</span><span class="p">(...)</span>
+ <span class="kt">bool</span> <span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+<span class="p">};</span>
+<span class="p">}</span> <span class="c1">// end anonymous namespace</span>
+
+<span class="k">static</span> <span class="kt">void</span> <span class="n">runHelper</span><span class="p">()</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="kt">bool</span> <span class="n">StringSort</span><span class="o">::</span><span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This is bad:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="p">{</span>
+
+<span class="k">class</span> <span class="nc">StringSort</span> <span class="p">{</span>
+<span class="p">...</span>
+<span class="k">public</span><span class="o">:</span>
+ <span class="n">StringSort</span><span class="p">(...)</span>
+ <span class="kt">bool</span> <span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+<span class="p">};</span>
+
+<span class="kt">void</span> <span class="n">runHelper</span><span class="p">()</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="kt">bool</span> <span class="n">StringSort</span><span class="o">::</span><span class="k">operator</span><span class="o"><</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">RHS</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+
+<span class="p">}</span> <span class="c1">// end anonymous namespace</span>
+</pre></div>
+</div>
+<p>This is bad specifically because if you’re looking at “<tt class="docutils literal"><span class="pre">runHelper</span></tt>” in the middle
+of a large C++ file, that you have no immediate way to tell if it is local to
+the file. When it is marked static explicitly, this is immediately obvious.
+Also, there is no reason to enclose the definition of “<tt class="docutils literal"><span class="pre">operator<</span></tt>” in the
+namespace just because it was declared there.</p>
+</div>
+</div>
+</div>
+<div class="section" id="see-also">
+<h2><a class="toc-backref" href="#id58">See Also</a><a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>A lot of these comments and recommendations have been culled from other sources.
+Two particularly important books for our work are:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective C++</a>
+by Scott Meyers. Also interesting and useful are “More Effective C++” and
+“Effective STL” by the same author.</li>
+<li><a class="reference external" href="https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620">Large-Scale C++ Software Design</a>
+by John Lakos</li>
+</ol>
+<p>If you get some free time, and you haven’t read them: do so, you might learn
+something.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="CommandLine.html" title="CommandLine 2.0 Library Manual"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="Atomics.html" title="LLVM Atomic Instructions and Concurrency Guide"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/FileCheck.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/FileCheck.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/FileCheck.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/FileCheck.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,616 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>FileCheck - Flexible pattern matching file verifier — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="tblgen - Target Description To C++ Code Generator" href="tblgen.html" />
+ <link rel="prev" title="llvm-bcanalyzer - LLVM bitcode analyzer" href="llvm-bcanalyzer.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="filecheck-flexible-pattern-matching-file-verifier">
+<h1>FileCheck - Flexible pattern matching file verifier<a class="headerlink" href="#filecheck-flexible-pattern-matching-file-verifier" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">FileCheck</strong> <em>match-filename</em> [<em>–check-prefix=XXX</em>] [<em>–strict-whitespace</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">FileCheck</strong> reads two files (one from standard input, and one
+specified on the command line) and uses one to verify the other. This
+behavior is particularly useful for the testsuite, which wants to verify that
+the output of some tool (e.g. <strong class="program">llc</strong>) contains the expected information
+(for example, a movsd from esp or whatever is interesting). This is similar to
+using <strong class="program">grep</strong>, but it is optimized for matching multiple different
+inputs in one file in a specific order.</p>
+<p>The <tt class="docutils literal"><span class="pre">match-filename</span></tt> file specifies the file that contains the patterns to
+match. The file to verify is read from standard input unless the
+<a class="reference internal" href="#cmdoption--input-file"><em class="xref std std-option">--input-file</em></a> option is used.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--check-prefix">
+<tt class="descname">--check-prefix</tt><tt class="descclassname"> prefix</tt><a class="headerlink" href="#cmdoption--check-prefix" title="Permalink to this definition">¶</a></dt>
+<dd><p>FileCheck searches the contents of <tt class="docutils literal"><span class="pre">match-filename</span></tt> for patterns to
+match. By default, these patterns are prefixed with “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>”.
+If you’d like to use a different prefix (e.g. because the same input
+file is checking multiple different tool or options), the
+<a class="reference internal" href="#cmdoption--check-prefix"><em class="xref std std-option">--check-prefix</em></a> argument allows you to specify one or more
+prefixes to match. Multiple prefixes are useful for tests which might
+change for different run options, but most lines remain the same.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--check-prefixes">
+<tt class="descname">--check-prefixes</tt><tt class="descclassname"> prefix1,prefix2,...</tt><a class="headerlink" href="#cmdoption--check-prefixes" title="Permalink to this definition">¶</a></dt>
+<dd><p>An alias of <a class="reference internal" href="#cmdoption--check-prefix"><em class="xref std std-option">--check-prefix</em></a> that allows multiple prefixes to be
+specified as a comma separated list.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--input-file">
+<tt class="descname">--input-file</tt><tt class="descclassname"> filename</tt><a class="headerlink" href="#cmdoption--input-file" title="Permalink to this definition">¶</a></dt>
+<dd><p>File to check (defaults to stdin).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--match-full-lines">
+<tt class="descname">--match-full-lines</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--match-full-lines" title="Permalink to this definition">¶</a></dt>
+<dd><p>By default, FileCheck allows matches of anywhere on a line. This
+option will require all positive matches to cover an entire
+line. Leading and trailing whitespace is ignored, unless
+<a class="reference internal" href="#cmdoption--strict-whitespace"><em class="xref std std-option">--strict-whitespace</em></a> is also specified. (Note: negative
+matches from <tt class="docutils literal"><span class="pre">CHECK-NOT</span></tt> are not affected by this option!)</p>
+<p>Passing this option is equivalent to inserting <tt class="docutils literal"><span class="pre">{{^</span> <span class="pre">*}}</span></tt> or
+<tt class="docutils literal"><span class="pre">{{^}}</span></tt> before, and <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">*$}}</span></tt> or <tt class="docutils literal"><span class="pre">{{$}}</span></tt> after every positive
+check pattern.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--strict-whitespace">
+<tt class="descname">--strict-whitespace</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--strict-whitespace" title="Permalink to this definition">¶</a></dt>
+<dd><p>By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+tabs) which causes it to ignore these differences (a space will match a tab).
+The <a class="reference internal" href="#cmdoption--strict-whitespace"><em class="xref std std-option">--strict-whitespace</em></a> argument disables this behavior. End-of-line
+sequences are canonicalized to UNIX-style <tt class="docutils literal"><span class="pre">\n</span></tt> in all modes.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--implicit-check-not">
+<tt class="descname">--implicit-check-not</tt><tt class="descclassname"> check-pattern</tt><a class="headerlink" href="#cmdoption--implicit-check-not" title="Permalink to this definition">¶</a></dt>
+<dd><p>Adds implicit negative checks for the specified patterns between positive
+checks. The option allows writing stricter tests without stuffing them with
+<tt class="docutils literal"><span class="pre">CHECK-NOT</span></tt>s.</p>
+<p>For example, “<tt class="docutils literal"><span class="pre">--implicit-check-not</span> <span class="pre">warning:</span></tt>” can be useful when testing
+diagnostic messages from tools that don’t have an option similar to <tt class="docutils literal"><span class="pre">clang</span>
+<span class="pre">-verify</span></tt>. With this option FileCheck will verify that input does not contain
+warnings not covered by any <tt class="docutils literal"><span class="pre">CHECK:</span></tt> patterns.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--dump-input-on-failure">
+<tt class="descname">--dump-input-on-failure</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--dump-input-on-failure" title="Permalink to this definition">¶</a></dt>
+<dd><p>When the check fails, dump all of the original input.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-var-scope">
+<tt class="descname">--enable-var-scope</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-var-scope" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enables scope for regex variables.</p>
+<p>Variables with names that start with <tt class="docutils literal"><span class="pre">$</span></tt> are considered global and
+remain set throughout the file.</p>
+<p>All other variables get undefined after each encountered <tt class="docutils literal"><span class="pre">CHECK-LABEL</span></tt>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-D">
+<tt class="descname">-D</tt><tt class="descclassname"><VAR=VALUE></tt><a class="headerlink" href="#cmdoption-D" title="Permalink to this definition">¶</a></dt>
+<dd><p>Sets a filecheck variable <tt class="docutils literal"><span class="pre">VAR</span></tt> with value <tt class="docutils literal"><span class="pre">VALUE</span></tt> that can be used in
+<tt class="docutils literal"><span class="pre">CHECK:</span></tt> lines.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-version">
+<tt class="descname">-version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the version number of this program.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print directive pattern matches.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-vv">
+<tt class="descname">-vv</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-vv" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print information helpful in diagnosing internal FileCheck issues, such as
+discarded overlapping <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> matches, implicit EOF pattern matches,
+and <tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt> patterns that do not have matches. Implies <tt class="docutils literal"><span class="pre">-v</span></tt>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--allow-deprecated-dag-overlap">
+<tt class="descname">--allow-deprecated-dag-overlap</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--allow-deprecated-dag-overlap" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable overlapping among matches in a group of consecutive <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>
+directives. This option is deprecated and is only provided for convenience
+as old tests are migrated to the new non-overlapping <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>
+implementation.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">FileCheck</strong> verifies that the file matches the expected contents,
+it exits with 0. Otherwise, if not, or if an error occurs, it will exit with a
+non-zero value.</p>
+</div>
+<div class="section" id="tutorial">
+<h2>TUTORIAL<a class="headerlink" href="#tutorial" title="Permalink to this headline">¶</a></h2>
+<p>FileCheck is typically used from LLVM regression tests, being invoked on the RUN
+line of the test. A simple example of using FileCheck from a RUN line looks
+like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s</span>
+</pre></div>
+</div>
+<p>This syntax says to pipe the current file (“<tt class="docutils literal"><span class="pre">%s</span></tt>”) into <tt class="docutils literal"><span class="pre">llvm-as</span></tt>, pipe
+that into <tt class="docutils literal"><span class="pre">llc</span></tt>, then pipe the output of <tt class="docutils literal"><span class="pre">llc</span></tt> into <tt class="docutils literal"><span class="pre">FileCheck</span></tt>. This
+means that FileCheck will be verifying its standard input (the llc output)
+against the filename argument specified (the original <tt class="docutils literal"><span class="pre">.ll</span></tt> file specified by
+“<tt class="docutils literal"><span class="pre">%s</span></tt>”). To see how this works, let’s look at the rest of the <tt class="docutils literal"><span class="pre">.ll</span></tt> file
+(after the RUN line):</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="kt">void</span> <span class="vg">@sub1</span><span class="p">(</span><span class="k">i32</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%v</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK: sub1:</span>
+<span class="c">; CHECK: subl</span>
+ <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i32</span> <span class="vg">@llvm.atomic.load.sub.i32.p0i32</span><span class="p">(</span><span class="k">i32</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%v</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="kt">void</span> <span class="vg">@inc4</span><span class="p">(</span><span class="k">i64</span><span class="p">*</span> <span class="nv">%p</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK: inc4:</span>
+<span class="c">; CHECK: incq</span>
+ <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="k">i64</span> <span class="vg">@llvm.atomic.load.add.i64.p0i64</span><span class="p">(</span><span class="k">i64</span><span class="p">*</span> <span class="nv">%p</span><span class="p">,</span> <span class="k">i64</span> <span class="m">1</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Here you can see some “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines specified in comments. Now you can
+see how the file is piped into <tt class="docutils literal"><span class="pre">llvm-as</span></tt>, then <tt class="docutils literal"><span class="pre">llc</span></tt>, and the machine code
+output is what we are verifying. FileCheck checks the machine code output to
+verify that it matches what the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines specify.</p>
+<p>The syntax of the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines is very simple: they are fixed strings that
+must occur in order. FileCheck defaults to ignoring horizontal whitespace
+differences (e.g. a space is allowed to match a tab) but otherwise, the contents
+of the “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” line is required to match some thing in the test file exactly.</p>
+<p>One nice thing about FileCheck (compared to grep) is that it allows merging
+test cases together into logical groups. For example, because the test above
+is checking for the “<tt class="docutils literal"><span class="pre">sub1:</span></tt>” and “<tt class="docutils literal"><span class="pre">inc4:</span></tt>” labels, it will not match
+unless there is a “<tt class="docutils literal"><span class="pre">subl</span></tt>” in between those labels. If it existed somewhere
+else in the file, that would not count: “<tt class="docutils literal"><span class="pre">grep</span> <span class="pre">subl</span></tt>” matches if “<tt class="docutils literal"><span class="pre">subl</span></tt>”
+exists anywhere in the file.</p>
+<div class="section" id="the-filecheck-check-prefix-option">
+<h3>The FileCheck -check-prefix option<a class="headerlink" href="#the-filecheck-check-prefix-option" title="Permalink to this headline">¶</a></h3>
+<p>The FileCheck <cite>-check-prefix</cite> option allows multiple test
+configurations to be driven from one <cite>.ll</cite> file. This is useful in many
+circumstances, for example, testing different architectural variants with
+<strong class="program">llc</strong>. Here’s a simple example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \</span>
+<span class="c">; RUN: | FileCheck %s -check-prefix=X32</span>
+<span class="c">; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \</span>
+<span class="c">; RUN: | FileCheck %s -check-prefix=X64</span>
+
+<span class="k">define</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="vg">@pinsrd_1</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%s</span><span class="p">,</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="nv">%tmp</span><span class="p">)</span> <span class="k">nounwind</span> <span class="p">{</span>
+ <span class="nv">%tmp1</span> <span class="p">=</span> <span class="k">insertelement</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span><span class="c">; %tmp, i32 %s, i32 1</span>
+ <span class="k">ret</span> <span class="p"><</span><span class="m">4</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="nv">%tmp1</span>
+<span class="c">; X32: pinsrd_1:</span>
+<span class="c">; X32: pinsrd $1, 4(%esp), %xmm0</span>
+
+<span class="c">; X64: pinsrd_1:</span>
+<span class="c">; X64: pinsrd $1, %edi, %xmm0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, we’re testing that we get the expected code generation with
+both 32-bit and 64-bit code generation.</p>
+</div>
+<div class="section" id="the-check-next-directive">
+<h3>The “CHECK-NEXT:” directive<a class="headerlink" href="#the-check-next-directive" title="Permalink to this headline">¶</a></h3>
+<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
+this case, you can use “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” and “<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” directives to specify
+this. If you specified a custom check prefix, just use “<tt class="docutils literal"><span class="pre"><PREFIX>-NEXT:</span></tt>”.
+For example, something like this works as you’d expect:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="kt">void</span> <span class="vg">@t2</span><span class="p">(<</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%r</span><span class="p">,</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%A</span><span class="p">,</span> <span class="kt">double</span> <span class="nv">%B</span><span class="p">)</span> <span class="p">{</span>
+ <span class="nv">%tmp3</span> <span class="p">=</span> <span class="k">load</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%A</span><span class="p">,</span> <span class="k">align</span> <span class="m">16</span>
+ <span class="nv">%tmp7</span> <span class="p">=</span> <span class="k">insertelement</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="k">undef</span><span class="p">,</span> <span class="kt">double</span> <span class="nv">%B</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span>
+ <span class="nv">%tmp9</span> <span class="p">=</span> <span class="k">shufflevector</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp3</span><span class="p">,</span>
+ <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp7</span><span class="p">,</span>
+ <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="k">i32</span><span class="p">></span> <span class="p"><</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">2</span> <span class="p">></span>
+ <span class="k">store</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">></span> <span class="nv">%tmp9</span><span class="p">,</span> <span class="p"><</span><span class="m">2</span> <span class="k">x</span> <span class="kt">double</span><span class="p">>*</span> <span class="nv">%r</span><span class="p">,</span> <span class="k">align</span> <span class="m">16</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+
+<span class="c">; CHECK: t2:</span>
+<span class="c">; CHECK: movl 8(%esp), %eax</span>
+<span class="c">; CHECK-NEXT: movapd (%eax), %xmm0</span>
+<span class="c">; CHECK-NEXT: movhpd 12(%esp), %xmm0</span>
+<span class="c">; CHECK-NEXT: movl 4(%esp), %eax</span>
+<span class="c">; CHECK-NEXT: movapd %xmm0, (%eax)</span>
+<span class="c">; CHECK-NEXT: ret</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” directives reject the input unless there is exactly one
+newline between it and the previous directive. A “<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” cannot be
+the first directive in a file.</p>
+</div>
+<div class="section" id="the-check-same-directive">
+<h3>The “CHECK-SAME:” directive<a class="headerlink" href="#the-check-same-directive" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes you want to match lines and would like to verify that matches happen
+on the same line as the previous match. In this case, you can use “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>”
+and “<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” directives to specify this. If you specified a custom
+check prefix, just use “<tt class="docutils literal"><span class="pre"><PREFIX>-SAME:</span></tt>”.</p>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” is particularly powerful in conjunction with “<tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>”
+(described below).</p>
+<p>For example, the following works like you’d expect:</p>
+<div class="highlight-llvm"><pre>!0 = !DILocation(line: 5, scope: !1, inlinedAt: !2)
+
+; CHECK: !DILocation(line: 5,
+; CHECK-NOT: column:
+; CHECK-SAME: scope: ![[SCOPE:[0-9]+]]</pre>
+</div>
+<p>“<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” directives reject the input if there are any newlines between
+it and the previous directive. A “<tt class="docutils literal"><span class="pre">CHECK-SAME:</span></tt>” cannot be the first
+directive in a file.</p>
+</div>
+<div class="section" id="the-check-empty-directive">
+<h3>The “CHECK-EMPTY:” directive<a class="headerlink" href="#the-check-empty-directive" title="Permalink to this headline">¶</a></h3>
+<p>If you need to check that the next line has nothing on it, not even whitespace,
+you can use the “<tt class="docutils literal"><span class="pre">CHECK-EMPTY:</span></tt>” directive.</p>
+<div class="highlight-llvm"><pre>foo
+
+bar
+; CHECK: foo
+; CHECK-EMPTY:
+; CHECK-NEXT: bar</pre>
+</div>
+<p>Just like “<tt class="docutils literal"><span class="pre">CHECK-NEXT:</span></tt>” the directive will fail if there is more than one
+newline before it finds the next blank line, and it cannot be the first
+directive in a file.</p>
+</div>
+<div class="section" id="the-check-not-directive">
+<h3>The “CHECK-NOT:” directive<a class="headerlink" href="#the-check-not-directive" title="Permalink to this headline">¶</a></h3>
+<p>The “<tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>” directive is used to verify that a string doesn’t occur
+between two matches (or before the first match, or after the last match). For
+example, to verify that a load is removed by a transformation, a test like this
+can be used:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i8</span> <span class="vg">@coerce_offset0</span><span class="p">(</span><span class="k">i32</span> <span class="nv">%V</span><span class="p">,</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">store</span> <span class="k">i32</span> <span class="nv">%V</span><span class="p">,</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span>
+
+ <span class="nv">%P2</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%P</span> <span class="k">to</span> <span class="k">i8</span><span class="p">*</span>
+ <span class="nv">%P3</span> <span class="p">=</span> <span class="k">getelementptr</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%P2</span><span class="p">,</span> <span class="k">i32</span> <span class="m">2</span>
+
+ <span class="nv">%A</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%P3</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="nv">%A</span>
+<span class="c">; CHECK: @coerce_offset0</span>
+<span class="c">; CHECK-NOT: load</span>
+<span class="c">; CHECK: ret i8</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-check-dag-directive">
+<h3>The “CHECK-DAG:” directive<a class="headerlink" href="#the-check-dag-directive" title="Permalink to this headline">¶</a></h3>
+<p>If it’s necessary to match strings that don’t occur in a strictly sequential
+order, “<tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>” could be used to verify them between two matches (or
+before the first match, or after the last match). For example, clang emits
+vtable globals in reverse order. Using <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt>, we can keep the checks
+in the natural order:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s</span>
+
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="k">virtual</span> <span class="kt">void</span> <span class="n">method</span><span class="p">();</span> <span class="p">};</span>
+<span class="n">Foo</span> <span class="n">f</span><span class="p">;</span> <span class="c1">// emit vtable</span>
+<span class="c1">// CHECK-DAG: @_ZTV3Foo =</span>
+
+<span class="k">struct</span> <span class="n">Bar</span> <span class="p">{</span> <span class="k">virtual</span> <span class="kt">void</span> <span class="n">method</span><span class="p">();</span> <span class="p">};</span>
+<span class="n">Bar</span> <span class="n">b</span><span class="p">;</span>
+<span class="c1">// CHECK-DAG: @_ZTV3Bar =</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt> directives could be mixed with <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives to
+exclude strings between the surrounding <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives. As a result,
+the surrounding <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives cannot be reordered, i.e. all
+occurrences matching <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> before <tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt> must not fall behind
+occurrences matching <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> after <tt class="docutils literal"><span class="pre">CHECK-NOT:</span></tt>. For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK-DAG: BEFORE</span>
+<span class="c">; CHECK-NOT: NOT</span>
+<span class="c">; CHECK-DAG: AFTER</span>
+</pre></div>
+</div>
+<p>This case will reject input strings where <tt class="docutils literal"><span class="pre">BEFORE</span></tt> occurs after <tt class="docutils literal"><span class="pre">AFTER</span></tt>.</p>
+<p>With captured variables, <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> is able to match valid topological
+orderings of a DAG with edges from the definition of a variable to its use.
+It’s useful, e.g., when your test cases need to match different output
+sequences from the instruction scheduler. For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2</span>
+<span class="c">; CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4</span>
+<span class="c">; CHECK: mul r5, [[REG1]], [[REG2]]</span>
+</pre></div>
+</div>
+<p>In this case, any order of that two <tt class="docutils literal"><span class="pre">add</span></tt> instructions will be allowed.</p>
+<p>If you are defining <cite>and</cite> using variables in the same <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> block,
+be aware that the definition rule can match <cite>after</cite> its use.</p>
+<p>So, for instance, the code below will pass:</p>
+<div class="highlight-text"><div class="highlight"><pre>; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
+; CHECK-DAG: vmov.32 [[REG2]][1]
+vmov.32 d0[1]
+vmov.32 d0[0]
+</pre></div>
+</div>
+<p>While this other code, will not:</p>
+<div class="highlight-text"><div class="highlight"><pre>; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
+; CHECK-DAG: vmov.32 [[REG2]][1]
+vmov.32 d1[1]
+vmov.32 d0[0]
+</pre></div>
+</div>
+<p>While this can be very useful, it’s also dangerous, because in the case of
+register sequence, you must have a strong order (read before write, copy before
+use, etc). If the definition your test is looking for doesn’t match (because
+of a bug in the compiler), it may match further away from the use, and mask
+real bugs away.</p>
+<p>In those cases, to enforce the order, use a non-DAG directive between DAG-blocks.</p>
+<p>A <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directive skips matches that overlap the matches of any
+preceding <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> directives in the same <tt class="docutils literal"><span class="pre">CHECK-DAG:</span></tt> block. Not only
+is this non-overlapping behavior consistent with other directives, but it’s
+also necessary to handle sets of non-unique strings or patterns. For example,
+the following directives look for unordered log entries for two tasks in a
+parallel program, such as the OpenMP runtime:</p>
+<div class="highlight-text"><div class="highlight"><pre>// CHECK-DAG: [[THREAD_ID:[0-9]+]]: task_begin
+// CHECK-DAG: [[THREAD_ID]]: task_end
+//
+// CHECK-DAG: [[THREAD_ID:[0-9]+]]: task_begin
+// CHECK-DAG: [[THREAD_ID]]: task_end
+</pre></div>
+</div>
+<p>The second pair of directives is guaranteed not to match the same log entries
+as the first pair even though the patterns are identical and even if the text
+of the log entries is identical because the thread ID manages to be reused.</p>
+</div>
+<div class="section" id="the-check-label-directive">
+<h3>The “CHECK-LABEL:” directive<a class="headerlink" href="#the-check-label-directive" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes in a file containing multiple tests divided into logical blocks, one
+or more <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives may inadvertently succeed by matching lines in a
+later block. While an error will usually eventually be generated, the check
+flagged as causing the error may not actually bear any relationship to the
+actual source of the problem.</p>
+<p>In order to produce better error messages in these cases, the “<tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt>”
+directive can be used. It is treated identically to a normal <tt class="docutils literal"><span class="pre">CHECK</span></tt>
+directive except that FileCheck makes an additional assumption that a line
+matched by the directive cannot also be matched by any other check present in
+<tt class="docutils literal"><span class="pre">match-filename</span></tt>; this is intended to be used for lines containing labels or
+other unique identifiers. Conceptually, the presence of <tt class="docutils literal"><span class="pre">CHECK-LABEL</span></tt> divides
+the input stream into separate blocks, each of which is processed independently,
+preventing a <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directive in one block matching a line in another block.
+If <tt class="docutils literal"><span class="pre">--enable-var-scope</span></tt> is in effect, all local variables are cleared at the
+beginning of the block.</p>
+<p>For example,</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="vg">@C_ctor_base</span><span class="p">(</span><span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK-LABEL: C_ctor_base:</span>
+<span class="c">; CHECK: mov [[SAVETHIS:r[0-9]+]], r0</span>
+<span class="c">; CHECK: bl A_ctor_base</span>
+<span class="c">; CHECK: mov r0, [[SAVETHIS]]</span>
+ <span class="nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span> <span class="k">to</span> <span class="nv">%struct.A</span><span class="p">*</span>
+ <span class="nv">%call</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="nv">%struct.A</span><span class="p">*</span> <span class="vg">@A_ctor_base</span><span class="p">(</span><span class="nv">%struct.A</span><span class="p">*</span> <span class="nv-Anonymous">%0</span><span class="p">)</span>
+ <span class="nv-Anonymous">%1</span> <span class="p">=</span> <span class="k">bitcast</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span> <span class="k">to</span> <span class="nv">%struct.B</span><span class="p">*</span>
+ <span class="nv">%call2</span> <span class="p">=</span> <span class="k">tail</span> <span class="k">call</span> <span class="nv">%struct.B</span><span class="p">*</span> <span class="vg">@B_ctor_base</span><span class="p">(</span><span class="nv">%struct.B</span><span class="p">*</span> <span class="nv-Anonymous">%1</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="nv">%struct.C</span><span class="p">*</span> <span class="nv">%this</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="nv">%struct.D</span><span class="p">*</span> <span class="vg">@D_ctor_base</span><span class="p">(</span><span class="nv">%struct.D</span><span class="p">*</span> <span class="nv">%this</span><span class="p">,</span> <span class="k">i32</span> <span class="nv">%x</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+<span class="c">; CHECK-LABEL: D_ctor_base:</span>
+</pre></div>
+</div>
+<p>The use of <tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives in this case ensures that the three
+<tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives only accept lines corresponding to the body of the
+<tt class="docutils literal"><span class="pre">@C_ctor_base</span></tt> function, even if the patterns match lines found later in
+the file. Furthermore, if one of these three <tt class="docutils literal"><span class="pre">CHECK:</span></tt> directives fail,
+FileCheck will recover by continuing to the next block, allowing multiple test
+failures to be detected in a single invocation.</p>
+<p>There is no requirement that <tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives contain strings that
+correspond to actual syntactic labels in a source or output language: they must
+simply uniquely match a single line in the file being verified.</p>
+<p><tt class="docutils literal"><span class="pre">CHECK-LABEL:</span></tt> directives cannot contain variable definitions or uses.</p>
+</div>
+<div class="section" id="filecheck-pattern-matching-syntax">
+<h3>FileCheck Pattern Matching Syntax<a class="headerlink" href="#filecheck-pattern-matching-syntax" title="Permalink to this headline">¶</a></h3>
+<p>All FileCheck directives take a pattern to match.
+For most uses of FileCheck, fixed string matching is perfectly sufficient. For
+some things, a more flexible form of matching is desired. To support this,
+FileCheck allows you to specify regular expressions in matching strings,
+surrounded by double braces: <tt class="docutils literal"><span class="pre">{{yourregex}}</span></tt>. FileCheck implements a POSIX
+regular expression matcher; it supports Extended POSIX regular expressions
+(ERE). Because we want to use fixed string matching for a majority of what we
+do, FileCheck has been designed to support mixing and matching fixed string
+matching with regular expressions. This allows you to write things like this:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}</span>
+</pre></div>
+</div>
+<p>In this case, any offset from the ESP register will be allowed, and any xmm
+register will be allowed.</p>
+<p>Because regular expressions are enclosed with double braces, they are
+visually distinct, and you don’t need to use escape characters within the double
+braces like you would in C. In the rare case that you want to match double
+braces explicitly from the input, you can use something ugly like
+<tt class="docutils literal"><span class="pre">{{[{][{]}}</span></tt> as your pattern.</p>
+</div>
+<div class="section" id="filecheck-variables">
+<h3>FileCheck Variables<a class="headerlink" href="#filecheck-variables" title="Permalink to this headline">¶</a></h3>
+<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,
+but verify that that register is used consistently later. To do this,
+<strong class="program">FileCheck</strong> allows named variables to be defined and substituted into
+patterns. Here is a simple example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: test5:</span>
+<span class="c">; CHECK: notw [[REGISTER:%[a-z]+]]</span>
+<span class="c">; CHECK: andw {{.*}}[[REGISTER]]</span>
+</pre></div>
+</div>
+<p>The first check line matches a regex <tt class="docutils literal"><span class="pre">%[a-z]+</span></tt> and captures it into the
+variable <tt class="docutils literal"><span class="pre">REGISTER</span></tt>. The second line verifies that whatever is in
+<tt class="docutils literal"><span class="pre">REGISTER</span></tt> occurs later in the file after an “<tt class="docutils literal"><span class="pre">andw</span></tt>”. <strong class="program">FileCheck</strong>
+variable references are always contained in <tt class="docutils literal"><span class="pre">[[</span> <span class="pre">]]</span></tt> pairs, and their names can
+be formed with the regex <tt class="docutils literal"><span class="pre">[a-zA-Z_][a-zA-Z0-9_]*</span></tt>. If a colon follows the name,
+then it is a definition of the variable; otherwise, it is a use.</p>
+<p><strong class="program">FileCheck</strong> variables can be defined multiple times, and uses always
+get the latest value. Variables can also be used later on the same line they
+were defined on. For example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="c">; CHECK: op [[REG:r[0-9]+]], [[REG]]</span>
+</pre></div>
+</div>
+<p>Can be useful if you want the operands of <tt class="docutils literal"><span class="pre">op</span></tt> to be the same register,
+and don’t care exactly which register it is.</p>
+<p>If <tt class="docutils literal"><span class="pre">--enable-var-scope</span></tt> is in effect, variables with names that
+start with <tt class="docutils literal"><span class="pre">$</span></tt> are considered to be global. All others variables are
+local. All local variables get undefined at the beginning of each
+CHECK-LABEL block. Global variables are not affected by CHECK-LABEL.
+This makes it easier to ensure that individual tests are not affected
+by variables set in preceding tests.</p>
+</div>
+<div class="section" id="filecheck-expressions">
+<h3>FileCheck Expressions<a class="headerlink" href="#filecheck-expressions" title="Permalink to this headline">¶</a></h3>
+<p>Sometimes there’s a need to verify output which refers line numbers of the
+match file, e.g. when testing compiler diagnostics. This introduces a certain
+fragility of the match file structure, as “<tt class="docutils literal"><span class="pre">CHECK:</span></tt>” lines contain absolute
+line numbers in the same file, which have to be updated whenever line numbers
+change due to text addition or deletion.</p>
+<p>To support this case, FileCheck allows using <tt class="docutils literal"><span class="pre">[[@LINE]]</span></tt>,
+<tt class="docutils literal"><span class="pre">[[@LINE+<offset>]]</span></tt>, <tt class="docutils literal"><span class="pre">[[@LINE-<offset>]]</span></tt> expressions in patterns. These
+expressions expand to a number of the line where a pattern is located (with an
+optional integer offset).</p>
+<p>This way match patterns can be put near the relevant test lines and include
+relative line number references, for example:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// CHECK: test.cpp:[[@LINE+4]]:6: error: expected ';' after top level declarator</span>
+<span class="c1">// CHECK-NEXT: {{^int a}}</span>
+<span class="c1">// CHECK-NEXT: {{^ \^}}</span>
+<span class="c1">// CHECK-NEXT: {{^ ;}}</span>
+<span class="kt">int</span> <span class="n">a</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="matching-newline-characters">
+<h3>Matching Newline Characters<a class="headerlink" href="#matching-newline-characters" title="Permalink to this headline">¶</a></h3>
+<p>To match newline characters in regular expressions the character class
+<tt class="docutils literal"><span class="pre">[[:space:]]</span></tt> can be used. For example, the following pattern:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// CHECK: DW_AT_location [DW_FORM_sec_offset] ([[DLOC:0x[0-9a-f]+]]){{[[:space:]].*}}"intd"</span>
+</pre></div>
+</div>
+<p>matches output of the form (from llvm-dwarfdump):</p>
+<div class="highlight-text"><div class="highlight"><pre>DW_AT_location [DW_FORM_sec_offset] (0x00000233)
+DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd")
+</pre></div>
+</div>
+<p>letting us set the <strong class="program">FileCheck</strong> variable <tt class="docutils literal"><span class="pre">DLOC</span></tt> to the desired value
+<tt class="docutils literal"><span class="pre">0x00000233</span></tt>, extracted from the line immediately preceding “<tt class="docutils literal"><span class="pre">intd</span></tt>”.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/bugpoint.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/bugpoint.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/bugpoint.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,266 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>bugpoint - automatic test case reduction tool — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-extract - extract a function from an LLVM module" href="llvm-extract.html" />
+ <link rel="prev" title="llvm-mca - LLVM Machine Code Analyzer" href="llvm-mca.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-mca.html" title="llvm-mca - LLVM Machine Code Analyzer"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="bugpoint-automatic-test-case-reduction-tool">
+<h1>bugpoint - automatic test case reduction tool<a class="headerlink" href="#bugpoint-automatic-test-case-reduction-tool" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>bugpoint</strong> [<em>options</em>] [<em>input LLVM ll/bc files</em>] [<em>LLVM passes</em>] <strong>–args</strong>
+<em>program arguments</em></p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>bugpoint</strong> narrows down the source of problems in LLVM tools and passes. It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers). It aims to reduce large test cases to small, useful ones.
+For more information on the design and inner workings of <strong>bugpoint</strong>, as well as
+advice for using bugpoint, see <a class="reference internal" href="../Bugpoint.html"><em>LLVM bugpoint tool: design and usage</em></a> in the LLVM
+distribution.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>–additional-so</strong> <em>library</em></p>
+<blockquote>
+<div>Load the dynamic shared object <em>library</em> into the test program whenever it is
+run. This is useful if you are debugging programs which depend on non-LLVM
+libraries (such as the X or curses libraries) to run.</div></blockquote>
+<p><strong>–append-exit-code</strong>=<em>{true,false}</em></p>
+<blockquote>
+<div>Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.</div></blockquote>
+<p><strong>–args</strong> <em>program args</em></p>
+<blockquote>
+<div><p>Pass all arguments specified after <strong>–args</strong> to the test program whenever it runs.
+Note that if any of the <em>program args</em> start with a “<tt class="docutils literal"><span class="pre">-</span></tt>”, you should use:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint <span class="o">[</span>bugpoint args<span class="o">]</span> --args -- <span class="o">[</span>program args<span class="o">]</span>
+</pre></div>
+</div>
+<p>The “<tt class="docutils literal"><span class="pre">--</span></tt>” right after the <strong>–args</strong> option tells <strong>bugpoint</strong> to consider
+any options starting with “<tt class="docutils literal"><span class="pre">-</span></tt>” to be part of the <strong>–args</strong> option, not as
+options to <strong>bugpoint</strong> itself.</p>
+</div></blockquote>
+<p><strong>–tool-args</strong> <em>tool args</em></p>
+<blockquote>
+<div><p>Pass all arguments specified after <strong>–tool-args</strong> to the LLVM tool under test
+(<strong>llc</strong>, <strong>lli</strong>, etc.) whenever it runs. You should use this option in the
+following way:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint <span class="o">[</span>bugpoint args<span class="o">]</span> --tool-args -- <span class="o">[</span>tool args<span class="o">]</span>
+</pre></div>
+</div>
+<p>The “<tt class="docutils literal"><span class="pre">--</span></tt>” right after the <strong>–tool-args</strong> option tells <strong>bugpoint</strong> to
+consider any options starting with “<tt class="docutils literal"><span class="pre">-</span></tt>” to be part of the <strong>–tool-args</strong>
+option, not as options to <strong>bugpoint</strong> itself. (See <strong>–args</strong>, above.)</p>
+</div></blockquote>
+<p><strong>–safe-tool-args</strong> <em>tool args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–safe-tool-args</strong> to the “safe” execution
+tool.</div></blockquote>
+<p><strong>–gcc-tool-args</strong> <em>gcc tool args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–gcc-tool-args</strong> to the invocation of
+<strong>gcc</strong>.</div></blockquote>
+<p><strong>–opt-args</strong> <em>opt args</em></p>
+<blockquote>
+<div>Pass all arguments specified after <strong>–opt-args</strong> to the invocation of <strong>opt</strong>.</div></blockquote>
+<p><strong>–disable-{dce,simplifycfg}</strong></p>
+<blockquote>
+<div>Do not run the specified passes to clean up and reduce the size of the test
+program. By default, <strong>bugpoint</strong> uses these passes internally when attempting to
+reduce test programs. If you’re trying to find a bug in one of these passes,
+<strong>bugpoint</strong> may crash.</div></blockquote>
+<p><strong>–enable-valgrind</strong></p>
+<blockquote>
+<div>Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.</div></blockquote>
+<p><strong>-find-bugs</strong></p>
+<blockquote>
+<div>Continually randomize the specified passes and run them on the test program
+until a bug is found or the user kills <strong>bugpoint</strong>.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of command line options.</div></blockquote>
+<p><strong>–input</strong> <em>filename</em></p>
+<blockquote>
+<div>Open <em>filename</em> and redirect the standard input of the test program, whenever
+it runs, to come from that file.</div></blockquote>
+<p><strong>–load</strong> <em>plugin</em></p>
+<blockquote>
+<div><p>Load the dynamic object <em>plugin</em> into <strong>bugpoint</strong> itself. This object should
+register new optimization passes. Once loaded, the object will add new command
+line options to enable various optimizations. To see the new complete list of
+optimizations, use the <strong>-help</strong> and <strong>–load</strong> options together; for example:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint --load myNewPass.so -help
+</pre></div>
+</div>
+</div></blockquote>
+<p><strong>–mlimit</strong> <em>megabytes</em></p>
+<blockquote>
+<div>Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.</div></blockquote>
+<p><strong>–output</strong> <em>filename</em></p>
+<blockquote>
+<div>Whenever the test program produces output on its standard output stream, it
+should match the contents of <em>filename</em> (the “reference output”). If you
+do not use this option, <strong>bugpoint</strong> will attempt to generate a reference output
+by compiling the program with the “safe” backend and running it.</div></blockquote>
+<p><strong>–run-{int,jit,llc,custom}</strong></p>
+<blockquote>
+<div>Whenever the test program is compiled, <strong>bugpoint</strong> should generate code for it
+using the specified code generator. These options allow you to choose the
+interpreter, the JIT compiler, the static native code compiler, or a
+custom command (see <strong>–exec-command</strong>) respectively.</div></blockquote>
+<p><strong>–safe-{llc,custom}</strong></p>
+<blockquote>
+<div>When debugging a code generator, <strong>bugpoint</strong> should use the specified code
+generator as the “safe” code generator. This is a known-good code generator
+used to generate the “reference output” if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, or a custom command, (see <strong>–exec-command</strong>)
+respectively. The interpreter and the JIT backends cannot currently
+be used as the “safe” backends.</div></blockquote>
+<p><strong>–exec-command</strong> <em>command</em></p>
+<blockquote>
+<div>This option defines the command to use with the <strong>–run-custom</strong> and
+<strong>–safe-custom</strong> options to execute the bitcode testcase. This can
+be useful for cross-compilation.</div></blockquote>
+<p><strong>–compile-command</strong> <em>command</em></p>
+<blockquote>
+<div><p>This option defines the command to use with the <strong>–compile-custom</strong>
+option to compile the bitcode testcase. The command should exit with a
+failure exit code if the file is “interesting” and should exit with a
+success exit code (i.e. 0) otherwise (this is the same as if it crashed on
+“interesting” inputs).</p>
+<p>This can be useful for
+testing compiler output without running any link or execute stages. To
+generate a reduced unit test, you may add CHECK directives to the
+testcase and pass the name of an executable compile-command script in this form:</p>
+<div class="highlight-sh"><div class="highlight"><pre><span class="c">#!/bin/sh</span>
+llc <span class="s2">"$@"</span>
+not FileCheck <span class="o">[</span>bugpoint input file<span class="o">]</span>.ll < bugpoint-test-program.s
+</pre></div>
+</div>
+<p>This script will “fail” as long as FileCheck passes. So the result
+will be the minimum bitcode that passes FileCheck.</p>
+</div></blockquote>
+<p><strong>–safe-path</strong> <em>path</em></p>
+<blockquote>
+<div>This option defines the path to the command to execute with the
+<strong>–safe-{int,jit,llc,custom}</strong>
+option.</div></blockquote>
+<p><strong>–verbose-errors</strong>=<em>{true,false}</em></p>
+<blockquote>
+<div>The default behavior of bugpoint is to print “<crash>” when it finds a reduced
+test that crashes compilation. This flag prints the output of the crashing
+program to stderr. This is useful to make sure it is the same error being
+tracked down and not a different error that happens to crash the compiler as
+well. Defaults to false.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>bugpoint</strong> succeeds in finding a problem, it will exit with 0. Otherwise,
+if an error occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>opt|opt</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-mca.html" title="llvm-mca - LLVM Machine Code Analyzer"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/dsymutil.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/dsymutil.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/dsymutil.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/dsymutil.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,247 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>dsymutil - manipulate archived DWARF debug symbol files — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-mca - LLVM Machine Code Analyzer" href="llvm-mca.html" />
+ <link rel="prev" title="llvm-dwarfdump - dump and verify DWARF debug information" href="llvm-dwarfdump.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-mca.html" title="llvm-mca - LLVM Machine Code Analyzer"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-dwarfdump.html" title="llvm-dwarfdump - dump and verify DWARF debug information"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="dsymutil-manipulate-archived-dwarf-debug-symbol-files">
+<h1>dsymutil - manipulate archived DWARF debug symbol files<a class="headerlink" href="#dsymutil-manipulate-archived-dwarf-debug-symbol-files" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<div class="line-block">
+<div class="line"><strong class="program">dsymutil</strong> [<em>options</em>] <em>executable</em></div>
+</div>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">dsymutil</strong> links the DWARF debug information found in the object files
+for an executable <em>executable</em> by using debug symbols information contained in
+its symbol table. By default, the linked debug information is placed in a
+<tt class="docutils literal"><span class="pre">.dSYM</span></tt> bundle with the same name as the executable.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--arch">
+<tt class="descname">--arch</tt><tt class="descclassname">=<arch></tt><a class="headerlink" href="#cmdoption--arch" title="Permalink to this definition">¶</a></dt>
+<dd><p>Link DWARF debug information only for specified CPU architecture types.
+Architectures may be specified by name. When using this option, an error will
+be returned if any architectures can not be properly linked. This option can
+be specified multiple times, once for each desired architecture. All CPU
+architectures will be linked by default and any architectures that can’t be
+properly linked will cause <strong class="program">dsymutil</strong> to return an error.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--dump-debug-map">
+<tt class="descname">--dump-debug-map</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--dump-debug-map" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dump the <em>executable</em>‘s debug-map (the list of the object files containing the
+debug information) in YAML format and exit. Not DWARF link will take place.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-f">
+<tt class="descname">-f</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--flat</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-f" title="Permalink to this definition">¶</a></dt>
+<dd><p>Produce a flat dSYM file. A <tt class="docutils literal"><span class="pre">.dwarf</span></tt> extension will be appended to the
+executable name unless the output file is specified using the -o option.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-z">
+<tt class="descname">-z</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--minimize</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-z" title="Permalink to this definition">¶</a></dt>
+<dd><p>When used when creating a dSYM file, this option will suppress the emission of
+the .debug_inlines, .debug_pubnames, and .debug_pubtypes sections since
+dsymutil currently has better equivalents: .apple_names and .apple_types. When
+used in conjunction with –update option, this option will cause redundant
+accelerator tables to be removed.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--no-odr">
+<tt class="descname">--no-odr</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--no-odr" title="Permalink to this definition">¶</a></dt>
+<dd><p>Do not use ODR (One Definition Rule) for uniquing C++ types.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--no-output">
+<tt class="descname">--no-output</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--no-output" title="Permalink to this definition">¶</a></dt>
+<dd><p>Do the link in memory, but do not emit the result file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--no-swiftmodule-timestamp">
+<tt class="descname">--no-swiftmodule-timestamp</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--no-swiftmodule-timestamp" title="Permalink to this definition">¶</a></dt>
+<dd><p>Don’t check the timestamp for swiftmodule files.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-j">
+<tt class="descname">-j</tt><tt class="descclassname"> <n></tt><tt class="descclassname">, </tt><tt class="descname">--num-threads</tt><tt class="descclassname">=<n></tt><a class="headerlink" href="#cmdoption-j" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specifies the maximum number (<tt class="docutils literal"><span class="pre">n</span></tt>) of simultaneous threads to use when
+linking multiple architectures.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-o">
+<tt class="descname">-o</tt><tt class="descclassname"> <filename></tt><a class="headerlink" href="#cmdoption-o" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specifies an alternate <tt class="docutils literal"><span class="pre">path</span></tt> to place the dSYM bundle. The default dSYM
+bundle path is created by appending <tt class="docutils literal"><span class="pre">.dSYM</span></tt> to the executable name.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--oso-prepend-path">
+<tt class="descname">--oso-prepend-path</tt><tt class="descclassname">=<path></tt><a class="headerlink" href="#cmdoption--oso-prepend-path" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specifies a <tt class="docutils literal"><span class="pre">path</span></tt> to prepend to all debug symbol object file paths.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--papertrail">
+<tt class="descname">--papertrail</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--papertrail" title="Permalink to this definition">¶</a></dt>
+<dd><p>When running dsymutil as part of your build system, it can be desirable for
+warnings to be part of the end product, rather than just being emitted to the
+output stream. When enabled warnings are embedded in the linked DWARF debug
+information.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-s">
+<tt class="descname">-s</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--symtab</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-s" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dumps the symbol table found in <em>executable</em> or object file(s) and exits.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--toolchain">
+<tt class="descname">--toolchain</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--toolchain" title="Permalink to this definition">¶</a></dt>
+<dd><p>Embed the toolchain in the dSYM bundle’s property list.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-u">
+<tt class="descname">-u</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--update</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-u" title="Permalink to this definition">¶</a></dt>
+<dd><p>Update an existing dSYM file to contain the latest accelerator tables and
+other DWARF optimizations. This option will rebuild the ‘.apple_names’ and
+‘.apple_types’ hashed accelerator tables.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--verbose</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display verbose information when linking.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--version">
+<tt class="descname">--version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display the version of the tool.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-y">
+<tt class="descname">-y</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-y" title="Permalink to this definition">¶</a></dt>
+<dd><p>Treat <em>executable</em> as a YAML debug-map rather than an executable.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">dsymutil</strong> returns 0 if the DWARF debug information was linked
+successfully. Otherwise, it returns 1.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p><em class="manpage">llvm-dwarfdump(1)</em></p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-mca.html" title="llvm-mca - LLVM Machine Code Analyzer"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-dwarfdump.html" title="llvm-dwarfdump - dump and verify DWARF debug information"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/index.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/index.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/index.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,154 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Command Guide — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="next" title="llvm-as - LLVM assembler" href="llvm-as.html" />
+ <link rel="prev" title="How To Cross-Compile Clang/LLVM using Clang/LLVM" href="../HowToCrossCompileLLVM.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="../HowToCrossCompileLLVM.html" title="How To Cross-Compile Clang/LLVM using Clang/LLVM"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-command-guide">
+<h1>LLVM Command Guide<a class="headerlink" href="#llvm-command-guide" title="Permalink to this headline">¶</a></h1>
+<p>The following documents are command descriptions for all of the LLVM tools.
+These pages describe how to use the LLVM commands and what their options are.
+Note that these pages do not describe all of the options available for all
+tools. To get a complete listing, pass the <tt class="docutils literal"><span class="pre">--help</span></tt> (general options) or
+<tt class="docutils literal"><span class="pre">--help-hidden</span></tt> (general and debugging options) arguments to the tool you are
+interested in.</p>
+<div class="section" id="basic-commands">
+<h2>Basic Commands<a class="headerlink" href="#basic-commands" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="llvm-as.html">llvm-as - LLVM assembler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-dis.html">llvm-dis - LLVM disassembler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="opt.html">opt - LLVM optimizer</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llc.html">llc - LLVM static compiler</a></li>
+<li class="toctree-l1"><a class="reference internal" href="lli.html">lli - directly execute programs from LLVM bitcode</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-link.html">llvm-link - LLVM bitcode linker</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-ar.html">llvm-ar - LLVM archiver</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-lib.html">llvm-lib - LLVM lib.exe compatible library tool</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-nm.html">llvm-nm - list LLVM bitcode and object file’s symbol table</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-config.html">llvm-config - Print LLVM compilation options</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-diff.html">llvm-diff - LLVM structural ‘diff’</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-cov.html">llvm-cov - emit coverage information</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-profdata.html">llvm-profdata - Profile data tool</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-stress.html">llvm-stress - generate random .ll files</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-symbolizer.html">llvm-symbolizer - convert addresses into source code locations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-dwarfdump.html">llvm-dwarfdump - dump and verify DWARF debug information</a></li>
+<li class="toctree-l1"><a class="reference internal" href="dsymutil.html">dsymutil - manipulate archived DWARF debug symbol files</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-mca.html">llvm-mca - LLVM Machine Code Analyzer</a></li>
+</ul>
+</div>
+</div>
+<div class="section" id="debugging-tools">
+<h2>Debugging Tools<a class="headerlink" href="#debugging-tools" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="bugpoint.html">bugpoint - automatic test case reduction tool</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-extract.html">llvm-extract - extract a function from an LLVM module</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-bcanalyzer.html">llvm-bcanalyzer - LLVM bitcode analyzer</a></li>
+</ul>
+</div>
+</div>
+<div class="section" id="developer-tools">
+<h2>Developer Tools<a class="headerlink" href="#developer-tools" title="Permalink to this headline">¶</a></h2>
+<div class="toctree-wrapper compound">
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="FileCheck.html">FileCheck - Flexible pattern matching file verifier</a></li>
+<li class="toctree-l1"><a class="reference internal" href="tblgen.html">tblgen - Target Description To C++ Code Generator</a></li>
+<li class="toctree-l1"><a class="reference internal" href="lit.html">lit - LLVM Integrated Tester</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-build.html">llvm-build - LLVM Project Build Utility</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-exegesis.html">llvm-exegesis - LLVM Machine Instruction Benchmark</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-pdbutil.html">llvm-pdbutil - PDB File forensics and diagnostics</a></li>
+<li class="toctree-l1"><a class="reference internal" href="llvm-readobj.html">llvm-readobj - LLVM Object Reader</a></li>
+</ul>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="../HowToCrossCompileLLVM.html" title="How To Cross-Compile Clang/LLVM using Clang/LLVM"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/lit.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/lit.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/lit.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/lit.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,585 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>lit - LLVM Integrated Tester — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-build - LLVM Project Build Utility" href="llvm-build.html" />
+ <link rel="prev" title="tblgen - Target Description To C++ Code Generator" href="tblgen.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="lit-llvm-integrated-tester">
+<h1>lit - LLVM Integrated Tester<a class="headerlink" href="#lit-llvm-integrated-tester" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> [<em>options</em>] [<em>tests</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> is a portable tool for executing LLVM and Clang style test
+suites, summarizing their results, and providing indication of failures.
+<strong class="program">lit</strong> is designed to be a lightweight testing tool with as simple a
+user interface as possible.</p>
+<p><strong class="program">lit</strong> should be run with one or more <em>tests</em> to run specified on the
+command line. Tests can be either individual test files or directories to
+search for tests (see <a class="reference internal" href="#test-discovery"><em>TEST DISCOVERY</em></a>).</p>
+<p>Each specified test will be executed (potentially in parallel) and once all
+tests have been run <strong class="program">lit</strong> will print summary information on the number
+of tests which passed or failed (see <a class="reference internal" href="#test-status-results"><em>TEST STATUS RESULTS</em></a>). The
+<strong class="program">lit</strong> program will execute with a non-zero exit code if any tests
+fail.</p>
+<p>By default <strong class="program">lit</strong> will use a succinct progress display and will only
+print summary information for test failures. See <a class="reference internal" href="#output-options"><em>OUTPUT OPTIONS</em></a> for
+options controlling the <strong class="program">lit</strong> progress display and output.</p>
+<p><strong class="program">lit</strong> also includes a number of options for controlling how tests are
+executed (specific features may depend on the particular test format). See
+<a class="reference internal" href="#execution-options"><em>EXECUTION OPTIONS</em></a> for more information.</p>
+<p>Finally, <strong class="program">lit</strong> also supports additional options for only running a
+subset of the options specified on the command line, see
+<a class="reference internal" href="#selection-options"><em>SELECTION OPTIONS</em></a> for more information.</p>
+<p>Users interested in the <strong class="program">lit</strong> architecture or designing a
+<strong class="program">lit</strong> testing implementation should see <a class="reference internal" href="#lit-infrastructure"><em>LIT INFRASTRUCTURE</em></a>.</p>
+</div>
+<div class="section" id="general-options">
+<h2>GENERAL OPTIONS<a class="headerlink" href="#general-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-h">
+<tt class="descname">-h</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-h" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the <strong class="program">lit</strong> help message.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-j">
+<tt class="descname">-j</tt><tt class="descclassname"> N</tt><tt class="descclassname">, </tt><tt class="descname">--threads</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption-j" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run <tt class="docutils literal"><span class="pre">N</span></tt> tests in parallel. By default, this is automatically chosen to
+match the number of detected available CPUs.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--config-prefix">
+<tt class="descname">--config-prefix</tt><tt class="descclassname">=NAME</tt><a class="headerlink" href="#cmdoption--config-prefix" title="Permalink to this definition">¶</a></dt>
+<dd><p>Search for <tt class="file docutils literal"><em><span class="pre">NAME</span></em><span class="pre">.cfg</span></tt> and <tt class="file docutils literal"><em><span class="pre">NAME</span></em><span class="pre">.site.cfg</span></tt> when searching for
+test suites, instead of <tt class="file docutils literal"><span class="pre">lit.cfg</span></tt> and <tt class="file docutils literal"><span class="pre">lit.site.cfg</span></tt>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-D">
+<tt class="descname">-D</tt><tt class="descclassname"> NAME[=VALUE]</tt><tt class="descclassname">, </tt><tt class="descname">--param</tt><tt class="descclassname"> NAME[=VALUE]</tt><a class="headerlink" href="#cmdoption-D" title="Permalink to this definition">¶</a></dt>
+<dd><p>Add a user defined parameter <tt class="docutils literal"><span class="pre">NAME</span></tt> with the given <tt class="docutils literal"><span class="pre">VALUE</span></tt> (or the empty
+string if not given). The meaning and use of these parameters is test suite
+dependent.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="output-options">
+<span id="id1"></span><h2>OUTPUT OPTIONS<a class="headerlink" href="#output-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-q">
+<tt class="descname">-q</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--quiet</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-q" title="Permalink to this definition">¶</a></dt>
+<dd><p>Suppress any output except for test failures.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-s">
+<tt class="descname">-s</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--succinct</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-s" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show less output, for example don’t show information on tests that pass.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--verbose</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show more information on test failures, for example the entire test output
+instead of just the test result.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-vv">
+<tt class="descname">-vv</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--echo-all-commands</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-vv" title="Permalink to this definition">¶</a></dt>
+<dd><p>Echo all commands to stdout, as they are being executed.
+This can be valuable for debugging test failures, as the last echoed command
+will be the one which has failed.
+<strong class="program">lit</strong> normally inserts a no-op command (<tt class="docutils literal"><span class="pre">:</span></tt> in the case of bash)
+with argument <tt class="docutils literal"><span class="pre">'RUN:</span> <span class="pre">at</span> <span class="pre">line</span> <span class="pre">N'</span></tt> before each command pipeline, and this
+option also causes those no-op commands to be echoed to stdout to help you
+locate the source line of the failed command.
+This option implies <tt class="docutils literal"><span class="pre">--verbose</span></tt>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-a">
+<tt class="descname">-a</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--show-all</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-a" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show more information about all tests, for example the entire test
+commandline and output.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--no-progress-bar">
+<tt class="descname">--no-progress-bar</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--no-progress-bar" title="Permalink to this definition">¶</a></dt>
+<dd><p>Do not use curses based progress bar.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-unsupported">
+<tt class="descname">--show-unsupported</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-unsupported" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the names of unsupported tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-xfail">
+<tt class="descname">--show-xfail</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-xfail" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the names of tests that were expected to fail.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="execution-options">
+<span id="id2"></span><h2>EXECUTION OPTIONS<a class="headerlink" href="#execution-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--path">
+<tt class="descname">--path</tt><tt class="descclassname">=PATH</tt><a class="headerlink" href="#cmdoption--path" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify an additional <tt class="docutils literal"><span class="pre">PATH</span></tt> to use when searching for executables in tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg">
+<tt class="descname">--vg</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--vg" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run individual tests under valgrind (using the memcheck tool). The
+<tt class="docutils literal"><span class="pre">--error-exitcode</span></tt> argument for valgrind is used so that valgrind failures
+will cause the program to exit with a non-zero status.</p>
+<p>When this option is enabled, <strong class="program">lit</strong> will also automatically provide a
+“<tt class="docutils literal"><span class="pre">valgrind</span></tt>” feature that can be used to conditionally disable (or expect
+failure in) certain tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg-arg">
+<tt class="descname">--vg-arg</tt><tt class="descclassname">=ARG</tt><a class="headerlink" href="#cmdoption--vg-arg" title="Permalink to this definition">¶</a></dt>
+<dd><p>When <a class="reference internal" href="#cmdoption--vg"><em class="xref std std-option">--vg</em></a> is used, specify an additional argument to pass to
+<strong class="program">valgrind</strong> itself.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--vg-leak">
+<tt class="descname">--vg-leak</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--vg-leak" title="Permalink to this definition">¶</a></dt>
+<dd><p>When <a class="reference internal" href="#cmdoption--vg"><em class="xref std std-option">--vg</em></a> is used, enable memory leak checks. When this option is
+enabled, <strong class="program">lit</strong> will also automatically provide a “<tt class="docutils literal"><span class="pre">vg_leak</span></tt>”
+feature that can be used to conditionally disable (or expect failure in)
+certain tests.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--time-tests">
+<tt class="descname">--time-tests</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--time-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>Track the wall time individual tests take to execute and includes the results
+in the summary output. This is useful for determining which tests in a test
+suite take the most time to execute. Note that this option is most useful
+with <tt class="docutils literal"><span class="pre">-j</span> <span class="pre">1</span></tt>.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="selection-options">
+<span id="id3"></span><h2>SELECTION OPTIONS<a class="headerlink" href="#selection-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--max-tests">
+<tt class="descname">--max-tests</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption--max-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run at most <tt class="docutils literal"><span class="pre">N</span></tt> tests and then terminate.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--max-time">
+<tt class="descname">--max-time</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption--max-time" title="Permalink to this definition">¶</a></dt>
+<dd><p>Spend at most <tt class="docutils literal"><span class="pre">N</span></tt> seconds (approximately) running tests and then terminate.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--shuffle">
+<tt class="descname">--shuffle</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--shuffle" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run the tests in a random order.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--num-shards">
+<tt class="descname">--num-shards</tt><tt class="descclassname">=M</tt><a class="headerlink" href="#cmdoption--num-shards" title="Permalink to this definition">¶</a></dt>
+<dd><p>Divide the set of selected tests into <tt class="docutils literal"><span class="pre">M</span></tt> equal-sized subsets or
+“shards”, and run only one of them. Must be used with the
+<tt class="docutils literal"><span class="pre">--run-shard=N</span></tt> option, which selects the shard to run. The environment
+variable <tt class="docutils literal"><span class="pre">LIT_NUM_SHARDS</span></tt> can also be used in place of this
+option. These two options provide a coarse mechanism for paritioning large
+testsuites, for parallel execution on separate machines (say in a large
+testing farm).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--run-shard">
+<tt class="descname">--run-shard</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption--run-shard" title="Permalink to this definition">¶</a></dt>
+<dd><p>Select which shard to run, assuming the <tt class="docutils literal"><span class="pre">--num-shards=M</span></tt> option was
+provided. The two options must be used together, and the value of <tt class="docutils literal"><span class="pre">N</span></tt>
+must be in the range <tt class="docutils literal"><span class="pre">1..M</span></tt>. The environment variable
+<tt class="docutils literal"><span class="pre">LIT_RUN_SHARD</span></tt> can also be used in place of this option.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--filter">
+<tt class="descname">--filter</tt><tt class="descclassname">=REGEXP</tt><a class="headerlink" href="#cmdoption--filter" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run only those tests whose name matches the regular expression specified in
+<tt class="docutils literal"><span class="pre">REGEXP</span></tt>. The environment variable <tt class="docutils literal"><span class="pre">LIT_FILTER</span></tt> can be also used in place
+of this option, which is especially useful in environments where the call
+to <tt class="docutils literal"><span class="pre">lit</span></tt> is issued indirectly.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="additional-options">
+<h2>ADDITIONAL OPTIONS<a class="headerlink" href="#additional-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption--debug">
+<tt class="descname">--debug</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--debug" title="Permalink to this definition">¶</a></dt>
+<dd><p>Run <strong class="program">lit</strong> in debug mode, for debugging configuration issues and
+<strong class="program">lit</strong> itself.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-suites">
+<tt class="descname">--show-suites</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-suites" title="Permalink to this definition">¶</a></dt>
+<dd><p>List the discovered test suites and exit.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--show-tests">
+<tt class="descname">--show-tests</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--show-tests" title="Permalink to this definition">¶</a></dt>
+<dd><p>List all of the discovered tests and exit.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lit</strong> will exit with an exit code of 1 if there are any FAIL or XPASS
+results. Otherwise, it will exit with the status 0. Other exit codes are used
+for non-test related failures (for example a user error or an internal program
+error).</p>
+</div>
+<div class="section" id="test-discovery">
+<span id="id4"></span><h2>TEST DISCOVERY<a class="headerlink" href="#test-discovery" title="Permalink to this headline">¶</a></h2>
+<p>The inputs passed to <strong class="program">lit</strong> can be either individual tests, or entire
+directories or hierarchies of tests to run. When <strong class="program">lit</strong> starts up, the
+first thing it does is convert the inputs into a complete list of tests to run
+as part of <em>test discovery</em>.</p>
+<p>In the <strong class="program">lit</strong> model, every test must exist inside some <em>test suite</em>.
+<strong class="program">lit</strong> resolves the inputs specified on the command line to test suites
+by searching upwards from the input path until it finds a <tt class="file docutils literal"><span class="pre">lit.cfg</span></tt> or
+<tt class="file docutils literal"><span class="pre">lit.site.cfg</span></tt> file. These files serve as both a marker of test suites
+and as configuration files which <strong class="program">lit</strong> loads in order to understand
+how to find and run the tests inside the test suite.</p>
+<p>Once <strong class="program">lit</strong> has mapped the inputs into test suites it traverses the
+list of inputs adding tests for individual files and recursively searching for
+tests in directories.</p>
+<p>This behavior makes it easy to specify a subset of tests to run, while still
+allowing the test suite configuration to control exactly how tests are
+interpreted. In addition, <strong class="program">lit</strong> always identifies tests by the test
+suite they are in, and their relative path inside the test suite. For
+appropriately configured projects, this allows <strong class="program">lit</strong> to provide
+convenient and flexible support for out-of-tree builds.</p>
+</div>
+<div class="section" id="test-status-results">
+<span id="id5"></span><h2>TEST STATUS RESULTS<a class="headerlink" href="#test-status-results" title="Permalink to this headline">¶</a></h2>
+<p>Each test ultimately produces one of the following six results:</p>
+<p><strong>PASS</strong></p>
+<blockquote>
+<div>The test succeeded.</div></blockquote>
+<p><strong>XFAIL</strong></p>
+<blockquote>
+<div>The test failed, but that is expected. This is used for test formats which allow
+specifying that a test does not currently work, but wish to leave it in the test
+suite.</div></blockquote>
+<p><strong>XPASS</strong></p>
+<blockquote>
+<div>The test succeeded, but it was expected to fail. This is used for tests which
+were specified as expected to fail, but are now succeeding (generally because
+the feature they test was broken and has been fixed).</div></blockquote>
+<p><strong>FAIL</strong></p>
+<blockquote>
+<div>The test failed.</div></blockquote>
+<p><strong>UNRESOLVED</strong></p>
+<blockquote>
+<div>The test result could not be determined. For example, this occurs when the test
+could not be run, the test itself is invalid, or the test was interrupted.</div></blockquote>
+<p><strong>UNSUPPORTED</strong></p>
+<blockquote>
+<div>The test is not supported in this environment. This is used by test formats
+which can report unsupported tests.</div></blockquote>
+<p>Depending on the test format tests may produce additional information about
+their status (generally only for failures). See the <a class="reference internal" href="#output-options"><em>OUTPUT OPTIONS</em></a>
+section for more information.</p>
+</div>
+<div class="section" id="lit-infrastructure">
+<span id="id6"></span><h2>LIT INFRASTRUCTURE<a class="headerlink" href="#lit-infrastructure" title="Permalink to this headline">¶</a></h2>
+<p>This section describes the <strong class="program">lit</strong> testing architecture for users interested in
+creating a new <strong class="program">lit</strong> testing implementation, or extending an existing one.</p>
+<p><strong class="program">lit</strong> proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. <strong class="program">lit</strong> itself doesn’t know how to run tests, rather this logic is
+defined by <em>test suites</em>.</p>
+<div class="section" id="test-suites">
+<h3>TEST SUITES<a class="headerlink" href="#test-suites" title="Permalink to this headline">¶</a></h3>
+<p>As described in <a class="reference internal" href="#test-discovery"><em>TEST DISCOVERY</em></a>, tests are always located inside a <em>test
+suite</em>. Test suites serve to define the format of the tests they contain, the
+logic for finding those tests, and any additional information to run the tests.</p>
+<p><strong class="program">lit</strong> identifies test suites as directories containing <tt class="docutils literal"><span class="pre">lit.cfg</span></tt> or
+<tt class="docutils literal"><span class="pre">lit.site.cfg</span></tt> files (see also <a class="reference internal" href="#cmdoption--config-prefix"><em class="xref std std-option">--config-prefix</em></a>). Test suites are
+initially discovered by recursively searching up the directory hierarchy for
+all the input files passed on the command line. You can use
+<a class="reference internal" href="#cmdoption--show-suites"><em class="xref std std-option">--show-suites</em></a> to display the discovered test suites at startup.</p>
+<p>Once a test suite is discovered, its config file is loaded. Config files
+themselves are Python modules which will be executed. When the config file is
+executed, two important global variables are predefined:</p>
+<p><strong>lit_config</strong></p>
+<blockquote>
+<div>The global <strong>lit</strong> configuration object (a <em>LitConfig</em> instance), which defines
+the builtin test formats, global configuration parameters, and other helper
+routines for implementing test configurations.</div></blockquote>
+<p><strong>config</strong></p>
+<blockquote>
+<div><p>This is the config object (a <em>TestingConfig</em> instance) for the test suite,
+which the config file is expected to populate. The following variables are also
+available on the <em>config</em> object, some of which must be set by the config and
+others are optional or predefined:</p>
+<p><strong>name</strong> <em>[required]</em> The name of the test suite, for use in reports and
+diagnostics.</p>
+<p><strong>test_format</strong> <em>[required]</em> The test format object which will be used to
+discover and run tests in the test suite. Generally this will be a builtin test
+format available from the <em>lit.formats</em> module.</p>
+<p><strong>test_source_root</strong> The filesystem path to the test suite root. For out-of-dir
+builds this is the directory that will be scanned for tests.</p>
+<p><strong>test_exec_root</strong> For out-of-dir builds, the path to the test suite root inside
+the object directory. This is where tests will be run and temporary output files
+placed.</p>
+<p><strong>environment</strong> A dictionary representing the environment to use when executing
+tests in the suite.</p>
+<p><strong>suffixes</strong> For <strong>lit</strong> test formats which scan directories for tests, this
+variable is a list of suffixes to identify test files. Used by: <em>ShTest</em>.</p>
+<p><strong>substitutions</strong> For <strong>lit</strong> test formats which substitute variables into a test
+script, the list of substitutions to perform. Used by: <em>ShTest</em>.</p>
+<p><strong>unsupported</strong> Mark an unsupported directory, all tests within it will be
+reported as unsupported. Used by: <em>ShTest</em>.</p>
+<p><strong>parent</strong> The parent configuration, this is the config object for the directory
+containing the test suite, or None.</p>
+<p><strong>root</strong> The root configuration. This is the top-most <strong class="program">lit</strong> configuration in
+the project.</p>
+<p><strong>pipefail</strong> Normally a test using a shell pipe fails if any of the commands
+on the pipe fail. If this is not desired, setting this variable to false
+makes the test fail only if the last command in the pipe fails.</p>
+<p><strong>available_features</strong> A set of features that can be used in <cite>XFAIL</cite>,
+<cite>REQUIRES</cite>, and <cite>UNSUPPORTED</cite> directives.</p>
+</div></blockquote>
+</div>
+<div class="section" id="id7">
+<h3>TEST DISCOVERY<a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h3>
+<p>Once test suites are located, <strong class="program">lit</strong> recursively traverses the source
+directory (following <em>test_source_root</em>) looking for tests. When <strong class="program">lit</strong>
+enters a sub-directory, it first checks to see if a nested test suite is
+defined in that directory. If so, it loads that test suite recursively,
+otherwise it instantiates a local test config for the directory (see
+<a class="reference internal" href="#local-configuration-files"><em>LOCAL CONFIGURATION FILES</em></a>).</p>
+<p>Tests are identified by the test suite they are contained within, and the
+relative path inside that suite. Note that the relative path may not refer to
+an actual file on disk; some test formats (such as <em>GoogleTest</em>) define
+“virtual tests” which have a path that contains both the path to the actual
+test file and a subpath to identify the virtual test.</p>
+</div>
+<div class="section" id="local-configuration-files">
+<span id="id8"></span><h3>LOCAL CONFIGURATION FILES<a class="headerlink" href="#local-configuration-files" title="Permalink to this headline">¶</a></h3>
+<p>When <strong class="program">lit</strong> loads a subdirectory in a test suite, it instantiates a
+local test configuration by cloning the configuration for the parent directory
+— the root of this configuration chain will always be a test suite. Once the
+test configuration is cloned <strong class="program">lit</strong> checks for a <em>lit.local.cfg</em> file
+in the subdirectory. If present, this file will be loaded and can be used to
+specialize the configuration for each individual directory. This facility can
+be used to define subdirectories of optional tests, or to change other
+configuration parameters — for example, to change the test format, or the
+suffixes which identify test files.</p>
+</div>
+<div class="section" id="pre-defined-substitutions">
+<h3>PRE-DEFINED SUBSTITUTIONS<a class="headerlink" href="#pre-defined-substitutions" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">lit</strong> provides various patterns that can be used with the RUN command.
+These are defined in TestRunner.py. The base set of substitutions are:</p>
+<blockquote>
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="16%" />
+<col width="84%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Macro</th>
+<th class="head">Substitution</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>%s</td>
+<td>source path (path to the file currently being run)</td>
+</tr>
+<tr class="row-odd"><td>%S</td>
+<td>source dir (directory of the file currently being run)</td>
+</tr>
+<tr class="row-even"><td>%p</td>
+<td>same as %S</td>
+</tr>
+<tr class="row-odd"><td>%{pathsep}</td>
+<td>path separator</td>
+</tr>
+<tr class="row-even"><td>%t</td>
+<td>temporary file name unique to the test</td>
+</tr>
+<tr class="row-odd"><td>%T</td>
+<td>temporary directory unique to the test</td>
+</tr>
+<tr class="row-even"><td>%%</td>
+<td>%</td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+<p>Other substitutions are provided that are variations on this base set and
+further substitution patterns can be defined by each test module. See the
+modules <a class="reference internal" href="#local-configuration-files"><em>LOCAL CONFIGURATION FILES</em></a>.</p>
+<p>More detailed information on substitutions can be found in the
+<a class="reference internal" href="../TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a>.</p>
+</div>
+<div class="section" id="test-run-output-format">
+<h3>TEST RUN OUTPUT FORMAT<a class="headerlink" href="#test-run-output-format" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">lit</strong> output for a test run conforms to the following schema, in
+both short and verbose modes (although in short mode no PASS lines will be
+shown). This schema has been chosen to be relatively easy to reliably parse by
+a machine (for example in buildbot log scraping), and for other tools to
+generate.</p>
+<p>Each test result is expected to appear on a line that matches:</p>
+<div class="highlight-none"><div class="highlight"><pre><result code>: <test name> (<progress info>)
+</pre></div>
+</div>
+<p>where <tt class="docutils literal"><span class="pre"><result-code></span></tt> is a standard test result such as PASS, FAIL, XFAIL,
+XPASS, UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and
+REGRESSED are also allowed.</p>
+<p>The <tt class="docutils literal"><span class="pre"><test</span> <span class="pre">name></span></tt> field can consist of an arbitrary string containing no
+newline.</p>
+<p>The <tt class="docutils literal"><span class="pre"><progress</span> <span class="pre">info></span></tt> field can be used to report progress information such
+as (1/300) or can be empty, but even when empty the parentheses are required.</p>
+<p>Each test result may include additional (multiline) log information in the
+following format:</p>
+<div class="highlight-none"><div class="highlight"><pre><log delineator> TEST '(<test name>)' <trailing delineator>
+... log message ...
+<log delineator>
+</pre></div>
+</div>
+<p>where <tt class="docutils literal"><span class="pre"><test</span> <span class="pre">name></span></tt> should be the name of a preceding reported test, <tt class="docutils literal"><span class="pre"><log</span>
+<span class="pre">delineator></span></tt> is a string of “*” characters <em>at least</em> four characters long
+(the recommended length is 20), and <tt class="docutils literal"><span class="pre"><trailing</span> <span class="pre">delineator></span></tt> is an arbitrary
+(unparsed) string.</p>
+<p>The following is an example of a test run output which consists of four tests A,
+B, C, and D, and a log message for the failing test C:</p>
+<div class="highlight-none"><div class="highlight"><pre>PASS: A (1 of 4)
+PASS: B (2 of 4)
+FAIL: C (3 of 4)
+******************** TEST 'C' FAILED ********************
+Test 'C' failed as a result of exit code 1.
+********************
+PASS: D (4 of 4)
+</pre></div>
+</div>
+</div>
+<div class="section" id="lit-example-tests">
+<h3>LIT EXAMPLE TESTS<a class="headerlink" href="#lit-example-tests" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">lit</strong> distribution contains several example implementations of
+test suites in the <em>ExampleTests</em> directory.</p>
+</div>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>valgrind(1)</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="tblgen.html" title="tblgen - Target Description To C++ Code Generator"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llc.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llc.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llc.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llc.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,326 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llc - LLVM static compiler — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="lli - directly execute programs from LLVM bitcode" href="lli.html" />
+ <link rel="prev" title="opt - LLVM optimizer" href="opt.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="opt.html" title="opt - LLVM optimizer"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llc-llvm-static-compiler">
+<h1>llc - LLVM static compiler<a class="headerlink" href="#llc-llvm-static-compiler" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llc</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llc</strong> command compiles LLVM source inputs into assembly language
+for a specified architecture. The assembly language output can then be passed
+through a native assembler and linker to generate a native executable.</p>
+<p>The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the <a class="reference internal" href="llvm-mca.html#cmdoption-march"><em class="xref std std-option">-march</em></a> option is used to
+override the default.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p>If <tt class="docutils literal"><span class="pre">filename</span></tt> is “<tt class="docutils literal"><span class="pre">-</span></tt>” or omitted, <strong class="program">llc</strong> reads from standard input.
+Otherwise, it will from <tt class="docutils literal"><span class="pre">filename</span></tt>. Inputs can be in either the LLVM assembly
+language format (<tt class="docutils literal"><span class="pre">.ll</span></tt>) or the LLVM bitcode format (<tt class="docutils literal"><span class="pre">.bc</span></tt>).</p>
+<p>If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is omitted, then <strong class="program">llc</strong> will send its output
+to standard output if the input is from standard input. If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a>
+option specifies “<tt class="docutils literal"><span class="pre">-</span></tt>”, then the output will also be sent to standard output.</p>
+<p>If no <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is specified and an input file other than “<tt class="docutils literal"><span class="pre">-</span></tt>” is
+specified, then <strong class="program">llc</strong> creates the output filename by taking the input
+filename, removing any existing <tt class="docutils literal"><span class="pre">.bc</span></tt> extension, and adding a <tt class="docutils literal"><span class="pre">.s</span></tt> suffix.</p>
+<p>Other <strong class="program">llc</strong> options are described below.</p>
+<div class="section" id="end-user-options">
+<h3>End-user Options<a class="headerlink" href="#end-user-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-O">
+<tt class="descname">-O</tt><tt class="descclassname">=uint</tt><a class="headerlink" href="#cmdoption-O" title="Permalink to this definition">¶</a></dt>
+<dd><p>Generate code at different optimization levels. These correspond to the
+<tt class="docutils literal"><span class="pre">-O0</span></tt>, <tt class="docutils literal"><span class="pre">-O1</span></tt>, <tt class="docutils literal"><span class="pre">-O2</span></tt>, and <tt class="docutils literal"><span class="pre">-O3</span></tt> optimization levels used by
+<strong class="program">clang</strong>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mtriple">
+<tt class="descname">-mtriple</tt><tt class="descclassname">=<target triple></tt><a class="headerlink" href="#cmdoption-mtriple" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override the target triple specified in the input file with the specified
+string.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-march">
+<tt class="descname">-march</tt><tt class="descclassname">=<arch></tt><a class="headerlink" href="#cmdoption-march" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the architecture for which to generate assembly, overriding the target
+encoded in the input file. See the output of <tt class="docutils literal"><span class="pre">llc</span> <span class="pre">-help</span></tt> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mcpu">
+<tt class="descname">-mcpu</tt><tt class="descclassname">=<cpuname></tt><a class="headerlink" href="#cmdoption-mcpu" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:</p>
+<div class="highlight-none"><div class="highlight"><pre>llvm-as < /dev/null | llc -march=xyz -mcpu=help
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-filetype">
+<tt class="descname">-filetype</tt><tt class="descclassname">=<output file type></tt><a class="headerlink" href="#cmdoption-filetype" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify what kind of output <tt class="docutils literal"><span class="pre">llc</span></tt> should generated. Options are: <tt class="docutils literal"><span class="pre">asm</span></tt>
+for textual assembly ( <tt class="docutils literal"><span class="pre">'.s'</span></tt>), <tt class="docutils literal"><span class="pre">obj</span></tt> for native object files (<tt class="docutils literal"><span class="pre">'.o'</span></tt>)
+and <tt class="docutils literal"><span class="pre">null</span></tt> for not emitting anything (for performance testing).</p>
+<p>Note that not all targets support all options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mattr">
+<tt class="descname">-mattr</tt><tt class="descclassname">=a1,+a2,-a3,...</tt><a class="headerlink" href="#cmdoption-mattr" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:</p>
+<div class="highlight-none"><div class="highlight"><pre>llvm-as < /dev/null | llc -march=xyz -mattr=help
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--disable-fp-elim">
+<tt class="descname">--disable-fp-elim</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--disable-fp-elim" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable frame pointer elimination optimization.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--disable-excess-fp-precision">
+<tt class="descname">--disable-excess-fp-precision</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--disable-excess-fp-precision" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable optimizations that may produce excess precision for floating point.
+Note that this option can dramatically slow down code on some systems
+(e.g. X86).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-no-infs-fp-math">
+<tt class="descname">--enable-no-infs-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-no-infs-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no Inf values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-no-nans-fp-math">
+<tt class="descname">--enable-no-nans-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-no-nans-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no NAN values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--enable-unsafe-fp-math">
+<tt class="descname">--enable-unsafe-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--enable-unsafe-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that make unsafe assumptions about IEEE math (e.g. that
+addition is associative) or may not work for all input ranges. These
+optimizations allow the code generator to make use of some instructions which
+would otherwise not be usable (such as <tt class="docutils literal"><span class="pre">fsin</span></tt> on X86).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--stats">
+<tt class="descname">--stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print statistics recorded by code-generation passes.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--time-passes">
+<tt class="descname">--time-passes</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--time-passes" title="Permalink to this definition">¶</a></dt>
+<dd><p>Record the amount of time needed for each pass and print a report to standard
+error.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--load">
+<tt class="descname">--load</tt><tt class="descclassname">=<dso_path></tt><a class="headerlink" href="#cmdoption--load" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dynamically load <tt class="docutils literal"><span class="pre">dso_path</span></tt> (a path to a dynamically shared object) that
+implements an LLVM target. This will permit the target name to be used with
+the <a class="reference internal" href="llvm-mca.html#cmdoption-march"><em class="xref std std-option">-march</em></a> option so that code can be generated for that target.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-meabi">
+<tt class="descname">-meabi</tt><tt class="descclassname">=[default|gnu|4|5]</tt><a class="headerlink" href="#cmdoption-meabi" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify which EABI version should conform to. Valid EABI versions are <em>gnu</em>,
+<em>4</em> and <em>5</em>. Default value (<em>default</em>) depends on the triple.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-stack-size-section">
+<tt class="descname">-stack-size-section</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-stack-size-section" title="Permalink to this definition">¶</a></dt>
+<dd><p>Emit the .stack_sizes section which contains stack size metadata. The section
+contains an array of pairs of function symbol values (pointer size) and stack
+sizes (unsigned LEB128). The stack size values only include the space allocated
+in the function prologue. Functions with dynamic stack allocations are not
+included.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="tuning-configuration-options">
+<h3>Tuning/Configuration Options<a class="headerlink" href="#tuning-configuration-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption--print-machineinstrs">
+<tt class="descname">--print-machineinstrs</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--print-machineinstrs" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print generated machine code between compilation phases (useful for debugging).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--regalloc">
+<tt class="descname">--regalloc</tt><tt class="descclassname">=<allocator></tt><a class="headerlink" href="#cmdoption--regalloc" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the register allocator to use.
+Valid register allocators are:</p>
+<p><em>basic</em></p>
+<blockquote>
+<div>Basic register allocator.</div></blockquote>
+<p><em>fast</em></p>
+<blockquote>
+<div>Fast register allocator. It is the default for unoptimized code.</div></blockquote>
+<p><em>greedy</em></p>
+<blockquote>
+<div>Greedy register allocator. It is the default for optimized code.</div></blockquote>
+<p><em>pbqp</em></p>
+<blockquote>
+<div>Register allocator based on ‘Partitioned Boolean Quadratic Programming’.</div></blockquote>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--spiller">
+<tt class="descname">--spiller</tt><tt class="descclassname">=<spiller></tt><a class="headerlink" href="#cmdoption--spiller" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the spiller to use for register allocators that support it. Currently
+this option is used only by the linear scan register allocator. The default
+<tt class="docutils literal"><span class="pre">spiller</span></tt> is <em>local</em>. Valid spillers are:</p>
+<p><em>simple</em></p>
+<blockquote>
+<div>Simple spiller</div></blockquote>
+<p><em>local</em></p>
+<blockquote>
+<div>Local spiller</div></blockquote>
+</dd></dl>
+
+</div>
+<div class="section" id="intel-ia-32-specific-options">
+<h3>Intel IA-32-specific Options<a class="headerlink" href="#intel-ia-32-specific-options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption--x86-asm-syntax">
+<tt class="descname">--x86-asm-syntax</tt><tt class="descclassname">=[att|intel]</tt><a class="headerlink" href="#cmdoption--x86-asm-syntax" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify whether to emit assembly code in AT&T syntax (the default) or Intel
+syntax.</p>
+</dd></dl>
+
+</div>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llc</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>lli</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="opt.html" title="opt - LLVM optimizer"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/lli.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/lli.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/lli.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/lli.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,354 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>lli - directly execute programs from LLVM bitcode — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-link - LLVM bitcode linker" href="llvm-link.html" />
+ <link rel="prev" title="llc - LLVM static compiler" href="llc.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llc.html" title="llc - LLVM static compiler"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="lli-directly-execute-programs-from-llvm-bitcode">
+<h1>lli - directly execute programs from LLVM bitcode<a class="headerlink" href="#lli-directly-execute-programs-from-llvm-bitcode" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lli</strong> [<em>options</em>] [<em>filename</em>] [<em>program args</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">lli</strong> directly executes programs in LLVM bitcode format. It takes a program
+in LLVM bitcode format and executes it using a just-in-time compiler or an
+interpreter.</p>
+<p><strong class="program">lli</strong> is <em>not</em> an emulator. It will not execute IR of different architectures
+and it can only interpret (or JIT-compile) for the host architecture.</p>
+<p>The JIT compiler takes the same arguments as other tools, like <strong class="program">llc</strong>,
+but they don’t necessarily work for the interpreter.</p>
+<p>If <cite>filename</cite> is not specified, then <strong class="program">lli</strong> reads the LLVM bitcode for the
+program from standard input.</p>
+<p>The optional <em>args</em> specified on the command line are passed to the program as
+arguments.</p>
+</div>
+<div class="section" id="general-options">
+<h2>GENERAL OPTIONS<a class="headerlink" href="#general-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-fake-argv0">
+<tt class="descname">-fake-argv0</tt><tt class="descclassname">=executable</tt><a class="headerlink" href="#cmdoption-fake-argv0" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override the <tt class="docutils literal"><span class="pre">argv[0]</span></tt> value passed into the executing program.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-force-interpreter">
+<tt class="descname">-force-interpreter</tt><tt class="descclassname">={false,true}</tt><a class="headerlink" href="#cmdoption-force-interpreter" title="Permalink to this definition">¶</a></dt>
+<dd><p>If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-load">
+<tt class="descname">-load</tt><tt class="descclassname">=pluginfilename</tt><a class="headerlink" href="#cmdoption-load" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">lli</strong> to load the plugin (shared object) named <em>pluginfilename</em> and use
+it for optimization.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-stats">
+<tt class="descname">-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print statistics from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-time-passes">
+<tt class="descname">-time-passes</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-time-passes" title="Permalink to this definition">¶</a></dt>
+<dd><p>Record the amount of time needed for each code-generation pass and print it to
+standard error.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-version">
+<tt class="descname">-version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print out the version of <strong class="program">lli</strong> and exit without doing anything else.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="target-options">
+<h2>TARGET OPTIONS<a class="headerlink" href="#target-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-mtriple">
+<tt class="descname">-mtriple</tt><tt class="descclassname">=target triple</tt><a class="headerlink" href="#cmdoption-mtriple" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override the target triple specified in the input bitcode file with the
+specified string. This may result in a crash if you pick an
+architecture which is not compatible with the current system.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-march">
+<tt class="descname">-march</tt><tt class="descclassname">=arch</tt><a class="headerlink" href="#cmdoption-march" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the architecture for which to generate assembly, overriding the target
+encoded in the bitcode file. See the output of <strong>llc -help</strong> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mcpu">
+<tt class="descname">-mcpu</tt><tt class="descclassname">=cpuname</tt><a class="headerlink" href="#cmdoption-mcpu" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mcpu=help</strong></p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mattr">
+<tt class="descname">-mattr</tt><tt class="descclassname">=a1,+a2,-a3,...</tt><a class="headerlink" href="#cmdoption-mattr" title="Permalink to this definition">¶</a></dt>
+<dd><p>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mattr=help</strong></p>
+</dd></dl>
+
+</div>
+<div class="section" id="floating-point-options">
+<h2>FLOATING POINT OPTIONS<a class="headerlink" href="#floating-point-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-disable-excess-fp-precision">
+<tt class="descname">-disable-excess-fp-precision</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-disable-excess-fp-precision" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable optimizations that may increase floating point precision.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-enable-no-infs-fp-math">
+<tt class="descname">-enable-no-infs-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-enable-no-infs-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no Inf values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-enable-no-nans-fp-math">
+<tt class="descname">-enable-no-nans-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-enable-no-nans-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable optimizations that assume no NAN values.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-enable-unsafe-fp-math">
+<tt class="descname">-enable-unsafe-fp-math</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-enable-unsafe-fp-math" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">lli</strong> to enable optimizations that may decrease floating point
+precision.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-soft-float">
+<tt class="descname">-soft-float</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-soft-float" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">lli</strong> to generate software floating point library calls instead of
+equivalent hardware instructions.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="code-generation-options">
+<h2>CODE GENERATION OPTIONS<a class="headerlink" href="#code-generation-options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-code-model">
+<tt class="descname">-code-model</tt><tt class="descclassname">=model</tt><a class="headerlink" href="#cmdoption-code-model" title="Permalink to this definition">¶</a></dt>
+<dd><p>Choose the code model from:</p>
+<div class="highlight-text"><div class="highlight"><pre>default: Target default code model
+small: Small code model
+kernel: Kernel code model
+medium: Medium code model
+large: Large code model
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-disable-post-RA-scheduler">
+<tt class="descname">-disable-post-RA-scheduler</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-disable-post-RA-scheduler" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable scheduling after register allocation.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-disable-spill-fusing">
+<tt class="descname">-disable-spill-fusing</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-disable-spill-fusing" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disable fusing of spill code into instructions.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-jit-enable-eh">
+<tt class="descname">-jit-enable-eh</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-jit-enable-eh" title="Permalink to this definition">¶</a></dt>
+<dd><p>Exception handling should be enabled in the just-in-time compiler.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-join-liveintervals">
+<tt class="descname">-join-liveintervals</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-join-liveintervals" title="Permalink to this definition">¶</a></dt>
+<dd><p>Coalesce copies (default=true).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-nozero-initialized-in-bss">
+<tt class="descname">-nozero-initialized-in-bss</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-nozero-initialized-in-bss" title="Permalink to this definition">¶</a></dt>
+<dd><p>Don’t place zero-initialized symbols into the BSS section.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-pre-RA-sched">
+<tt class="descname">-pre-RA-sched</tt><tt class="descclassname">=scheduler</tt><a class="headerlink" href="#cmdoption-pre-RA-sched" title="Permalink to this definition">¶</a></dt>
+<dd><p>Instruction schedulers available (before register allocation):</p>
+<div class="highlight-text"><div class="highlight"><pre>=default: Best scheduler for the target
+=none: No scheduling: breadth first sequencing
+=simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
+=simple-noitin: Simple two pass scheduling: Same as simple except using generic latency
+=list-burr: Bottom-up register reduction list scheduling
+=list-tdrr: Top-down register reduction list scheduling
+=list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-regalloc">
+<tt class="descname">-regalloc</tt><tt class="descclassname">=allocator</tt><a class="headerlink" href="#cmdoption-regalloc" title="Permalink to this definition">¶</a></dt>
+<dd><p>Register allocator to use (default=linearscan)</p>
+<div class="highlight-text"><div class="highlight"><pre>=bigblock: Big-block register allocator
+=linearscan: linear scan register allocator =local - local register allocator
+=simple: simple register allocator
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-relocation-model">
+<tt class="descname">-relocation-model</tt><tt class="descclassname">=model</tt><a class="headerlink" href="#cmdoption-relocation-model" title="Permalink to this definition">¶</a></dt>
+<dd><p>Choose relocation model from:</p>
+<div class="highlight-text"><div class="highlight"><pre>=default: Target default relocation model
+=static: Non-relocatable code =pic - Fully relocatable, position independent code
+=dynamic-no-pic: Relocatable external references, non-relocatable code
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-spiller">
+<tt class="descname">-spiller</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-spiller" title="Permalink to this definition">¶</a></dt>
+<dd><p>Spiller to use (default=local)</p>
+<div class="highlight-text"><div class="highlight"><pre>=simple: simple spiller
+=local: local spiller
+</pre></div>
+</div>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-x86-asm-syntax">
+<tt class="descname">-x86-asm-syntax</tt><tt class="descclassname">=syntax</tt><a class="headerlink" href="#cmdoption-x86-asm-syntax" title="Permalink to this definition">¶</a></dt>
+<dd><p>Choose style of code to emit from X86 backend:</p>
+<div class="highlight-text"><div class="highlight"><pre>=att: Emit AT&T-style assembly
+=intel: Emit Intel-style assembly
+</pre></div>
+</div>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">lli</strong> fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llc</strong></p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llc.html" title="llc - LLVM static compiler"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-ar.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-ar.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-ar.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-ar.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,347 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-ar - LLVM archiver — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-lib - LLVM lib.exe compatible library tool" href="llvm-lib.html" />
+ <link rel="prev" title="llvm-link - LLVM bitcode linker" href="llvm-link.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-lib.html" title="llvm-lib - LLVM lib.exe compatible library tool"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-ar-llvm-archiver">
+<h1>llvm-ar - LLVM archiver<a class="headerlink" href="#llvm-ar-llvm-archiver" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-ar</strong> [-]{dmpqrtx}[Rabfikou] [relpos] [count] <archive> [files...]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-ar</strong> command is similar to the common Unix utility, <tt class="docutils literal"><span class="pre">ar</span></tt>. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bitcode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+<strong>llvm-ar</strong> generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.</p>
+<p>The <strong>llvm-ar</strong> command can be used to <em>read</em> SVR4, GNU and BSD style archive
+files. However, right now it can only write in the GNU format. If an
+SVR4 or BSD style archive is used with the <tt class="docutils literal"><span class="pre">r</span></tt> (replace) or <tt class="docutils literal"><span class="pre">q</span></tt> (quick
+update) operations, the archive will be reconstructed in GNU format.</p>
+<p>Here’s where <strong>llvm-ar</strong> departs from previous <tt class="docutils literal"><span class="pre">ar</span></tt> implementations:</p>
+<p><em>Symbol Table</em></p>
+<blockquote>
+<div>Since <strong>llvm-ar</strong> supports bitcode files. The symbol table it creates
+is in GNU format and includes both native and bitcode files.</div></blockquote>
+<p><em>Long Paths</em></p>
+<blockquote>
+<div>Currently <strong>llvm-ar</strong> can read GNU and BSD long file names, but only writes
+archives with the GNU format.</div></blockquote>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p>The options to <strong>llvm-ar</strong> are compatible with other <tt class="docutils literal"><span class="pre">ar</span></tt> implementations.
+However, there are a few modifiers (<em>R</em>) that are not found in other <tt class="docutils literal"><span class="pre">ar</span></tt>
+implementations. The options to <strong>llvm-ar</strong> specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the name of
+the archive file, and an optional list of file names. These options are used to
+determine how <strong>llvm-ar</strong> should process the archive file.</p>
+<p>The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a <tt class="docutils literal"><span class="pre">.a</span></tt> suffix, but this is not required. Following
+the <em>archive-name</em> comes a list of <em>files</em> that indicate the specific members
+of the archive to operate on. If the <em>files</em> option is not specified, it
+generally means either “none” or “all” members, depending on the operation.</p>
+<div class="section" id="operations">
+<h3>Operations<a class="headerlink" href="#operations" title="Permalink to this headline">¶</a></h3>
+<p>d</p>
+<blockquote>
+<div>Delete files from the archive. No modifiers are applicable to this operation.
+The <em>files</em> options specify which members should be removed from the
+archive. It is not an error if a specified file does not appear in the archive.
+If no <em>files</em> are specified, the archive is not modified.</div></blockquote>
+<p>m[abi]</p>
+<blockquote>
+<div>Move files from one location in the archive to another. The <em>a</em>, <em>b</em>, and
+<em>i</em> modifiers apply to this operation. The <em>files</em> will all be moved
+to the location given by the modifiers. If no modifiers are used, the files
+will be moved to the end of the archive. If no <em>files</em> are specified, the
+archive is not modified.</div></blockquote>
+<p>p</p>
+<blockquote>
+<div>Print files to the standard output. This operation simply prints the
+<em>files</em> indicated to the standard output. If no <em>files</em> are
+specified, the entire archive is printed. Printing bitcode files is
+ill-advised as they might confuse your terminal settings. The <em>p</em>
+operation never modifies the archive.</div></blockquote>
+<p>q</p>
+<blockquote>
+<div>Quickly append files to the end of the archive. This operation quickly adds the
+<em>files</em> to the archive without checking for duplicates that should be
+removed first. If no <em>files</em> are specified, the archive is not modified.
+Because of the way that <strong>llvm-ar</strong> constructs the archive file, its dubious
+whether the <em>q</em> operation is any faster than the <em>r</em> operation.</div></blockquote>
+<p>r[abu]</p>
+<blockquote>
+<div>Replace or insert file members. The <em>a</em>, <em>b</em>, and <em>u</em>
+modifiers apply to this operation. This operation will replace existing
+<em>files</em> or insert them at the end of the archive if they do not exist. If no
+<em>files</em> are specified, the archive is not modified.</div></blockquote>
+<p>t[v]</p>
+<blockquote>
+<div>Print the table of contents. Without any modifiers, this operation just prints
+the names of the members to the standard output. With the <em>v</em> modifier,
+<strong>llvm-ar</strong> also prints out the file type (B=bitcode, S=symbol
+table, blank=regular file), the permission mode, the owner and group, the
+size, and the date. If any <em>files</em> are specified, the listing is only for
+those files. If no <em>files</em> are specified, the table of contents for the
+whole archive is printed.</div></blockquote>
+<p>x[oP]</p>
+<blockquote>
+<div>Extract archive members back to files. The <em>o</em> modifier applies to this
+operation. This operation retrieves the indicated <em>files</em> from the archive
+and writes them back to the operating system’s file system. If no
+<em>files</em> are specified, the entire archive is extract.</div></blockquote>
+</div>
+<div class="section" id="modifiers-operation-specific">
+<h3>Modifiers (operation specific)<a class="headerlink" href="#modifiers-operation-specific" title="Permalink to this headline">¶</a></h3>
+<p>The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.</p>
+<p>[a]</p>
+<blockquote>
+<div>When inserting or moving member files, this option specifies the destination of
+the new files as being after the <em>relpos</em> member. If <em>relpos</em> is not found,
+the files are placed at the end of the archive.</div></blockquote>
+<p>[b]</p>
+<blockquote>
+<div>When inserting or moving member files, this option specifies the destination of
+the new files as being before the <em>relpos</em> member. If <em>relpos</em> is not
+found, the files are placed at the end of the archive. This modifier is
+identical to the <em>i</em> modifier.</div></blockquote>
+<p>[i]</p>
+<blockquote>
+<div>A synonym for the <em>b</em> option.</div></blockquote>
+<p>[o]</p>
+<blockquote>
+<div>When extracting files, this option will cause <strong>llvm-ar</strong> to preserve the
+original modification times of the files it writes.</div></blockquote>
+<p>[u]</p>
+<blockquote>
+<div>When replacing existing files in the archive, only replace those files that have
+a time stamp than the time stamp of the member in the archive.</div></blockquote>
+</div>
+<div class="section" id="modifiers-generic">
+<h3>Modifiers (generic)<a class="headerlink" href="#modifiers-generic" title="Permalink to this headline">¶</a></h3>
+<p>The modifiers below may be applied to any operation.</p>
+<p>[c]</p>
+<blockquote>
+<div>For all operations, <strong>llvm-ar</strong> will always create the archive if it doesn’t
+exist. Normally, <strong>llvm-ar</strong> will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.</div></blockquote>
+<p>[s]</p>
+<blockquote>
+<div>This modifier requests that an archive index (or symbol table) be added to the
+archive. This is the default mode of operation. The symbol table will contain
+all the externally visible functions and global variables defined by all the
+bitcode files in the archive.</div></blockquote>
+<p>[S]</p>
+<blockquote>
+<div>This modifier is the opposite of the <em>s</em> modifier. It instructs <strong>llvm-ar</strong> to
+not build the symbol table. If both <em>s</em> and <em>S</em> are used, the last modifier to
+occur in the options will prevail.</div></blockquote>
+<p>[v]</p>
+<blockquote>
+<div>This modifier instructs <strong>llvm-ar</strong> to be verbose about what it is doing. Each
+editing operation taken against the archive will produce a line of output saying
+what is being done.</div></blockquote>
+</div>
+</div>
+<div class="section" id="standards">
+<h2>STANDARDS<a class="headerlink" href="#standards" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-ar</strong> utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for <tt class="docutils literal"><span class="pre">ar</span></tt>. <strong>llvm-ar</strong> can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the <tt class="docutils literal"><span class="pre">f</span></tt> modifier is given to the <tt class="docutils literal"><span class="pre">x</span></tt> or <tt class="docutils literal"><span class="pre">r</span></tt> operations
+then <strong>llvm-ar</strong> will write SVR4 compatible archives. Without this modifier,
+<strong>llvm-ar</strong> will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the “#1/ddd” notation for the
+name in the header.</p>
+</div>
+<div class="section" id="file-format">
+<h2>FILE FORMAT<a class="headerlink" href="#file-format" title="Permalink to this headline">¶</a></h2>
+<p>The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the <tt class="docutils literal"><span class="pre">ar</span></tt> commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.</p>
+<p>Each archive begins with the archive magic number which is the eight printable
+characters ”!<arch>n” where n represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a n padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated “long file name” and the contents of
+the file.</p>
+<p>The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded
+with space characters.</p>
+<p>name - char[16]</p>
+<blockquote>
+<div>This field of the header provides the name of the archive member. If the name is
+longer than 15 characters or contains a slash (/) character, then this field
+contains <tt class="docutils literal"><span class="pre">#1/nnn</span></tt> where <tt class="docutils literal"><span class="pre">nnn</span></tt> provides the length of the name and the <tt class="docutils literal"><span class="pre">#1/</span></tt>
+is literal. In this case, the actual name of the file is provided in the <tt class="docutils literal"><span class="pre">nnn</span></tt>
+bytes immediately following the header. If the name is 15 characters or less, it
+is contained directly in this field and terminated with a slash (/) character.</div></blockquote>
+<p>date - char[12]</p>
+<blockquote>
+<div>This field provides the date of modification of the file in the form of a
+decimal encoded number that provides the number of seconds since the epoch
+(since 00:00:00 Jan 1, 1970) per Posix specifications.</div></blockquote>
+<p>uid - char[6]</p>
+<blockquote>
+<div>This field provides the user id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_uid field of the stat structure returned by the stat(2)
+operating system call.</div></blockquote>
+<p>gid - char[6]</p>
+<blockquote>
+<div>This field provides the group id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_gid field of the stat structure returned by the stat(2)
+operating system call.</div></blockquote>
+<p>mode - char[8]</p>
+<blockquote>
+<div>This field provides the access mode of the file encoded as an octal ASCII
+string. This field might not make much sense on non-Unix systems. On Unix, it
+is the same value as the st_mode field of the stat structure returned by the
+stat(2) operating system call.</div></blockquote>
+<p>size - char[10]</p>
+<blockquote>
+<div>This field provides the size of the file, in bytes, encoded as a decimal ASCII
+string.</div></blockquote>
+<p>fmag - char[2]</p>
+<blockquote>
+<div>This field is the archive file member magic number. Its content is always the
+two characters back tick (0x60) and newline (0x0A). This provides some measure
+utility in identifying archive files that have been corrupted.</div></blockquote>
+<p>offset - vbr encoded 32-bit integer</p>
+<blockquote>
+<div>The offset item provides the offset into the archive file where the bitcode
+member is stored that is associated with the symbol. The offset value is 0
+based at the start of the first “normal” file member. To derive the actual
+file offset of the member, you must add the number of bytes occupied by the file
+signature (8 bytes) and the symbol tables. The value of this item is encoded
+using variable bit rate encoding to reduce the size of the symbol table.
+Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+from the value. The final byte does not have the high bit set.</div></blockquote>
+<p>length - vbr encoded 32-bit integer</p>
+<blockquote>
+<div>The length item provides the length of the symbol that follows. Like this
+<em>offset</em> item, the length is variable bit rate encoded.</div></blockquote>
+<p>symbol - character array</p>
+<blockquote>
+<div>The symbol item provides the text of the symbol that is associated with the
+<em>offset</em>. The symbol is not terminated by any character. Its length is provided
+by the <em>length</em> field. Note that is allowed (but unwise) to use non-printing
+characters (even 0x00) in the symbol. This allows for multiple encodings of
+symbol names.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-ar</strong> succeeds, it will exit with 0. A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>ar(1)</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-lib.html" title="llvm-lib - LLVM lib.exe compatible library tool"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-link.html" title="llvm-link - LLVM bitcode linker"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-as.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-as.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-as.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-as.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,148 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-as - LLVM assembler — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-dis - LLVM disassembler" href="llvm-dis.html" />
+ <link rel="prev" title="LLVM Command Guide" href="index.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-dis.html" title="llvm-dis - LLVM disassembler"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="index.html" title="LLVM Command Guide"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-as-llvm-assembler">
+<h1>llvm-as - LLVM assembler<a class="headerlink" href="#llvm-as-llvm-assembler" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-as</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-as</strong> is the LLVM assembler. It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bitcode, and writes the result
+into a file or to standard output.</p>
+<p>If <em>filename</em> is omitted or is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong>llvm-as</strong> reads its input from
+standard input.</p>
+<p>If an output file is not specified with the <strong>-o</strong> option, then
+<strong>llvm-as</strong> sends its output to a file or standard output by following
+these rules:</p>
+<ul class="simple">
+<li>If the input is standard input, then the output is standard output.</li>
+<li>If the input is a file that ends with <tt class="docutils literal"><span class="pre">.ll</span></tt>, then the output file is of the
+same name, except that the suffix is changed to <tt class="docutils literal"><span class="pre">.bc</span></tt>.</li>
+<li>If the input is a file that does not end with the <tt class="docutils literal"><span class="pre">.ll</span></tt> suffix, then the
+output file has the same name as the input file, except that the <tt class="docutils literal"><span class="pre">.bc</span></tt>
+suffix is appended.</li>
+</ul>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="docutils">
+<dt><strong>-f</strong></dt>
+<dd>Enable binary output on terminals. Normally, <strong>llvm-as</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-as</strong> will write raw bitcode regardless of the output device.</dd>
+<dt><strong>-help</strong></dt>
+<dd>Print a summary of command line options.</dd>
+<dt><strong>-o</strong> <em>filename</em></dt>
+<dd>Specify the output file name. If <em>filename</em> is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong>llvm-as</strong>
+sends its output to standard output.</dd>
+</dl>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-as</strong> succeeds, it will exit with 0. Otherwise, if an error occurs, it
+will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>llvm-dis|llvm-dis, gccas|gccas</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-dis.html" title="llvm-dis - LLVM disassembler"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="index.html" title="LLVM Command Guide"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-bcanalyzer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-bcanalyzer.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-bcanalyzer.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-bcanalyzer.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,354 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-bcanalyzer - LLVM bitcode analyzer — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="FileCheck - Flexible pattern matching file verifier" href="FileCheck.html" />
+ <link rel="prev" title="llvm-extract - extract a function from an LLVM module" href="llvm-extract.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="FileCheck.html" title="FileCheck - Flexible pattern matching file verifier"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-bcanalyzer-llvm-bitcode-analyzer">
+<h1>llvm-bcanalyzer - LLVM bitcode analyzer<a class="headerlink" href="#llvm-bcanalyzer-llvm-bitcode-analyzer" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-bcanalyzer</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llvm-bcanalyzer</strong> command is a small utility for analyzing bitcode
+files. The tool reads a bitcode file (such as generated with the
+<strong class="program">llvm-as</strong> tool) and produces a statistical report on the contents of
+the bitcode file. The tool can also dump a low level but human readable
+version of the bitcode file. This tool is probably not of much interest or
+utility except for those working directly with the bitcode file format. Most
+LLVM users can just ignore this tool.</p>
+<p>If <em>filename</em> is omitted or is <tt class="docutils literal"><span class="pre">-</span></tt>, then <strong class="program">llvm-bcanalyzer</strong> reads its
+input from standard input. This is useful for combining the tool into a
+pipeline. Output is written to the standard output.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-nodetails">
+<tt class="descname">-nodetails</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-nodetails" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to abbreviate its output by writing out only
+a module level summary. The details for individual functions are not
+displayed.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-dump">
+<tt class="descname">-dump</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-dump" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to dump the bitcode in a human readable
+format. This format is significantly different from LLVM assembly and
+provides details about the encoding of the bitcode file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-verify">
+<tt class="descname">-verify</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-verify" title="Permalink to this definition">¶</a></dt>
+<dd><p>Causes <strong class="program">llvm-bcanalyzer</strong> to verify the module produced by reading the
+bitcode. This ensures that the statistics generated are based on a consistent
+module.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-bcanalyzer-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-bcanalyzer-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llvm-bcanalyzer</strong> succeeds, it will exit with 0. Otherwise, if an
+error occurs, it will exit with a non-zero value, usually 1.</p>
+</div>
+<div class="section" id="summary-output-definitions">
+<h2>SUMMARY OUTPUT DEFINITIONS<a class="headerlink" href="#summary-output-definitions" title="Permalink to this headline">¶</a></h2>
+<p>The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.</p>
+<p><strong>Bitcode Analysis Of Module</strong></p>
+<blockquote>
+<div>This just provides the name of the module for which bitcode analysis is being
+generated.</div></blockquote>
+<p><strong>Bitcode Version Number</strong></p>
+<blockquote>
+<div>The bitcode version (not LLVM version) of the file read by the analyzer.</div></blockquote>
+<p><strong>File Size</strong></p>
+<blockquote>
+<div>The size, in bytes, of the entire bitcode file.</div></blockquote>
+<p><strong>Module Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the module block. Percentage is relative to File Size.</div></blockquote>
+<p><strong>Function Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the function blocks. Percentage is relative to File
+Size.</div></blockquote>
+<p><strong>Global Types Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the Global Types Pool. Percentage is relative to File
+Size. This is the size of the definitions of all types in the bitcode file.</div></blockquote>
+<p><strong>Constant Pool Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.</div></blockquote>
+<p><strong>Module Globals Bytes</strong></p>
+<blockquote>
+<div>Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.</div></blockquote>
+<p><strong>Instruction List Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the instruction lists in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.</div></blockquote>
+<p><strong>Compaction Table Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the compaction tables in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.</div></blockquote>
+<p><strong>Symbol Table Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of all the symbol tables in all the functions. Percentage is
+relative to File Size. Note that this value is also included in the Function
+Bytes.</div></blockquote>
+<p><strong>Dependent Libraries Bytes</strong></p>
+<blockquote>
+<div>The size, in bytes, of the list of dependent libraries in the module. Percentage
+is relative to File Size. Note that this value is also included in the Module
+Global Bytes.</div></blockquote>
+<p><strong>Number Of Bitcode Blocks</strong></p>
+<blockquote>
+<div>The total number of blocks of any kind in the bitcode file.</div></blockquote>
+<p><strong>Number Of Functions</strong></p>
+<blockquote>
+<div>The total number of function definitions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Types</strong></p>
+<blockquote>
+<div>The total number of types defined in the Global Types Pool.</div></blockquote>
+<p><strong>Number Of Constants</strong></p>
+<blockquote>
+<div>The total number of constants (of any type) defined in the Constant Pool.</div></blockquote>
+<p><strong>Number Of Basic Blocks</strong></p>
+<blockquote>
+<div>The total number of basic blocks defined in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Instructions</strong></p>
+<blockquote>
+<div>The total number of instructions defined in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Long Instructions</strong></p>
+<blockquote>
+<div>The total number of long instructions defined in all functions in the bitcode
+file. Long instructions are those taking greater than 4 bytes. Typically long
+instructions are GetElementPtr with several indices, PHI nodes, and calls to
+functions with large numbers of arguments.</div></blockquote>
+<p><strong>Number Of Operands</strong></p>
+<blockquote>
+<div>The total number of operands used in all instructions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Compaction Tables</strong></p>
+<blockquote>
+<div>The total number of compaction tables in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Symbol Tables</strong></p>
+<blockquote>
+<div>The total number of symbol tables in all functions in the bitcode file.</div></blockquote>
+<p><strong>Number Of Dependent Libs</strong></p>
+<blockquote>
+<div>The total number of dependent libraries found in the bitcode file.</div></blockquote>
+<p><strong>Total Instruction Size</strong></p>
+<blockquote>
+<div>The total size of the instructions in all functions in the bitcode file.</div></blockquote>
+<p><strong>Average Instruction Size</strong></p>
+<blockquote>
+<div>The average number of bytes per instruction across all functions in the bitcode
+file. This value is computed by dividing Total Instruction Size by Number Of
+Instructions.</div></blockquote>
+<p><strong>Maximum Type Slot Number</strong></p>
+<blockquote>
+<div>The maximum value used for a type’s slot number. Larger slot number values take
+more bytes to encode.</div></blockquote>
+<p><strong>Maximum Value Slot Number</strong></p>
+<blockquote>
+<div>The maximum value used for a value’s slot number. Larger slot number values take
+more bytes to encode.</div></blockquote>
+<p><strong>Bytes Per Value</strong></p>
+<blockquote>
+<div>The average size of a Value definition (of any type). This is computed by
+dividing File Size by the total number of values of any type.</div></blockquote>
+<p><strong>Bytes Per Global</strong></p>
+<blockquote>
+<div>The average size of a global definition (constants and global variables).</div></blockquote>
+<p><strong>Bytes Per Function</strong></p>
+<blockquote>
+<div>The average number of bytes per function definition. This is computed by
+dividing Function Bytes by Number Of Functions.</div></blockquote>
+<p><strong># of VBR 32-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 32-bit integers encoded using the Variable Bit Rate
+encoding scheme.</div></blockquote>
+<p><strong># of VBR 64-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+scheme.</div></blockquote>
+<p><strong># of VBR Compressed Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes consumed by the 32-bit and 64-bit integers that use
+the Variable Bit Rate encoding scheme.</div></blockquote>
+<p><strong># of VBR Expanded Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes that would have been consumed by the 32-bit and 64-bit
+integers had they not been compressed with the Variable Bit Rage encoding
+scheme.</div></blockquote>
+<p><strong>Bytes Saved With VBR</strong></p>
+<blockquote>
+<div>The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of VBR Expanded Bytes.</div></blockquote>
+</div>
+<div class="section" id="detailed-output-definitions">
+<h2>DETAILED OUTPUT DEFINITIONS<a class="headerlink" href="#detailed-output-definitions" title="Permalink to this headline">¶</a></h2>
+<p>The following definitions occur only if the -nodetails option was not given.
+The detailed output provides additional information on a per-function basis.</p>
+<p><strong>Type</strong></p>
+<blockquote>
+<div>The type signature of the function.</div></blockquote>
+<p><strong>Byte Size</strong></p>
+<blockquote>
+<div>The total number of bytes in the function’s block.</div></blockquote>
+<p><strong>Basic Blocks</strong></p>
+<blockquote>
+<div>The number of basic blocks defined by the function.</div></blockquote>
+<p><strong>Instructions</strong></p>
+<blockquote>
+<div>The number of instructions defined by the function.</div></blockquote>
+<p><strong>Long Instructions</strong></p>
+<blockquote>
+<div>The number of instructions using the long instruction format in the function.</div></blockquote>
+<p><strong>Operands</strong></p>
+<blockquote>
+<div>The number of operands used by all instructions in the function.</div></blockquote>
+<p><strong>Instruction Size</strong></p>
+<blockquote>
+<div>The number of bytes consumed by instructions in the function.</div></blockquote>
+<p><strong>Average Instruction Size</strong></p>
+<blockquote>
+<div>The average number of bytes consumed by the instructions in the function.
+This value is computed by dividing Instruction Size by Instructions.</div></blockquote>
+<p><strong>Bytes Per Instruction</strong></p>
+<blockquote>
+<div>The average number of bytes used by the function per instruction. This value
+is computed by dividing Byte Size by Instructions. Note that this is not the
+same as Average Instruction Size. It computes a number relative to the total
+function size not just the size of the instruction list.</div></blockquote>
+<p><strong>Number of VBR 32-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 32-bit integers found in this function (for any use).</div></blockquote>
+<p><strong>Number of VBR 64-bit Integers</strong></p>
+<blockquote>
+<div>The total number of 64-bit integers found in this function (for any use).</div></blockquote>
+<p><strong>Number of VBR Compressed Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes in this function consumed by the 32-bit and 64-bit
+integers that use the Variable Bit Rate encoding scheme.</div></blockquote>
+<p><strong>Number of VBR Expanded Bytes</strong></p>
+<blockquote>
+<div>The total number of bytes in this function that would have been consumed by
+the 32-bit and 64-bit integers had they not been compressed with the Variable
+Bit Rate encoding scheme.</div></blockquote>
+<p><strong>Bytes Saved With VBR</strong></p>
+<blockquote>
+<div>The total number of bytes saved in this function by using the Variable Bit
+Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.</div></blockquote>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p><a class="reference internal" href="llvm-dis.html"><em>llvm-dis - LLVM disassembler</em></a>, <a class="reference internal" href="../BitCodeFormat.html"><em>LLVM Bitcode File Format</em></a></p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="FileCheck.html" title="FileCheck - Flexible pattern matching file verifier"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-extract.html" title="llvm-extract - extract a function from an LLVM module"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-build.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-build.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-build.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-build.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,165 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-build - LLVM Project Build Utility — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-exegesis - LLVM Machine Instruction Benchmark" href="llvm-exegesis.html" />
+ <link rel="prev" title="lit - LLVM Integrated Tester" href="lit.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-exegesis.html" title="llvm-exegesis - LLVM Machine Instruction Benchmark"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="lit.html" title="lit - LLVM Integrated Tester"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-build-llvm-project-build-utility">
+<h1>llvm-build - LLVM Project Build Utility<a class="headerlink" href="#llvm-build-llvm-project-build-utility" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> [<em>options</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> is a tool for working with LLVM projects that use the LLVMBuild
+system for describing their components.</p>
+<p>At heart, <strong>llvm-build</strong> is responsible for loading, verifying, and manipulating
+the project’s component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-h</strong>, <strong>–help</strong></p>
+<blockquote>
+<div>Print the builtin program help.</div></blockquote>
+<p><strong>–source-root</strong>=<em>PATH</em></p>
+<blockquote>
+<div>If given, load the project at the given source root path. If this option is not
+given, the location of the project sources will be inferred from the location of
+the <strong>llvm-build</strong> script itself.</div></blockquote>
+<p><strong>–print-tree</strong></p>
+<blockquote>
+<div>Print the component tree for the project.</div></blockquote>
+<p><strong>–write-library-table</strong></p>
+<blockquote>
+<div>Write out the C++ fragment which defines the components, library names, and
+required libraries. This C++ fragment is built into llvm-config|llvm-config
+in order to provide clients with the list of required libraries for arbitrary
+component combinations.</div></blockquote>
+<p><strong>–write-llvmbuild</strong></p>
+<blockquote>
+<div>Write out new <em>LLVMBuild.txt</em> files based on the loaded components. This is
+useful for auto-upgrading the schema of the files. <strong>llvm-build</strong> will try to a
+limited extent to preserve the comments which were written in the original
+source file, although at this time it only preserves block comments that precede
+the section names in the <em>LLVMBuild</em> files.</div></blockquote>
+<p><strong>–write-cmake-fragment</strong></p>
+<blockquote>
+<div>Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see LLVM’s
+top-level CMakeLists.txt.</div></blockquote>
+<p><strong>–write-make-fragment</strong></p>
+<blockquote>
+<div>Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+consumed by a Make based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+LLVM’s Makefile.rules.</div></blockquote>
+<p><strong>–llvmbuild-source-root</strong>=<em>PATH</em></p>
+<blockquote>
+<div>If given, expect the <em>LLVMBuild</em> files for the project to be rooted at the
+given path, instead of inside the source tree itself. This option is primarily
+designed for use in conjunction with <strong>–write-llvmbuild</strong> to test changes to
+<em>LLVMBuild</em> schema.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-build</strong> exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-exegesis.html" title="llvm-exegesis - LLVM Machine Instruction Benchmark"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="lit.html" title="lit - LLVM Integrated Tester"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-config.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-config.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-config.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-config.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,197 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-config - Print LLVM compilation options — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-diff - LLVM structural âdiffâ" href="llvm-diff.html" />
+ <link rel="prev" title="llvm-nm - list LLVM bitcode and object fileâs symbol table" href="llvm-nm.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-diff.html" title="llvm-diff - LLVM structural âdiffâ"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object fileâs symbol table"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-config-print-llvm-compilation-options">
+<h1>llvm-config - Print LLVM compilation options<a class="headerlink" href="#llvm-config-print-llvm-compilation-options" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-config</strong> <em>option</em> [<em>components</em>...]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-config</strong> makes it easier to build applications that use LLVM. It can
+print the compiler flags, linker flags and object libraries needed to link
+against LLVM.</p>
+</div>
+<div class="section" id="examples">
+<h2>EXAMPLES<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
+<p>To link against the JIT:</p>
+<div class="highlight-sh"><div class="highlight"><pre>g++ <span class="sb">`</span>llvm-config --cxxflags<span class="sb">`</span> -o HowToUseJIT.o -c HowToUseJIT.cpp
+g++ <span class="sb">`</span>llvm-config --ldflags<span class="sb">`</span> -o HowToUseJIT HowToUseJIT.o <span class="se">\</span>
+ <span class="sb">`</span>llvm-config --libs engine bcreader scalaropts<span class="sb">`</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>–version</strong></p>
+<blockquote>
+<div>Print the version number of LLVM.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of <strong>llvm-config</strong> arguments.</div></blockquote>
+<p><strong>–prefix</strong></p>
+<blockquote>
+<div>Print the installation prefix for LLVM.</div></blockquote>
+<p><strong>–src-root</strong></p>
+<blockquote>
+<div>Print the source root from which LLVM was built.</div></blockquote>
+<p><strong>–obj-root</strong></p>
+<blockquote>
+<div>Print the object root used to build LLVM.</div></blockquote>
+<p><strong>–bindir</strong></p>
+<blockquote>
+<div>Print the installation directory for LLVM binaries.</div></blockquote>
+<p><strong>–includedir</strong></p>
+<blockquote>
+<div>Print the installation directory for LLVM headers.</div></blockquote>
+<p><strong>–libdir</strong></p>
+<blockquote>
+<div>Print the installation directory for LLVM libraries.</div></blockquote>
+<p><strong>–cxxflags</strong></p>
+<blockquote>
+<div>Print the C++ compiler flags needed to use LLVM headers.</div></blockquote>
+<p><strong>–ldflags</strong></p>
+<blockquote>
+<div>Print the flags needed to link against LLVM libraries.</div></blockquote>
+<p><strong>–libs</strong></p>
+<blockquote>
+<div>Print all the libraries needed to link against the specified LLVM
+<em>components</em>, including any dependencies.</div></blockquote>
+<p><strong>–libnames</strong></p>
+<blockquote>
+<div>Similar to <strong>–libs</strong>, but prints the bare filenames of the libraries
+without <strong>-l</strong> or pathnames. Useful for linking against a not-yet-installed
+copy of LLVM.</div></blockquote>
+<p><strong>–libfiles</strong></p>
+<blockquote>
+<div>Similar to <strong>–libs</strong>, but print the full path to each library file. This is
+useful when creating makefile dependencies, to ensure that a tool is relinked if
+any library it uses changes.</div></blockquote>
+<p><strong>–components</strong></p>
+<blockquote>
+<div>Print all valid component names.</div></blockquote>
+<p><strong>–targets-built</strong></p>
+<blockquote>
+<div>Print the component names for all targets supported by this copy of LLVM.</div></blockquote>
+<p><strong>–build-mode</strong></p>
+<blockquote>
+<div>Print the build mode used when LLVM was built (e.g. Debug or Release)</div></blockquote>
+</div>
+<div class="section" id="components">
+<h2>COMPONENTS<a class="headerlink" href="#components" title="Permalink to this headline">¶</a></h2>
+<p>To print a list of all available components, run <strong>llvm-config
+–components</strong>. In most cases, components correspond directly to LLVM
+libraries. Useful “virtual” components include:</p>
+<p><strong>all</strong></p>
+<blockquote>
+<div>Includes all LLVM libraries. The default if no components are specified.</div></blockquote>
+<p><strong>backend</strong></p>
+<blockquote>
+<div>Includes either a native backend or the C backend.</div></blockquote>
+<p><strong>engine</strong></p>
+<blockquote>
+<div>Includes either a native JIT or the bitcode interpreter.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-config</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-diff.html" title="llvm-diff - LLVM structural âdiffâ"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object fileâs symbol table"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-cov.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-cov.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-cov.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-cov.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,546 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-cov - emit coverage information — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-profdata - Profile data tool" href="llvm-profdata.html" />
+ <link rel="prev" title="llvm-diff - LLVM structural âdiffâ" href="llvm-diff.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-profdata.html" title="llvm-profdata - Profile data tool"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-diff.html" title="llvm-diff - LLVM structural âdiffâ"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-cov-emit-coverage-information">
+<h1>llvm-cov - emit coverage information<a class="headerlink" href="#llvm-cov-emit-coverage-information" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-cov</strong> <em>command</em> [<em>args...</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llvm-cov</strong> tool shows code coverage information for
+programs that are instrumented to emit profile data. It can be used to
+work with <tt class="docutils literal"><span class="pre">gcov</span></tt>-style coverage or with <tt class="docutils literal"><span class="pre">clang</span></tt>‘s instrumentation
+based profiling.</p>
+<p>If the program is invoked with a base name of <tt class="docutils literal"><span class="pre">gcov</span></tt>, it will behave as if
+the <strong class="program">llvm-cov gcov</strong> command were called. Otherwise, a command should
+be provided.</p>
+</div>
+<div class="section" id="commands">
+<h2>COMMANDS<a class="headerlink" href="#commands" title="Permalink to this headline">¶</a></h2>
+<ul class="simple">
+<li><a class="reference internal" href="#llvm-cov-gcov"><em>gcov</em></a></li>
+<li><a class="reference internal" href="#llvm-cov-show"><em>show</em></a></li>
+<li><a class="reference internal" href="#llvm-cov-report"><em>report</em></a></li>
+<li><a class="reference internal" href="#llvm-cov-export"><em>export</em></a></li>
+</ul>
+</div>
+<div class="section" id="gcov-command">
+<span id="llvm-cov-gcov"></span><h2>GCOV COMMAND<a class="headerlink" href="#gcov-command" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="id1">
+<h3>SYNOPSIS<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">llvm-cov gcov</strong> [<em>options</em>] <em>SOURCEFILE</em></p>
+</div>
+<div class="section" id="id2">
+<h3>DESCRIPTION<a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">llvm-cov gcov</strong> tool reads code coverage data files and displays
+the coverage information for a specified source file. It is compatible with the
+<tt class="docutils literal"><span class="pre">gcov</span></tt> tool from version 4.2 of <tt class="docutils literal"><span class="pre">GCC</span></tt> and may also be compatible with some
+later versions of <tt class="docutils literal"><span class="pre">gcov</span></tt>.</p>
+<p>To use <strong class="program">llvm-cov gcov</strong>, you must first build an instrumented version
+of your application that collects coverage data as it runs. Compile with the
+<tt class="docutils literal"><span class="pre">-fprofile-arcs</span></tt> and <tt class="docutils literal"><span class="pre">-ftest-coverage</span></tt> options to add the
+instrumentation. (Alternatively, you can use the <tt class="docutils literal"><span class="pre">--coverage</span></tt> option, which
+includes both of those other options.) You should compile with debugging
+information (<tt class="docutils literal"><span class="pre">-g</span></tt>) and without optimization (<tt class="docutils literal"><span class="pre">-O0</span></tt>); otherwise, the
+coverage data cannot be accurately mapped back to the source code.</p>
+<p>At the time you compile the instrumented code, a <tt class="docutils literal"><span class="pre">.gcno</span></tt> data file will be
+generated for each object file. These <tt class="docutils literal"><span class="pre">.gcno</span></tt> files contain half of the
+coverage data. The other half of the data comes from <tt class="docutils literal"><span class="pre">.gcda</span></tt> files that are
+generated when you run the instrumented program, with a separate <tt class="docutils literal"><span class="pre">.gcda</span></tt>
+file for each object file. Each time you run the program, the execution counts
+are summed into any existing <tt class="docutils literal"><span class="pre">.gcda</span></tt> files, so be sure to remove any old
+files if you do not want their contents to be included.</p>
+<p>By default, the <tt class="docutils literal"><span class="pre">.gcda</span></tt> files are written into the same directory as the
+object files, but you can override that by setting the <tt class="docutils literal"><span class="pre">GCOV_PREFIX</span></tt> and
+<tt class="docutils literal"><span class="pre">GCOV_PREFIX_STRIP</span></tt> environment variables. The <tt class="docutils literal"><span class="pre">GCOV_PREFIX_STRIP</span></tt>
+variable specifies a number of directory components to be removed from the
+start of the absolute path to the object file directory. After stripping those
+directories, the prefix from the <tt class="docutils literal"><span class="pre">GCOV_PREFIX</span></tt> variable is added. These
+environment variables allow you to run the instrumented program on a machine
+where the original object file directories are not accessible, but you will
+then need to copy the <tt class="docutils literal"><span class="pre">.gcda</span></tt> files back to the object file directories
+where <strong class="program">llvm-cov gcov</strong> expects to find them.</p>
+<p>Once you have generated the coverage data files, run <strong class="program">llvm-cov gcov</strong>
+for each main source file where you want to examine the coverage results. This
+should be run from the same directory where you previously ran the
+compiler. The results for the specified source file are written to a file named
+by appending a <tt class="docutils literal"><span class="pre">.gcov</span></tt> suffix. A separate output file is also created for
+each file included by the main source file, also with a <tt class="docutils literal"><span class="pre">.gcov</span></tt> suffix added.</p>
+<p>The basic content of an <tt class="docutils literal"><span class="pre">.gcov</span></tt> output file is a copy of the source file with
+an execution count and line number prepended to every line. The execution
+count is shown as <tt class="docutils literal"><span class="pre">-</span></tt> if a line does not contain any executable code. If
+a line contains code but that code was never executed, the count is displayed
+as <tt class="docutils literal"><span class="pre">#####</span></tt>.</p>
+</div>
+<div class="section" id="options">
+<h3>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-a">
+<tt class="descname">-a</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--all-blocks</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-a" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display all basic blocks. If there are multiple blocks for a single line of
+source code, this option causes llvm-cov to show the count for each block
+instead of just one count for the entire line.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-b">
+<tt class="descname">-b</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--branch-probabilities</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-b" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display conditional branch probabilities and a summary of branch information.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-c">
+<tt class="descname">-c</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--branch-counts</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-c" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display branch counts instead of probabilities (requires -b).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-f">
+<tt class="descname">-f</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--function-summaries</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-f" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show a summary of coverage for each function instead of just one summary for
+an entire source file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov--help">
+<tt class="descname">--help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov--help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display available options (–help-hidden for more).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-l">
+<tt class="descname">-l</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--long-file-names</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-l" title="Permalink to this definition">¶</a></dt>
+<dd><p>For coverage output of files included from the main source file, add the
+main file name followed by <tt class="docutils literal"><span class="pre">##</span></tt> as a prefix to the output file names. This
+can be combined with the –preserve-paths option to use complete paths for
+both the main file and the included file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-n">
+<tt class="descname">-n</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--no-output</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-n" title="Permalink to this definition">¶</a></dt>
+<dd><p>Do not output any <tt class="docutils literal"><span class="pre">.gcov</span></tt> files. Summary information is still
+displayed.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-o">
+<tt class="descname">-o</tt><tt class="descclassname">=<DIR|FILE></tt><tt class="descclassname">, </tt><tt class="descname">--object-directory</tt><tt class="descclassname">=<DIR></tt><tt class="descclassname">, </tt><tt class="descname">--object-file</tt><tt class="descclassname">=<FILE></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-o" title="Permalink to this definition">¶</a></dt>
+<dd><p>Find objects in DIR or based on FILE’s path. If you specify a particular
+object file, the coverage data files are expected to have the same base name
+with <tt class="docutils literal"><span class="pre">.gcno</span></tt> and <tt class="docutils literal"><span class="pre">.gcda</span></tt> extensions. If you specify a directory, the
+files are expected in that directory with the same base name as the source
+file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-p">
+<tt class="descname">-p</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--preserve-paths</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-p" title="Permalink to this definition">¶</a></dt>
+<dd><p>Preserve path components when naming the coverage output files. In addition
+to the source file name, include the directories from the path to that
+file. The directories are separate by <tt class="docutils literal"><span class="pre">#</span></tt> characters, with <tt class="docutils literal"><span class="pre">.</span></tt> directories
+removed and <tt class="docutils literal"><span class="pre">..</span></tt> directories replaced by <tt class="docutils literal"><span class="pre">^</span></tt> characters. When used with
+the –long-file-names option, this applies to both the main file name and the
+included file name.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-u">
+<tt class="descname">-u</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--unconditional-branches</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-u" title="Permalink to this definition">¶</a></dt>
+<dd><p>Include unconditional branches in the output for the –branch-probabilities
+option.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-gcov-version">
+<tt class="descname">-version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-gcov-version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display the version of llvm-cov.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h3>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">llvm-cov gcov</strong> returns 1 if it cannot read input files. Otherwise,
+it exits with zero.</p>
+</div>
+</div>
+<div class="section" id="show-command">
+<span id="llvm-cov-show"></span><h2>SHOW COMMAND<a class="headerlink" href="#show-command" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="id3">
+<h3>SYNOPSIS<a class="headerlink" href="#id3" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">llvm-cov show</strong> [<em>options</em>] -instr-profile <em>PROFILE</em> <em>BIN</em> [<em>-object BIN,...</em>] [[<em>-object BIN</em>]] [<em>SOURCES</em>]</p>
+</div>
+<div class="section" id="id4">
+<h3>DESCRIPTION<a class="headerlink" href="#id4" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">llvm-cov show</strong> command shows line by line coverage of the
+binaries <em>BIN</em>,... using the profile data <em>PROFILE</em>. It can optionally be
+filtered to only show the coverage for the files listed in <em>SOURCES</em>.</p>
+<p>To use <strong class="program">llvm-cov show</strong>, you need a program that is compiled with
+instrumentation to emit profile and coverage data. To build such a program with
+<tt class="docutils literal"><span class="pre">clang</span></tt> use the <tt class="docutils literal"><span class="pre">-fprofile-instr-generate</span></tt> and <tt class="docutils literal"><span class="pre">-fcoverage-mapping</span></tt>
+flags. If linking with the <tt class="docutils literal"><span class="pre">clang</span></tt> driver, pass <tt class="docutils literal"><span class="pre">-fprofile-instr-generate</span></tt>
+to the link stage to make sure the necessary runtime libraries are linked in.</p>
+<p>The coverage information is stored in the built executable or library itself,
+and this is what you should pass to <strong class="program">llvm-cov show</strong> as a <em>BIN</em>
+argument. The profile data is generated by running this instrumented program
+normally. When the program exits it will write out a raw profile file,
+typically called <tt class="docutils literal"><span class="pre">default.profraw</span></tt>, which can be converted to a format that
+is suitable for the <em>PROFILE</em> argument using the <strong class="program">llvm-profdata merge</strong>
+tool.</p>
+</div>
+<div class="section" id="id5">
+<h3>OPTIONS<a class="headerlink" href="#id5" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-show-line-counts">
+<tt class="descname">-show-line-counts</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-show-line-counts" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the execution counts for each line. Defaults to true, unless another
+<tt class="docutils literal"><span class="pre">-show</span></tt> option is used.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-show-expansions">
+<tt class="descname">-show-expansions</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-show-expansions" title="Permalink to this definition">¶</a></dt>
+<dd><p>Expand inclusions, such as preprocessor macros or textual inclusions, inline
+in the display of the source file. Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-show-instantiations">
+<tt class="descname">-show-instantiations</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-show-instantiations" title="Permalink to this definition">¶</a></dt>
+<dd><p>For source regions that are instantiated multiple times, such as templates in
+<tt class="docutils literal"><span class="pre">C++</span></tt>, show each instantiation separately as well as the combined summary.
+Defaults to true.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-show-regions">
+<tt class="descname">-show-regions</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-show-regions" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the execution counts for each region by displaying a caret that points to
+the character where the region starts. Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-show-line-counts-or-regions">
+<tt class="descname">-show-line-counts-or-regions</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-show-line-counts-or-regions" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the execution counts for each line if there is only one region on the
+line, but show the individual regions if there are multiple on the line.
+Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-use-color">
+<tt class="descname">-use-color</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-use-color" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable or disable color output. By default this is autodetected.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-arch">
+<tt class="descname">-arch</tt><tt class="descclassname">=[*NAMES*]</tt><a class="headerlink" href="#cmdoption-llvm-cov-show-arch" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a list of architectures such that the Nth entry in the list
+corresponds to the Nth specified binary. If the covered object is a universal
+binary, this specifies the architecture to use. It is an error to specify an
+architecture that is not included in the universal binary or to use an
+architecture that does not match a non-universal binary.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-name">
+<tt class="descname">-name</tt><tt class="descclassname">=<NAME></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-name" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions with the given name.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-name-whitelist">
+<tt class="descname">-name-whitelist</tt><tt class="descclassname">=<FILE></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-name-whitelist" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions listed in the given file. Each line in
+the file should start with <cite>whitelist_fun:</cite>, immediately followed by the name
+of the function to accept. This name can be a wildcard expression.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-name-regex">
+<tt class="descname">-name-regex</tt><tt class="descclassname">=<PATTERN></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-name-regex" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions that match the given regular expression.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-ignore-filename-regex">
+<tt class="descname">-ignore-filename-regex</tt><tt class="descclassname">=<PATTERN></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-ignore-filename-regex" title="Permalink to this definition">¶</a></dt>
+<dd><p>Skip source code files with file paths that match the given regular expression.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-format">
+<tt class="descname">-format</tt><tt class="descclassname">=<FORMAT></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-format" title="Permalink to this definition">¶</a></dt>
+<dd><p>Use the specified output format. The supported formats are: “text”, “html”.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-tab-size">
+<tt class="descname">-tab-size</tt><tt class="descclassname">=<TABSIZE></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-tab-size" title="Permalink to this definition">¶</a></dt>
+<dd><p>Replace tabs with <TABSIZE> spaces when preparing reports. Currently, this is
+only supported for the html format.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-output-dir">
+<tt class="descname">-output-dir</tt><tt class="descclassname">=PATH</tt><a class="headerlink" href="#cmdoption-llvm-cov-show-output-dir" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a directory to write coverage reports into. If the directory does not
+exist, it is created. When used in function view mode (i.e when -name or
+-name-regex are used to select specific functions), the report is written to
+PATH/functions.EXTENSION. When used in file view mode, a report for each file
+is written to PATH/REL_PATH_TO_FILE.EXTENSION.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-Xdemangler">
+<tt class="descname">-Xdemangler</tt><tt class="descclassname">=<TOOL>|<TOOL-OPTION></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-Xdemangler" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a symbol demangler. This can be used to make reports more
+human-readable. This option can be specified multiple times to supply
+arguments to the demangler (e.g <cite>-Xdemangler c++filt -Xdemangler -n</cite> for C++).
+The demangler is expected to read a newline-separated list of symbols from
+stdin and write a newline-separated list of the same length to stdout.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-num-threads">
+<tt class="descname">-num-threads</tt><tt class="descclassname">=N</tt><tt class="descclassname">, </tt><tt class="descname">-j</tt><tt class="descclassname">=N</tt><a class="headerlink" href="#cmdoption-llvm-cov-show-num-threads" title="Permalink to this definition">¶</a></dt>
+<dd><p>Use N threads to write file reports (only applicable when -output-dir is
+specified). When N=0, llvm-cov auto-detects an appropriate number of threads to
+use. This is the default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-line-coverage-gt">
+<tt class="descname">-line-coverage-gt</tt><tt class="descclassname">=<N></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-line-coverage-gt" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions with line coverage greater than the
+given threshold.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-line-coverage-lt">
+<tt class="descname">-line-coverage-lt</tt><tt class="descclassname">=<N></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-line-coverage-lt" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions with line coverage less than the given
+threshold.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-region-coverage-gt">
+<tt class="descname">-region-coverage-gt</tt><tt class="descclassname">=<N></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-region-coverage-gt" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions with region coverage greater than the
+given threshold.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-region-coverage-lt">
+<tt class="descname">-region-coverage-lt</tt><tt class="descclassname">=<N></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-region-coverage-lt" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show code coverage only for functions with region coverage less than the given
+threshold.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-show-path-equivalence">
+<tt class="descname">-path-equivalence</tt><tt class="descclassname">=<from>,<to></tt><a class="headerlink" href="#cmdoption-llvm-cov-show-path-equivalence" title="Permalink to this definition">¶</a></dt>
+<dd><p>Map the paths in the coverage data to local source file paths. This allows you
+to generate the coverage data on one machine, and then use llvm-cov on a
+different machine where you have the same files on a different path.</p>
+</dd></dl>
+
+</div>
+</div>
+<div class="section" id="report-command">
+<span id="llvm-cov-report"></span><h2>REPORT COMMAND<a class="headerlink" href="#report-command" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="id6">
+<h3>SYNOPSIS<a class="headerlink" href="#id6" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">llvm-cov report</strong> [<em>options</em>] -instr-profile <em>PROFILE</em> <em>BIN</em> [<em>-object BIN,...</em>] [[<em>-object BIN</em>]] [<em>SOURCES</em>]</p>
+</div>
+<div class="section" id="id7">
+<h3>DESCRIPTION<a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">llvm-cov report</strong> command displays a summary of the coverage of
+the binaries <em>BIN</em>,... using the profile data <em>PROFILE</em>. It can optionally be
+filtered to only show the coverage for the files listed in <em>SOURCES</em>.</p>
+<p>If no source files are provided, a summary line is printed for each file in the
+coverage data. If any files are provided, summaries can be shown for each
+function in the listed files if the <tt class="docutils literal"><span class="pre">-show-functions</span></tt> option is enabled.</p>
+<p>For information on compiling programs for coverage and generating profile data,
+see <a class="reference internal" href="#llvm-cov-show"><em>SHOW COMMAND</em></a>.</p>
+</div>
+<div class="section" id="id8">
+<h3>OPTIONS<a class="headerlink" href="#id8" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-llvm-cov-report-use-color">
+<tt class="descname">-use-color</tt><tt class="descclassname">[=VALUE]</tt><a class="headerlink" href="#cmdoption-llvm-cov-report-use-color" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable or disable color output. By default this is autodetected.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-report-arch">
+<tt class="descname">-arch</tt><tt class="descclassname">=<name></tt><a class="headerlink" href="#cmdoption-llvm-cov-report-arch" title="Permalink to this definition">¶</a></dt>
+<dd><p>If the covered binary is a universal binary, select the architecture to use.
+It is an error to specify an architecture that is not included in the
+universal binary or to use an architecture that does not match a
+non-universal binary.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-report-show-functions">
+<tt class="descname">-show-functions</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-report-show-functions" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show coverage summaries for each function. Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-report-show-instantiation-summary">
+<tt class="descname">-show-instantiation-summary</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-report-show-instantiation-summary" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show statistics for all function instantiations. Defaults to false.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-report-ignore-filename-regex">
+<tt class="descname">-ignore-filename-regex</tt><tt class="descclassname">=<PATTERN></tt><a class="headerlink" href="#cmdoption-llvm-cov-report-ignore-filename-regex" title="Permalink to this definition">¶</a></dt>
+<dd><p>Skip source code files with file paths that match the given regular expression.</p>
+</dd></dl>
+
+</div>
+</div>
+<div class="section" id="export-command">
+<span id="llvm-cov-export"></span><h2>EXPORT COMMAND<a class="headerlink" href="#export-command" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="id9">
+<h3>SYNOPSIS<a class="headerlink" href="#id9" title="Permalink to this headline">¶</a></h3>
+<p><strong class="program">llvm-cov export</strong> [<em>options</em>] -instr-profile <em>PROFILE</em> <em>BIN</em> [<em>-object BIN,...</em>] [[<em>-object BIN</em>]] [<em>SOURCES</em>]</p>
+</div>
+<div class="section" id="id10">
+<h3>DESCRIPTION<a class="headerlink" href="#id10" title="Permalink to this headline">¶</a></h3>
+<p>The <strong class="program">llvm-cov export</strong> command exports regions, functions, expansions,
+and summaries of the coverage of the binaries <em>BIN</em>,... using the profile data
+<em>PROFILE</em> as JSON. It can optionally be filtered to only export the coverage
+for the files listed in <em>SOURCES</em>.</p>
+<p>For information on compiling programs for coverage and generating profile data,
+see <a class="reference internal" href="#llvm-cov-show"><em>SHOW COMMAND</em></a>.</p>
+</div>
+<div class="section" id="id11">
+<h3>OPTIONS<a class="headerlink" href="#id11" title="Permalink to this headline">¶</a></h3>
+<dl class="option">
+<dt id="cmdoption-llvm-cov-export-arch">
+<tt class="descname">-arch</tt><tt class="descclassname">=<name></tt><a class="headerlink" href="#cmdoption-llvm-cov-export-arch" title="Permalink to this definition">¶</a></dt>
+<dd><p>If the covered binary is a universal binary, select the architecture to use.
+It is an error to specify an architecture that is not included in the
+universal binary or to use an architecture that does not match a
+non-universal binary.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-export-summary-only">
+<tt class="descname">-summary-only</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-cov-export-summary-only" title="Permalink to this definition">¶</a></dt>
+<dd><p>Export only summary information for each file in the coverage data. This mode
+will not export coverage information for smaller units such as individual
+functions or regions. The result will be the same as produced by :program:
+<cite>llvm-cov report</cite> command, but presented in JSON format rather than text.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-cov-export-ignore-filename-regex">
+<tt class="descname">-ignore-filename-regex</tt><tt class="descclassname">=<PATTERN></tt><a class="headerlink" href="#cmdoption-llvm-cov-export-ignore-filename-regex" title="Permalink to this definition">¶</a></dt>
+<dd><p>Skip source code files with file paths that match the given regular expression.</p>
+</dd></dl>
+
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-profdata.html" title="llvm-profdata - Profile data tool"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-diff.html" title="llvm-diff - LLVM structural âdiffâ"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-diff.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-diff.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-diff.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-diff.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,139 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-diff - LLVM structural âdiffâ — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-cov - emit coverage information" href="llvm-cov.html" />
+ <link rel="prev" title="llvm-config - Print LLVM compilation options" href="llvm-config.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-cov.html" title="llvm-cov - emit coverage information"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-config.html" title="llvm-config - Print LLVM compilation options"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-diff-llvm-structural-diff">
+<h1>llvm-diff - LLVM structural ‘diff’<a class="headerlink" href="#llvm-diff-llvm-structural-diff" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-diff</strong> [<em>options</em>] <em>module 1</em> <em>module 2</em> [<em>global name ...</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-diff</strong> compares the structure of two LLVM modules, primarily
+focusing on differences in function definitions. Insignificant
+differences, such as changes in the ordering of globals or in the
+names of local values, are ignored.</p>
+<p>An input module will be interpreted as an assembly file if its name
+ends in ‘.ll’; otherwise it will be read in as a bitcode file.</p>
+<p>If a list of global names is given, just the values with those names
+are compared; otherwise, all global values are compared, and
+diagnostics are produced for globals which only appear in one module
+or the other.</p>
+<p><strong>llvm-diff</strong> compares two functions by comparing their basic blocks,
+beginning with the entry blocks. If the terminators seem to match,
+then the corresponding successors are compared; otherwise they are
+ignored. This algorithm is very sensitive to changes in control flow,
+which tend to stop any downstream changes from being detected.</p>
+<p><strong>llvm-diff</strong> is intended as a debugging tool for writers of LLVM
+passes and frontends. It does not have a stable output format.</p>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-diff</strong> finds no differences between the modules, it will exit
+with 0 and produce no output. Otherwise it will exit with a non-zero
+value.</p>
+</div>
+<div class="section" id="bugs">
+<h2>BUGS<a class="headerlink" href="#bugs" title="Permalink to this headline">¶</a></h2>
+<p>Many important differences, like changes in linkage or function
+attributes, are not diagnosed.</p>
+<p>Changes in memory behavior (for example, coalescing loads) can cause
+massive detected differences in blocks.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-cov.html" title="llvm-cov - emit coverage information"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-config.html" title="llvm-config - Print LLVM compilation options"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dis.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dis.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dis.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,143 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-dis - LLVM disassembler — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="opt - LLVM optimizer" href="opt.html" />
+ <link rel="prev" title="llvm-as - LLVM assembler" href="llvm-as.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="opt.html" title="opt - LLVM optimizer"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-dis-llvm-disassembler">
+<h1>llvm-dis - LLVM disassembler<a class="headerlink" href="#llvm-dis-llvm-disassembler" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-dis</strong> [<em>options</em>] [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-dis</strong> command is the LLVM disassembler. It takes an LLVM
+bitcode file and converts it into human-readable LLVM assembly language.</p>
+<p>If filename is omitted or specified as <tt class="docutils literal"><span class="pre">-</span></tt>, <strong>llvm-dis</strong> reads its
+input from standard input.</p>
+<p>If the input is being read from standard input, then <strong>llvm-dis</strong>
+will send its output to standard output by default. Otherwise, the
+output will be written to a file named after the input file, with
+a <tt class="docutils literal"><span class="pre">.ll</span></tt> suffix added (any existing <tt class="docutils literal"><span class="pre">.bc</span></tt> suffix will first be
+removed). You can override the choice of output file using the
+<strong>-o</strong> option.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-f</strong></p>
+<blockquote>
+<div>Enable binary output on terminals. Normally, <strong>llvm-dis</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-dis</strong> will write raw bitcode regardless of the output device.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of command line options.</div></blockquote>
+<p><strong>-o</strong> <em>filename</em></p>
+<blockquote>
+<div>Specify the output file name. If <em>filename</em> is -, then the output is sent
+to standard output.</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong>llvm-dis</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>llvm-as|llvm-as</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="opt.html" title="opt - LLVM optimizer"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-as.html" title="llvm-as - LLVM assembler"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dwarfdump.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dwarfdump.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dwarfdump.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-dwarfdump.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,278 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-dwarfdump - dump and verify DWARF debug information — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="dsymutil - manipulate archived DWARF debug symbol files" href="dsymutil.html" />
+ <link rel="prev" title="llvm-symbolizer - convert addresses into source code locations" href="llvm-symbolizer.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="dsymutil.html" title="dsymutil - manipulate archived DWARF debug symbol files"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-symbolizer.html" title="llvm-symbolizer - convert addresses into source code locations"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-dwarfdump-dump-and-verify-dwarf-debug-information">
+<h1>llvm-dwarfdump - dump and verify DWARF debug information<a class="headerlink" href="#llvm-dwarfdump-dump-and-verify-dwarf-debug-information" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-dwarfdump</strong> [<em>options</em>] [<em>filename ...</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-dwarfdump</strong> parses DWARF sections in object files,
+archives, and <cite>.dSYM</cite> bundles and prints their contents in
+human-readable form. Only the .debug_info section is printed unless one of
+the section-specific options or <em class="xref std std-option">--all</em> is specified.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-a">
+<tt class="descname">-a</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--all</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-a" title="Permalink to this definition">¶</a></dt>
+<dd><p>Disassemble all supported DWARF sections.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--arch">
+<tt class="descname">--arch</tt><tt class="descclassname">=<arch></tt><a class="headerlink" href="#cmdoption--arch" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dump DWARF debug information for the specified CPU architecture.
+Architectures may be specified by name or by number. This
+option can be specified multiple times, once for each desired
+architecture. All CPU architectures will be printed by
+default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-c">
+<tt class="descname">-c</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--show-children</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-c" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show a debug info entry’s children when using
+the <em class="xref std std-option">--debug-info</em>, <em class="xref std std-option">--find</em>,
+and <em class="xref std std-option">--name</em> options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-f">
+<tt class="descname">-f</tt><tt class="descclassname"> <name></tt><tt class="descclassname">, </tt><tt class="descname">--find</tt><tt class="descclassname">=<name></tt><a class="headerlink" href="#cmdoption-f" title="Permalink to this definition">¶</a></dt>
+<dd><p>Search for the exact text <name> in the accelerator tables
+and print the matching debug information entries.
+When there is no accelerator tables or the name of the DIE
+you are looking for is not found in the accelerator tables,
+try using the slower but more complete <em class="xref std std-option">--name</em> option.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-F">
+<tt class="descname">-F</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--show-form</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-F" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show DWARF form types after the DWARF attribute types.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-h">
+<tt class="descname">-h</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-h" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show help and usage for this command.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-i">
+<tt class="descname">-i</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--ignore-case</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-i" title="Permalink to this definition">¶</a></dt>
+<dd><p>Ignore case distinctions in when searching entries by name
+or by regular expression.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-n">
+<tt class="descname">-n</tt><tt class="descclassname"> <pattern></tt><tt class="descclassname">, </tt><tt class="descname">--name</tt><tt class="descclassname">=<pattern></tt><a class="headerlink" href="#cmdoption-n" title="Permalink to this definition">¶</a></dt>
+<dd><p>Find and print all debug info entries whose name
+(<cite>DW_AT_name</cite> attribute) matches the exact text in
+<pattern>. Use the <em class="xref std std-option">--regex</em> option to have
+<pattern> become a regular expression for more flexible
+pattern matching.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--lookup">
+<tt class="descname">--lookup</tt><tt class="descclassname">=<address></tt><a class="headerlink" href="#cmdoption--lookup" title="Permalink to this definition">¶</a></dt>
+<dd><p>Lookup <address> in the debug information and print out the file,
+function, block, and line table details.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-o">
+<tt class="descname">-o</tt><tt class="descclassname"> <path></tt><tt class="descclassname">, </tt><tt class="descname">--out-file</tt><tt class="descclassname">=<path></tt><a class="headerlink" href="#cmdoption-o" title="Permalink to this definition">¶</a></dt>
+<dd><p>Redirect output to a file specified by <path>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-p">
+<tt class="descname">-p</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--show-parents</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-p" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show a debug info entry’s parent objects when using the
+<em class="xref std std-option">--debug-info</em>, <em class="xref std std-option">--find</em>, and
+<em class="xref std std-option">--name</em> options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-r">
+<tt class="descname">-r</tt><tt class="descclassname"> <n></tt><tt class="descclassname">, </tt><tt class="descname">--recurse-depth</tt><tt class="descclassname">=<n></tt><a class="headerlink" href="#cmdoption-r" title="Permalink to this definition">¶</a></dt>
+<dd><p>Only recurse to a maximum depth of <n> when dumping debug info
+entries.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--statistics">
+<tt class="descname">--statistics</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--statistics" title="Permalink to this definition">¶</a></dt>
+<dd><p>Collect debug info quality metrics and print the results
+as machine-readable single-line JSON output.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-x">
+<tt class="descname">-x</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--regex</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-x" title="Permalink to this definition">¶</a></dt>
+<dd><p>Treat any <pattern> strings as regular expressions when searching
+instead of just as an exact string match.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-u">
+<tt class="descname">-u</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--uuid</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-u" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show the UUID for each architecture.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--diff">
+<tt class="descname">--diff</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--diff" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dump the output in a format that is more friendly for comparing
+DWARF output from two different files.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--verbose</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display verbose information when dumping. This can help to debug
+DWARF issues.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--verify">
+<tt class="descname">--verify</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--verify" title="Permalink to this definition">¶</a></dt>
+<dd><p>Verify the structure of the DWARF information by verifying the
+compile unit chains, DIE relationships graph, address
+ranges, and more.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--version">
+<tt class="descname">--version</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--version" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display the version of the tool.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption--debug-abbrev">
+<tt class="descname">--debug-abbrev</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-aranges</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-cu-index</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-frame</tt><tt class="descclassname"> [=<offset>]</tt><tt class="descclassname">, </tt><tt class="descname">--debug-gnu-pubnames</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-gnu-pubtypes</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-info</tt><tt class="descclassname"> [=<offset>]</tt><tt class="descclassname">, </tt><tt class="descname">--debug-line</tt><tt class="descclassname"> [=<offset>]</tt><tt class="descclassname">, </tt><tt class="descname">--debug-loc</tt><tt class="descclassname"> [=<offset>]</tt><tt class="descclassname">, </tt><tt class="descname">--debug-macro</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-pubnames</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-pubtypes</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-ranges</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-str</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-str-offsets</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-tu-index</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--debug-types</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--eh-frame</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--gdb-index</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--apple-names</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--apple-types</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--apple-namespaces</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">--apple-objc</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption--debug-abbrev" title="Permalink to this definition">¶</a></dt>
+<dd><p>Dump the specified DWARF section by name. Only the
+<cite>.debug_info</cite> section is shown by default. Some entries
+support adding an <cite>=<offset></cite> as a way to provide an
+optional offset of the exact entry to dump within the
+respective section. When an offset is provided, only the
+entry at that offset will be dumped, else the entire
+section will be dumped. Children of items at a specific
+offset can be dumped by also using the
+<em class="xref std std-option">--show-children</em> option where applicable.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-dwarfdump</strong> returns 0 if the input files were parsed and dumped
+successfully. Otherwise, it returns 1.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p><em class="manpage">dsymutil(1)</em></p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="dsymutil.html" title="dsymutil - manipulate archived DWARF debug symbol files"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-symbolizer.html" title="llvm-symbolizer - convert addresses into source code locations"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-exegesis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-exegesis.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-exegesis.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-exegesis.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,284 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-exegesis - LLVM Machine Instruction Benchmark — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-pdbutil - PDB File forensics and diagnostics" href="llvm-pdbutil.html" />
+ <link rel="prev" title="llvm-build - LLVM Project Build Utility" href="llvm-build.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-pdbutil.html" title="llvm-pdbutil - PDB File forensics and diagnostics"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-exegesis-llvm-machine-instruction-benchmark">
+<h1>llvm-exegesis - LLVM Machine Instruction Benchmark<a class="headerlink" href="#llvm-exegesis-llvm-machine-instruction-benchmark" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-exegesis</strong> [<em>options</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-exegesis</strong> is a benchmarking tool that uses information available
+in LLVM to measure host machine instruction characteristics like latency or port
+decomposition.</p>
+<p>Given an LLVM opcode name and a benchmarking mode, <strong class="program">llvm-exegesis</strong>
+generates a code snippet that makes execution as serial (resp. as parallel) as
+possible so that we can measure the latency (resp. uop decomposition) of the
+instruction.
+The code snippet is jitted and executed on the host subtarget. The time taken
+(resp. resource usage) is measured using hardware performance counters. The
+result is printed out as YAML to the standard output.</p>
+<p>The main goal of this tool is to automatically (in)validate the LLVM’s TableDef
+scheduling models. To that end, we also provide analysis of the results.</p>
+</div>
+<div class="section" id="examples-benchmarking">
+<h2>EXAMPLES: benchmarking<a class="headerlink" href="#examples-benchmarking" title="Permalink to this headline">¶</a></h2>
+<p>Assume you have an X86-64 machine. To measure the latency of a single
+instruction, run:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llvm-exegesis -mode<span class="o">=</span>latency -opcode-name<span class="o">=</span>ADD64rr
+</pre></div>
+</div>
+<p>Measuring the uop decomposition of an instruction works similarly:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llvm-exegesis -mode<span class="o">=</span>uops -opcode-name<span class="o">=</span>ADD64rr
+</pre></div>
+</div>
+<p>The output is a YAML document (the default is to write to stdout, but you can
+redirect the output to a file using <cite>-benchmarks-file</cite>):</p>
+<div class="highlight-none"><div class="highlight"><pre>---
+key:
+ opcode_name: ADD64rr
+ mode: latency
+ config: ''
+cpu_name: haswell
+llvm_triple: x86_64-unknown-linux-gnu
+num_repetitions: 10000
+measurements:
+ - { key: latency, value: 1.0058, debug_string: '' }
+error: ''
+info: 'explicit self cycles, selecting one aliasing configuration.
+Snippet:
+ADD64rr R8, R8, R10
+'
+...
+</pre></div>
+</div>
+<p>To measure the latency of all instructions for the host architecture, run:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="c">#!/bin/bash</span>
+<span class="nb">readonly </span><span class="nv">INSTRUCTIONS</span><span class="o">=</span><span class="k">$(($(</span>grep INSTRUCTION_LIST_END build/lib/Target/X86/X86GenInstrInfo.inc | cut -f2 -d<span class="o">=</span><span class="k">)</span> <span class="o">-</span> <span class="m">1</span><span class="k">))</span>
+<span class="k">for </span>INSTRUCTION in <span class="k">$(</span>seq 1 <span class="k">${</span><span class="nv">INSTRUCTIONS</span><span class="k">})</span>;
+<span class="k">do</span>
+ ./build/bin/llvm-exegesis -mode<span class="o">=</span>latency -opcode-index<span class="o">=</span><span class="k">${</span><span class="nv">INSTRUCTION</span><span class="k">}</span> | sed -n <span class="s1">'/---/,$p'</span>
+<span class="k">done</span>
+</pre></div>
+</div>
+<p>FIXME: Provide an <strong class="program">llvm-exegesis</strong> option to test all instructions.</p>
+</div>
+<div class="section" id="examples-analysis">
+<h2>EXAMPLES: analysis<a class="headerlink" href="#examples-analysis" title="Permalink to this headline">¶</a></h2>
+<p>Assuming you have a set of benchmarked instructions (either latency or uops) as
+YAML in file <cite>/tmp/benchmarks.yaml</cite>, you can analyze the results using the
+following command:</p>
+<div class="highlight-bash"><div class="highlight"><pre> <span class="nv">$ </span>llvm-exegesis -mode<span class="o">=</span>analysis <span class="se">\</span>
+-benchmarks-file<span class="o">=</span>/tmp/benchmarks.yaml <span class="se">\</span>
+-analysis-clusters-output-file<span class="o">=</span>/tmp/clusters.csv <span class="se">\</span>
+-analysis-inconsistencies-output-file<span class="o">=</span>/tmp/inconsistencies.txt
+</pre></div>
+</div>
+<p>This will group the instructions into clusters with the same performance
+characteristics. The clusters will be written out to <cite>/tmp/clusters.csv</cite> in the
+following format:</p>
+<div class="highlight-none"><div class="highlight"><pre>cluster_id,opcode_name,config,sched_class
+...
+2,ADD32ri8_DB,,WriteALU,1.00
+2,ADD32ri_DB,,WriteALU,1.01
+2,ADD32rr,,WriteALU,1.01
+2,ADD32rr_DB,,WriteALU,1.00
+2,ADD32rr_REV,,WriteALU,1.00
+2,ADD64i32,,WriteALU,1.01
+2,ADD64ri32,,WriteALU,1.01
+2,MOVSX64rr32,,BSWAP32r_BSWAP64r_MOVSX64rr32,1.00
+2,VPADDQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.02
+2,VPSUBQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.01
+2,ADD64ri8,,WriteALU,1.00
+2,SETBr,,WriteSETCC,1.01
+...
+</pre></div>
+</div>
+<p><strong class="program">llvm-exegesis</strong> will also analyze the clusters to point out
+inconsistencies in the scheduling information. The output is an html file. For
+example, <cite>/tmp/inconsistencies.html</cite> will contain messages like the following :</p>
+<img alt="../_images/llvm-exegesis-analysis.png" class="align-center" src="../_images/llvm-exegesis-analysis.png" />
+<p>Note that the scheduling class names will be resolved only when
+<strong class="program">llvm-exegesis</strong> is compiled in debug mode, else only the class id will
+be shown. This does not invalidate any of the analysis results though.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-opcode-index">
+<tt class="descname">-opcode-index</tt><tt class="descclassname">=<LLVM opcode index></tt><a class="headerlink" href="#cmdoption-opcode-index" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the opcode to measure, by index.
+Either <cite>opcode-index</cite> or <cite>opcode-name</cite> must be set.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-opcode-name">
+<tt class="descname">-opcode-name</tt><tt class="descclassname">=<LLVM opcode name></tt><a class="headerlink" href="#cmdoption-opcode-name" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the opcode to measure, by name.
+Either <cite>opcode-index</cite> or <cite>opcode-name</cite> must be set.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mode">
+<tt class="descname">-mode</tt><tt class="descclassname">=[latency|uops|analysis]</tt><a class="headerlink" href="#cmdoption-mode" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the run mode.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-num-repetitions">
+<tt class="descname">-num-repetitions</tt><tt class="descclassname">=<Number of repetition></tt><a class="headerlink" href="#cmdoption-num-repetitions" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the number of repetitions of the asm snippet.
+Higher values lead to more accurate measurements but lengthen the benchmark.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-benchmarks-file">
+<tt class="descname">-benchmarks-file</tt><tt class="descclassname">=</path/to/file></tt><a class="headerlink" href="#cmdoption-benchmarks-file" title="Permalink to this definition">¶</a></dt>
+<dd><p>File to read (<cite>analysis</cite> mode) or write (<cite>latency</cite>/<cite>uops</cite> modes) benchmark
+results. “-” uses stdin/stdout.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-analysis-clusters-output-file">
+<tt class="descname">-analysis-clusters-output-file</tt><tt class="descclassname">=</path/to/file></tt><a class="headerlink" href="#cmdoption-analysis-clusters-output-file" title="Permalink to this definition">¶</a></dt>
+<dd><p>If provided, write the analysis clusters as CSV to this file. “-” prints to
+stdout.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-analysis-inconsistencies-output-file">
+<tt class="descname">-analysis-inconsistencies-output-file</tt><tt class="descclassname">=</path/to/file></tt><a class="headerlink" href="#cmdoption-analysis-inconsistencies-output-file" title="Permalink to this definition">¶</a></dt>
+<dd><p>If non-empty, write inconsistencies found during analysis to this file. <cite>-</cite>
+prints to stdout.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-analysis-numpoints">
+<tt class="descname">-analysis-numpoints</tt><tt class="descclassname">=<dbscan numPoints parameter></tt><a class="headerlink" href="#cmdoption-analysis-numpoints" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the numPoints parameters to be used for DBSCAN clustering
+(<cite>analysis</cite> mode).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-analysis-espilon">
+<tt class="descname">-analysis-espilon</tt><tt class="descclassname">=<dbscan epsilon parameter></tt><a class="headerlink" href="#cmdoption-analysis-espilon" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the numPoints parameters to be used for DBSCAN clustering
+(<cite>analysis</cite> mode).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-ignore-invalid-sched-class">
+<tt class="descname">-ignore-invalid-sched-class</tt><tt class="descclassname">=false</tt><a class="headerlink" href="#cmdoption-ignore-invalid-sched-class" title="Permalink to this definition">¶</a></dt>
+<dd><p>If set, ignore instructions that do not have a sched class (class idx = 0).</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-exegesis</strong> returns 0 on success. Otherwise, an error message is
+printed to standard error, and the tool returns a non 0 value.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-pdbutil.html" title="llvm-pdbutil - PDB File forensics and diagnostics"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-build.html" title="llvm-build - LLVM Project Build Utility"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-extract.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-extract.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-extract.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-extract.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,164 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-extract - extract a function from an LLVM module — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-bcanalyzer - LLVM bitcode analyzer" href="llvm-bcanalyzer.html" />
+ <link rel="prev" title="bugpoint - automatic test case reduction tool" href="bugpoint.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="bugpoint.html" title="bugpoint - automatic test case reduction tool"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-extract-extract-a-function-from-an-llvm-module">
+<h1>llvm-extract - extract a function from an LLVM module<a class="headerlink" href="#llvm-extract-extract-a-function-from-an-llvm-module" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-extract</strong> [<em>options</em>] <strong>–func</strong> <em>function-name</em> [<em>filename</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llvm-extract</strong> command takes the name of a function and extracts
+it from the specified LLVM bitcode file. It is primarily used as a debugging
+tool to reduce test cases from larger programs that are triggering a bug.</p>
+<p>In addition to extracting the bitcode of the specified function,
+<strong class="program">llvm-extract</strong> will also remove unreachable global variables,
+prototypes, and unused types.</p>
+<p>The <strong class="program">llvm-extract</strong> command reads its input from standard input if
+filename is omitted or if filename is <tt class="docutils literal"><span class="pre">-</span></tt>. The output is always written to
+standard output, unless the <strong>-o</strong> option is specified (see below).</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p><strong>-f</strong></p>
+<blockquote>
+<div>Enable binary output on terminals. Normally, <strong class="program">llvm-extract</strong> will
+refuse to write raw bitcode output if the output stream is a terminal. With
+this option, <strong class="program">llvm-extract</strong> will write raw bitcode regardless of the
+output device.</div></blockquote>
+<p><strong>–func</strong> <em>function-name</em></p>
+<blockquote>
+<div>Extract the function named <em>function-name</em> from the LLVM bitcode. May be
+specified multiple times to extract multiple functions at once.</div></blockquote>
+<p><strong>–rfunc</strong> <em>function-regular-expr</em></p>
+<blockquote>
+<div>Extract the function(s) matching <em>function-regular-expr</em> from the LLVM bitcode.
+All functions matching the regular expression will be extracted. May be
+specified multiple times.</div></blockquote>
+<p><strong>–glob</strong> <em>global-name</em></p>
+<blockquote>
+<div>Extract the global variable named <em>global-name</em> from the LLVM bitcode. May be
+specified multiple times to extract multiple global variables at once.</div></blockquote>
+<p><strong>–rglob</strong> <em>glob-regular-expr</em></p>
+<blockquote>
+<div>Extract the global variable(s) matching <em>global-regular-expr</em> from the LLVM
+bitcode. All global variables matching the regular expression will be
+extracted. May be specified multiple times.</div></blockquote>
+<p><strong>-help</strong></p>
+<blockquote>
+<div>Print a summary of command line options.</div></blockquote>
+<p><strong>-o</strong> <em>filename</em></p>
+<blockquote>
+<div>Specify the output filename. If filename is “-” (the default), then
+<strong class="program">llvm-extract</strong> sends its output to standard output.</div></blockquote>
+<p><strong>-S</strong></p>
+<blockquote>
+<div>Write output in LLVM intermediate language (instead of bitcode).</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llvm-extract</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>bugpoint</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-bcanalyzer.html" title="llvm-bcanalyzer - LLVM bitcode analyzer"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="bugpoint.html" title="bugpoint - automatic test case reduction tool"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-lib.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-lib.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-lib.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-lib.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,124 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-lib - LLVM lib.exe compatible library tool — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-nm - list LLVM bitcode and object fileâs symbol table" href="llvm-nm.html" />
+ <link rel="prev" title="llvm-ar - LLVM archiver" href="llvm-ar.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object fileâs symbol table"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-ar.html" title="llvm-ar - LLVM archiver"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-lib-llvm-lib-exe-compatible-library-tool">
+<h1>llvm-lib - LLVM lib.exe compatible library tool<a class="headerlink" href="#llvm-lib-llvm-lib-exe-compatible-library-tool" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong>llvm-lib</strong> [/libpath:<path>] [/out:<output>] [/llvmlibthin]
+[/ignore] [/machine] [/nologo] [files...]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong>llvm-lib</strong> command is intended to be a <tt class="docutils literal"><span class="pre">lib.exe</span></tt> compatible
+tool. See <a class="reference external" href="https://msdn.microsoft.com/en-us/library/7ykb2k5f">https://msdn.microsoft.com/en-us/library/7ykb2k5f</a> for the
+general description.</p>
+<p><strong>llvm-lib</strong> has the following extensions:</p>
+<ul class="simple">
+<li>Bitcode files in symbol tables.
+<strong>llvm-lib</strong> includes symbols from both bitcode files and regular
+object files in the symbol table.</li>
+<li>Creating thin archives.
+The /llvmlibthin option causes <strong>llvm-lib</strong> to create thin archive
+that contain only the symbol table and the header for the various
+members. These files are much smaller, but are not compatible with
+link.exe (lld can handle them).</li>
+</ul>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-nm.html" title="llvm-nm - list LLVM bitcode and object fileâs symbol table"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-ar.html" title="llvm-ar - LLVM archiver"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-link.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-link.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-link.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-link.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,163 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-link - LLVM bitcode linker — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-ar - LLVM archiver" href="llvm-ar.html" />
+ <link rel="prev" title="lli - directly execute programs from LLVM bitcode" href="lli.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-ar.html" title="llvm-ar - LLVM archiver"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-link-llvm-bitcode-linker">
+<h1>llvm-link - LLVM bitcode linker<a class="headerlink" href="#llvm-link-llvm-bitcode-linker" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-link</strong> [<em>options</em>] <em>filename ...</em></p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-link</strong> takes several LLVM bitcode files and links them together
+into a single LLVM bitcode file. It writes the output file to standard output,
+unless the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is used to specify a filename.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-f">
+<tt class="descname">-f</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-f" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable binary output on terminals. Normally, <strong class="program">llvm-link</strong> will refuse
+to write raw bitcode output if the output stream is a terminal. With this
+option, <strong class="program">llvm-link</strong> will write raw bitcode regardless of the output
+device.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-o">
+<tt class="descname">-o</tt><tt class="descclassname"> filename</tt><a class="headerlink" href="#cmdoption-o" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the output file name. If <tt class="docutils literal"><span class="pre">filename</span></tt> is “<tt class="docutils literal"><span class="pre">-</span></tt>”, then
+<strong class="program">llvm-link</strong> will write its output to standard output.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-S">
+<tt class="descname">-S</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-S" title="Permalink to this definition">¶</a></dt>
+<dd><p>Write output in LLVM intermediate language (instead of bitcode).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-d">
+<tt class="descname">-d</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-d" title="Permalink to this definition">¶</a></dt>
+<dd><p>If specified, <strong class="program">llvm-link</strong> prints a human-readable version of the
+output bitcode file to standard error.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-v">
+<tt class="descname">-v</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-v" title="Permalink to this definition">¶</a></dt>
+<dd><p>Verbose mode. Print information about what <strong class="program">llvm-link</strong> is doing.
+This typically includes a message for each bitcode file linked in and for each
+library found.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p>If <strong class="program">llvm-link</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-ar.html" title="llvm-ar - LLVM archiver"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="lli.html" title="lli - directly execute programs from LLVM bitcode"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-mca.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-mca.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-mca.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-mca.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,821 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-mca - LLVM Machine Code Analyzer — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="bugpoint - automatic test case reduction tool" href="bugpoint.html" />
+ <link rel="prev" title="dsymutil - manipulate archived DWARF debug symbol files" href="dsymutil.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="bugpoint.html" title="bugpoint - automatic test case reduction tool"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="dsymutil.html" title="dsymutil - manipulate archived DWARF debug symbol files"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-mca-llvm-machine-code-analyzer">
+<h1>llvm-mca - LLVM Machine Code Analyzer<a class="headerlink" href="#llvm-mca-llvm-machine-code-analyzer" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-mca</strong> [<em>options</em>] [input]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-mca</strong> is a performance analysis tool that uses information
+available in LLVM (e.g. scheduling models) to statically measure the performance
+of machine code in a specific CPU.</p>
+<p>Performance is measured in terms of throughput as well as processor resource
+consumption. The tool currently works for processors with an out-of-order
+backend, for which there is a scheduling model available in LLVM.</p>
+<p>The main goal of this tool is not just to predict the performance of the code
+when run on the target, but also help with diagnosing potential performance
+issues.</p>
+<p>Given an assembly code sequence, llvm-mca estimates the Instructions Per Cycle
+(IPC), as well as hardware resource pressure. The analysis and reporting style
+were inspired by the IACA tool from Intel.</p>
+<p><strong class="program">llvm-mca</strong> allows the usage of special code comments to mark regions of
+the assembly code to be analyzed. A comment starting with substring
+<tt class="docutils literal"><span class="pre">LLVM-MCA-BEGIN</span></tt> marks the beginning of a code region. A comment starting with
+substring <tt class="docutils literal"><span class="pre">LLVM-MCA-END</span></tt> marks the end of a code region. For example:</p>
+<div class="highlight-none"><div class="highlight"><pre># LLVM-MCA-BEGIN My Code Region
+ ...
+# LLVM-MCA-END
+</pre></div>
+</div>
+<p>Multiple regions can be specified provided that they do not overlap. A code
+region can have an optional description. If no user-defined region is specified,
+then <strong class="program">llvm-mca</strong> assumes a default region which contains every
+instruction in the input file. Every region is analyzed in isolation, and the
+final performance report is the union of all the reports generated for every
+code region.</p>
+<p>Inline assembly directives may be used from source code to annotate the
+assembly text:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="n">a</span><span class="p">,</span> <span class="kt">int</span> <span class="n">b</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kr">__asm</span> <span class="k">volatile</span><span class="p">(</span><span class="s">"# LLVM-MCA-BEGIN foo"</span><span class="p">);</span>
+ <span class="n">a</span> <span class="o">+=</span> <span class="mi">42</span><span class="p">;</span>
+ <span class="kr">__asm</span> <span class="k">volatile</span><span class="p">(</span><span class="s">"# LLVM-MCA-END"</span><span class="p">);</span>
+ <span class="n">a</span> <span class="o">*=</span> <span class="n">b</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">a</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>So for example, you can compile code with clang, output assembly, and pipe it
+directly into llvm-mca for analysis:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>clang foo.c -O2 -target x86_64-unknown-unknown -S -o - | llvm-mca -mcpu<span class="o">=</span>btver2
+</pre></div>
+</div>
+<p>Or for Intel syntax:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>clang foo.c -O2 -target x86_64-unknown-unknown -mllvm -x86-asm-syntax<span class="o">=</span>intel -S -o - | llvm-mca -mcpu<span class="o">=</span>btver2
+</pre></div>
+</div>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<p>If <tt class="docutils literal"><span class="pre">input</span></tt> is “<tt class="docutils literal"><span class="pre">-</span></tt>” or omitted, <strong class="program">llvm-mca</strong> reads from standard
+input. Otherwise, it will read from the specified filename.</p>
+<p>If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a> option is omitted, then <strong class="program">llvm-mca</strong> will send its output
+to standard output if the input is from standard input. If the <a class="reference internal" href="opt.html#cmdoption-o"><em class="xref std std-option">-o</em></a>
+option specifies “<tt class="docutils literal"><span class="pre">-</span></tt>”, then the output will also be sent to standard output.</p>
+<dl class="option">
+<dt id="cmdoption-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command line options.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mtriple">
+<tt class="descname">-mtriple</tt><tt class="descclassname">=<target triple></tt><a class="headerlink" href="#cmdoption-mtriple" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a target triple string.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-march">
+<tt class="descname">-march</tt><tt class="descclassname">=<arch></tt><a class="headerlink" href="#cmdoption-march" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the architecture for which to analyze the code. It defaults to the
+host default target.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-mcpu">
+<tt class="descname">-mcpu</tt><tt class="descclassname">=<cpuname></tt><a class="headerlink" href="#cmdoption-mcpu" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the processor for which to analyze the code. By default, the cpu name
+is autodetected from the host.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-output-asm-variant">
+<tt class="descname">-output-asm-variant</tt><tt class="descclassname">=<variant id></tt><a class="headerlink" href="#cmdoption-output-asm-variant" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the output assembly variant for the report generated by the tool.
+On x86, possible values are [0, 1]. A value of 0 (vic. 1) for this flag enables
+the AT&T (vic. Intel) assembly format for the code printed out by the tool in
+the analysis report.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-dispatch">
+<tt class="descname">-dispatch</tt><tt class="descclassname">=<width></tt><a class="headerlink" href="#cmdoption-dispatch" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify a different dispatch width for the processor. The dispatch width
+defaults to field ‘IssueWidth’ in the processor scheduling model. If width is
+zero, then the default dispatch width is used.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-register-file-size">
+<tt class="descname">-register-file-size</tt><tt class="descclassname">=<size></tt><a class="headerlink" href="#cmdoption-register-file-size" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the size of the register file. When specified, this flag limits how
+many physical registers are available for register renaming purposes. A value
+of zero for this flag means “unlimited number of physical registers”.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-iterations">
+<tt class="descname">-iterations</tt><tt class="descclassname">=<number of iterations></tt><a class="headerlink" href="#cmdoption-iterations" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the number of iterations to run. If this flag is set to 0, then the
+tool sets the number of iterations to a default value (i.e. 100).</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-noalias">
+<tt class="descname">-noalias</tt><tt class="descclassname">=<bool></tt><a class="headerlink" href="#cmdoption-noalias" title="Permalink to this definition">¶</a></dt>
+<dd><p>If set, the tool assumes that loads and stores don’t alias. This is the
+default behavior.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-lqueue">
+<tt class="descname">-lqueue</tt><tt class="descclassname">=<load queue size></tt><a class="headerlink" href="#cmdoption-lqueue" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the size of the load queue in the load/store unit emulated by the tool.
+By default, the tool assumes an unbound number of entries in the load queue.
+A value of zero for this flag is ignored, and the default load queue size is
+used instead.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-squeue">
+<tt class="descname">-squeue</tt><tt class="descclassname">=<store queue size></tt><a class="headerlink" href="#cmdoption-squeue" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the size of the store queue in the load/store unit emulated by the
+tool. By default, the tool assumes an unbound number of entries in the store
+queue. A value of zero for this flag is ignored, and the default store queue
+size is used instead.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-timeline">
+<tt class="descname">-timeline</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-timeline" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable the timeline view.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-timeline-max-iterations">
+<tt class="descname">-timeline-max-iterations</tt><tt class="descclassname">=<iterations></tt><a class="headerlink" href="#cmdoption-timeline-max-iterations" title="Permalink to this definition">¶</a></dt>
+<dd><p>Limit the number of iterations to print in the timeline view. By default, the
+timeline view prints information for up to 10 iterations.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-timeline-max-cycles">
+<tt class="descname">-timeline-max-cycles</tt><tt class="descclassname">=<cycles></tt><a class="headerlink" href="#cmdoption-timeline-max-cycles" title="Permalink to this definition">¶</a></dt>
+<dd><p>Limit the number of cycles in the timeline view. By default, the number of
+cycles is set to 80.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-resource-pressure">
+<tt class="descname">-resource-pressure</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-resource-pressure" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable the resource pressure view. This is enabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-register-file-stats">
+<tt class="descname">-register-file-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-register-file-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable register file usage statistics.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-dispatch-stats">
+<tt class="descname">-dispatch-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-dispatch-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable extra dispatch statistics. This view collects and analyzes instruction
+dispatch events, as well as static/dynamic dispatch stall events. This view
+is disabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-scheduler-stats">
+<tt class="descname">-scheduler-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-scheduler-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable extra scheduler statistics. This view collects and analyzes instruction
+issue events. This view is disabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-retire-stats">
+<tt class="descname">-retire-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-retire-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable extra retire control unit statistics. This view is disabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-instruction-info">
+<tt class="descname">-instruction-info</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-instruction-info" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable the instruction info view. This is enabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-all-stats">
+<tt class="descname">-all-stats</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-all-stats" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print all hardware statistics. This enables extra statistics related to the
+dispatch logic, the hardware schedulers, the register file(s), and the retire
+control unit. This option is disabled by default.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-all-views">
+<tt class="descname">-all-views</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-all-views" title="Permalink to this definition">¶</a></dt>
+<dd><p>Enable all the view.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-instruction-tables">
+<tt class="descname">-instruction-tables</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-instruction-tables" title="Permalink to this definition">¶</a></dt>
+<dd><p>Prints resource pressure information based on the static information
+available from the processor model. This differs from the resource pressure
+view because it doesn’t require that the code is simulated. It instead prints
+the theoretical uniform distribution of resource pressure for every
+instruction in sequence.</p>
+</dd></dl>
+
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-mca</strong> returns 0 on success. Otherwise, an error message is printed
+to standard error, and the tool returns 1.</p>
+</div>
+<div class="section" id="how-llvm-mca-works">
+<h2>HOW LLVM-MCA WORKS<a class="headerlink" href="#how-llvm-mca-works" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-mca</strong> takes assembly code as input. The assembly code is parsed
+into a sequence of MCInst with the help of the existing LLVM target assembly
+parsers. The parsed sequence of MCInst is then analyzed by a <tt class="docutils literal"><span class="pre">Pipeline</span></tt> module
+to generate a performance report.</p>
+<p>The Pipeline module simulates the execution of the machine code sequence in a
+loop of iterations (default is 100). During this process, the pipeline collects
+a number of execution related statistics. At the end of this process, the
+pipeline generates and prints a report from the collected statistics.</p>
+<p>Here is an example of a performance report generated by the tool for a
+dot-product of two packed float vectors of four elements. The analysis is
+conducted for target x86, cpu btver2. The following result can be produced via
+the following command using the example located at
+<tt class="docutils literal"><span class="pre">test/tools/llvm-mca/X86/BtVer2/dot-product.s</span></tt>:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llvm-mca -mtriple<span class="o">=</span>x86_64-unknown-unknown -mcpu<span class="o">=</span>btver2 -iterations<span class="o">=</span>300 dot-product.s
+</pre></div>
+</div>
+<div class="highlight-none"><div class="highlight"><pre>Iterations: 300
+Instructions: 900
+Total Cycles: 610
+Dispatch Width: 2
+IPC: 1.48
+Block RThroughput: 2.0
+
+
+Instruction Info:
+[1]: #uOps
+[2]: Latency
+[3]: RThroughput
+[4]: MayLoad
+[5]: MayStore
+[6]: HasSideEffects (U)
+
+[1] [2] [3] [4] [5] [6] Instructions:
+ 1 2 1.00 vmulps %xmm0, %xmm1, %xmm2
+ 1 3 1.00 vhaddps %xmm2, %xmm2, %xmm3
+ 1 3 1.00 vhaddps %xmm3, %xmm3, %xmm4
+
+
+Resources:
+[0] - JALU0
+[1] - JALU1
+[2] - JDiv
+[3] - JFPA
+[4] - JFPM
+[5] - JFPU0
+[6] - JFPU1
+[7] - JLAGU
+[8] - JMul
+[9] - JSAGU
+[10] - JSTC
+[11] - JVALU0
+[12] - JVALU1
+[13] - JVIMUL
+
+
+Resource pressure per iteration:
+[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
+ - - - 2.00 1.00 2.00 1.00 - - - - - - -
+
+Resource pressure by instruction:
+[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Instructions:
+ - - - - 1.00 - 1.00 - - - - - - - vmulps %xmm0, %xmm1, %xmm2
+ - - - 1.00 - 1.00 - - - - - - - - vhaddps %xmm2, %xmm2, %xmm3
+ - - - 1.00 - 1.00 - - - - - - - - vhaddps %xmm3, %xmm3, %xmm4
+</pre></div>
+</div>
+<p>According to this report, the dot-product kernel has been executed 300 times,
+for a total of 900 dynamically executed instructions.</p>
+<p>The report is structured in three main sections. The first section collects a
+few performance numbers; the goal of this section is to give a very quick
+overview of the performance throughput. In this example, the two important
+performance indicators are <strong>IPC</strong> and <strong>Block RThroughput</strong> (Block Reciprocal
+Throughput).</p>
+<p>IPC is computed dividing the total number of simulated instructions by the total
+number of cycles. A delta between Dispatch Width and IPC is an indicator of a
+performance issue. In the absence of loop-carried data dependencies, the
+observed IPC tends to a theoretical maximum which can be computed by dividing
+the number of instructions of a single iteration by the <em>Block RThroughput</em>.</p>
+<p>IPC is bounded from above by the dispatch width. That is because the dispatch
+width limits the maximum size of a dispatch group. IPC is also limited by the
+amount of hardware parallelism. The availability of hardware resources affects
+the resource pressure distribution, and it limits the number of instructions
+that can be executed in parallel every cycle. A delta between Dispatch
+Width and the theoretical maximum IPC is an indicator of a performance
+bottleneck caused by the lack of hardware resources. In general, the lower the
+Block RThroughput, the better.</p>
+<p>In this example, <tt class="docutils literal"><span class="pre">Instructions</span> <span class="pre">per</span> <span class="pre">iteration/Block</span> <span class="pre">RThroughput</span></tt> is 1.50. Since
+there are no loop-carried dependencies, the observed IPC is expected to approach
+1.50 when the number of iterations tends to infinity. The delta between the
+Dispatch Width (2.00), and the theoretical maximum IPC (1.50) is an indicator of
+a performance bottleneck caused by the lack of hardware resources, and the
+<em>Resource pressure view</em> can help to identify the problematic resource usage.</p>
+<p>The second section of the report shows the latency and reciprocal
+throughput of every instruction in the sequence. That section also reports
+extra information related to the number of micro opcodes, and opcode properties
+(i.e., ‘MayLoad’, ‘MayStore’, and ‘HasSideEffects’).</p>
+<p>The third section is the <em>Resource pressure view</em>. This view reports
+the average number of resource cycles consumed every iteration by instructions
+for every processor resource unit available on the target. Information is
+structured in two tables. The first table reports the number of resource cycles
+spent on average every iteration. The second table correlates the resource
+cycles to the machine instruction in the sequence. For example, every iteration
+of the instruction vmulps always executes on resource unit [6]
+(JFPU1 - floating point pipeline #1), consuming an average of 1 resource cycle
+per iteration. Note that on AMD Jaguar, vector floating-point multiply can
+only be issued to pipeline JFPU1, while horizontal floating-point additions can
+only be issued to pipeline JFPU0.</p>
+<p>The resource pressure view helps with identifying bottlenecks caused by high
+usage of specific hardware resources. Situations with resource pressure mainly
+concentrated on a few resources should, in general, be avoided. Ideally,
+pressure should be uniformly distributed between multiple resources.</p>
+<div class="section" id="timeline-view">
+<h3>Timeline View<a class="headerlink" href="#timeline-view" title="Permalink to this headline">¶</a></h3>
+<p>The timeline view produces a detailed report of each instruction’s state
+transitions through an instruction pipeline. This view is enabled by the
+command line option <tt class="docutils literal"><span class="pre">-timeline</span></tt>. As instructions transition through the
+various stages of the pipeline, their states are depicted in the view report.
+These states are represented by the following characters:</p>
+<ul class="simple">
+<li>D : Instruction dispatched.</li>
+<li>e : Instruction executing.</li>
+<li>E : Instruction executed.</li>
+<li>R : Instruction retired.</li>
+<li>= : Instruction already dispatched, waiting to be executed.</li>
+<li>- : Instruction executed, waiting to be retired.</li>
+</ul>
+<p>Below is the timeline view for a subset of the dot-product example located in
+<tt class="docutils literal"><span class="pre">test/tools/llvm-mca/X86/BtVer2/dot-product.s</span></tt> and processed by
+<strong class="program">llvm-mca</strong> using the following command:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>llvm-mca -mtriple<span class="o">=</span>x86_64-unknown-unknown -mcpu<span class="o">=</span>btver2 -iterations<span class="o">=</span>3 -timeline dot-product.s
+</pre></div>
+</div>
+<div class="highlight-none"><div class="highlight"><pre>Timeline view:
+ 012345
+Index 0123456789
+
+[0,0] DeeER. . . vmulps %xmm0, %xmm1, %xmm2
+[0,1] D==eeeER . . vhaddps %xmm2, %xmm2, %xmm3
+[0,2] .D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
+[1,0] .DeeE-----R . vmulps %xmm0, %xmm1, %xmm2
+[1,1] . D=eeeE---R . vhaddps %xmm2, %xmm2, %xmm3
+[1,2] . D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
+[2,0] . DeeE-----R . vmulps %xmm0, %xmm1, %xmm2
+[2,1] . D====eeeER . vhaddps %xmm2, %xmm2, %xmm3
+[2,2] . D======eeeER vhaddps %xmm3, %xmm3, %xmm4
+
+
+Average Wait times (based on the timeline view):
+[0]: Executions
+[1]: Average time spent waiting in a scheduler's queue
+[2]: Average time spent waiting in a scheduler's queue while ready
+[3]: Average time elapsed from WB until retire stage
+
+ [0] [1] [2] [3]
+0. 3 1.0 1.0 3.3 vmulps %xmm0, %xmm1, %xmm2
+1. 3 3.3 0.7 1.0 vhaddps %xmm2, %xmm2, %xmm3
+2. 3 5.7 0.0 0.0 vhaddps %xmm3, %xmm3, %xmm4
+</pre></div>
+</div>
+<p>The timeline view is interesting because it shows instruction state changes
+during execution. It also gives an idea of how the tool processes instructions
+executed on the target, and how their timing information might be calculated.</p>
+<p>The timeline view is structured in two tables. The first table shows
+instructions changing state over time (measured in cycles); the second table
+(named <em>Average Wait times</em>) reports useful timing statistics, which should
+help diagnose performance bottlenecks caused by long data dependencies and
+sub-optimal usage of hardware resources.</p>
+<p>An instruction in the timeline view is identified by a pair of indices, where
+the first index identifies an iteration, and the second index is the
+instruction index (i.e., where it appears in the code sequence). Since this
+example was generated using 3 iterations: <tt class="docutils literal"><span class="pre">-iterations=3</span></tt>, the iteration
+indices range from 0-2 inclusively.</p>
+<p>Excluding the first and last column, the remaining columns are in cycles.
+Cycles are numbered sequentially starting from 0.</p>
+<p>From the example output above, we know the following:</p>
+<ul class="simple">
+<li>Instruction [1,0] was dispatched at cycle 1.</li>
+<li>Instruction [1,0] started executing at cycle 2.</li>
+<li>Instruction [1,0] reached the write back stage at cycle 4.</li>
+<li>Instruction [1,0] was retired at cycle 10.</li>
+</ul>
+<p>Instruction [1,0] (i.e., vmulps from iteration #1) does not have to wait in the
+scheduler’s queue for the operands to become available. By the time vmulps is
+dispatched, operands are already available, and pipeline JFPU1 is ready to
+serve another instruction. So the instruction can be immediately issued on the
+JFPU1 pipeline. That is demonstrated by the fact that the instruction only
+spent 1cy in the scheduler’s queue.</p>
+<p>There is a gap of 5 cycles between the write-back stage and the retire event.
+That is because instructions must retire in program order, so [1,0] has to wait
+for [0,2] to be retired first (i.e., it has to wait until cycle 10).</p>
+<p>In the example, all instructions are in a RAW (Read After Write) dependency
+chain. Register %xmm2 written by vmulps is immediately used by the first
+vhaddps, and register %xmm3 written by the first vhaddps is used by the second
+vhaddps. Long data dependencies negatively impact the ILP (Instruction Level
+Parallelism).</p>
+<p>In the dot-product example, there are anti-dependencies introduced by
+instructions from different iterations. However, those dependencies can be
+removed at register renaming stage (at the cost of allocating register aliases,
+and therefore consuming physical registers).</p>
+<p>Table <em>Average Wait times</em> helps diagnose performance issues that are caused by
+the presence of long latency instructions and potentially long data dependencies
+which may limit the ILP. Note that <strong class="program">llvm-mca</strong>, by default, assumes at
+least 1cy between the dispatch event and the issue event.</p>
+<p>When the performance is limited by data dependencies and/or long latency
+instructions, the number of cycles spent while in the <em>ready</em> state is expected
+to be very small when compared with the total number of cycles spent in the
+scheduler’s queue. The difference between the two counters is a good indicator
+of how large of an impact data dependencies had on the execution of the
+instructions. When performance is mostly limited by the lack of hardware
+resources, the delta between the two counters is small. However, the number of
+cycles spent in the queue tends to be larger (i.e., more than 1-3cy),
+especially when compared to other low latency instructions.</p>
+</div>
+<div class="section" id="extra-statistics-to-further-diagnose-performance-issues">
+<h3>Extra Statistics to Further Diagnose Performance Issues<a class="headerlink" href="#extra-statistics-to-further-diagnose-performance-issues" title="Permalink to this headline">¶</a></h3>
+<p>The <tt class="docutils literal"><span class="pre">-all-stats</span></tt> command line option enables extra statistics and performance
+counters for the dispatch logic, the reorder buffer, the retire control unit,
+and the register file.</p>
+<p>Below is an example of <tt class="docutils literal"><span class="pre">-all-stats</span></tt> output generated by MCA for the
+dot-product example discussed in the previous sections.</p>
+<div class="highlight-none"><div class="highlight"><pre>Dynamic Dispatch Stall Cycles:
+RAT - Register unavailable: 0
+RCU - Retire tokens unavailable: 0
+SCHEDQ - Scheduler full: 272
+LQ - Load queue full: 0
+SQ - Store queue full: 0
+GROUP - Static restrictions on the dispatch group: 0
+
+
+Dispatch Logic - number of cycles where we saw N instructions dispatched:
+[# dispatched], [# cycles]
+ 0, 24 (3.9%)
+ 1, 272 (44.6%)
+ 2, 314 (51.5%)
+
+
+Schedulers - number of cycles where we saw N instructions issued:
+[# issued], [# cycles]
+ 0, 7 (1.1%)
+ 1, 306 (50.2%)
+ 2, 297 (48.7%)
+
+
+Scheduler's queue usage:
+JALU01, 0/20
+JFPU01, 18/18
+JLSAGU, 0/12
+
+
+Retire Control Unit - number of cycles where we saw N instructions retired:
+[# retired], [# cycles]
+ 0, 109 (17.9%)
+ 1, 102 (16.7%)
+ 2, 399 (65.4%)
+
+
+Register File statistics:
+Total number of mappings created: 900
+Max number of mappings used: 35
+
+* Register File #1 -- JFpuPRF:
+ Number of physical registers: 72
+ Total number of mappings created: 900
+ Max number of mappings used: 35
+
+* Register File #2 -- JIntegerPRF:
+ Number of physical registers: 64
+ Total number of mappings created: 0
+ Max number of mappings used: 0
+</pre></div>
+</div>
+<p>If we look at the <em>Dynamic Dispatch Stall Cycles</em> table, we see the counter for
+SCHEDQ reports 272 cycles. This counter is incremented every time the dispatch
+logic is unable to dispatch a group of two instructions because the scheduler’s
+queue is full.</p>
+<p>Looking at the <em>Dispatch Logic</em> table, we see that the pipeline was only able
+to dispatch two instructions 51.5% of the time. The dispatch group was limited
+to one instruction 44.6% of the cycles, which corresponds to 272 cycles. The
+dispatch statistics are displayed by either using the command option
+<tt class="docutils literal"><span class="pre">-all-stats</span></tt> or <tt class="docutils literal"><span class="pre">-dispatch-stats</span></tt>.</p>
+<p>The next table, <em>Schedulers</em>, presents a histogram displaying a count,
+representing the number of instructions issued on some number of cycles. In
+this case, of the 610 simulated cycles, single
+instructions were issued 306 times (50.2%) and there were 7 cycles where
+no instructions were issued.</p>
+<p>The <em>Scheduler’s queue usage</em> table shows that the maximum number of buffer
+entries (i.e., scheduler queue entries) used at runtime. Resource JFPU01
+reached its maximum (18 of 18 queue entries). Note that AMD Jaguar implements
+three schedulers:</p>
+<ul class="simple">
+<li>JALU01 - A scheduler for ALU instructions.</li>
+<li>JFPU01 - A scheduler floating point operations.</li>
+<li>JLSAGU - A scheduler for address generation.</li>
+</ul>
+<p>The dot-product is a kernel of three floating point instructions (a vector
+multiply followed by two horizontal adds). That explains why only the floating
+point scheduler appears to be used.</p>
+<p>A full scheduler queue is either caused by data dependency chains or by a
+sub-optimal usage of hardware resources. Sometimes, resource pressure can be
+mitigated by rewriting the kernel using different instructions that consume
+different scheduler resources. Schedulers with a small queue are less resilient
+to bottlenecks caused by the presence of long data dependencies.
+The scheduler statistics are displayed by
+using the command option <tt class="docutils literal"><span class="pre">-all-stats</span></tt> or <tt class="docutils literal"><span class="pre">-scheduler-stats</span></tt>.</p>
+<p>The next table, <em>Retire Control Unit</em>, presents a histogram displaying a count,
+representing the number of instructions retired on some number of cycles. In
+this case, of the 610 simulated cycles, two instructions were retired during
+the same cycle 399 times (65.4%) and there were 109 cycles where no
+instructions were retired. The retire statistics are displayed by using the
+command option <tt class="docutils literal"><span class="pre">-all-stats</span></tt> or <tt class="docutils literal"><span class="pre">-retire-stats</span></tt>.</p>
+<p>The last table presented is <em>Register File statistics</em>. Each physical register
+file (PRF) used by the pipeline is presented in this table. In the case of AMD
+Jaguar, there are two register files, one for floating-point registers
+(JFpuPRF) and one for integer registers (JIntegerPRF). The table shows that of
+the 900 instructions processed, there were 900 mappings created. Since this
+dot-product example utilized only floating point registers, the JFPuPRF was
+responsible for creating the 900 mappings. However, we see that the pipeline
+only used a maximum of 35 of 72 available register slots at any given time. We
+can conclude that the floating point PRF was the only register file used for
+the example, and that it was never resource constrained. The register file
+statistics are displayed by using the command option <tt class="docutils literal"><span class="pre">-all-stats</span></tt> or
+<tt class="docutils literal"><span class="pre">-register-file-stats</span></tt>.</p>
+<p>In this example, we can conclude that the IPC is mostly limited by data
+dependencies, and not by resource pressure.</p>
+</div>
+<div class="section" id="instruction-flow">
+<h3>Instruction Flow<a class="headerlink" href="#instruction-flow" title="Permalink to this headline">¶</a></h3>
+<p>This section describes the instruction flow through MCA’s default out-of-order
+pipeline, as well as the functional units involved in the process.</p>
+<p>The default pipeline implements the following sequence of stages used to
+process instructions.</p>
+<ul class="simple">
+<li>Dispatch (Instruction is dispatched to the schedulers).</li>
+<li>Issue (Instruction is issued to the processor pipelines).</li>
+<li>Write Back (Instruction is executed, and results are written back).</li>
+<li>Retire (Instruction is retired; writes are architecturally committed).</li>
+</ul>
+<p>The default pipeline only models the out-of-order portion of a processor.
+Therefore, the instruction fetch and decode stages are not modeled. Performance
+bottlenecks in the frontend are not diagnosed. MCA assumes that instructions
+have all been decoded and placed into a queue. Also, MCA does not model branch
+prediction.</p>
+<div class="section" id="instruction-dispatch">
+<h4>Instruction Dispatch<a class="headerlink" href="#instruction-dispatch" title="Permalink to this headline">¶</a></h4>
+<p>During the dispatch stage, instructions are picked in program order from a
+queue of already decoded instructions, and dispatched in groups to the
+simulated hardware schedulers.</p>
+<p>The size of a dispatch group depends on the availability of the simulated
+hardware resources. The processor dispatch width defaults to the value
+of the <tt class="docutils literal"><span class="pre">IssueWidth</span></tt> in LLVM’s scheduling model.</p>
+<p>An instruction can be dispatched if:</p>
+<ul class="simple">
+<li>The size of the dispatch group is smaller than processor’s dispatch width.</li>
+<li>There are enough entries in the reorder buffer.</li>
+<li>There are enough physical registers to do register renaming.</li>
+<li>The schedulers are not full.</li>
+</ul>
+<p>Scheduling models can optionally specify which register files are available on
+the processor. MCA uses that information to initialize register file
+descriptors. Users can limit the number of physical registers that are
+globally available for register renaming by using the command option
+<tt class="docutils literal"><span class="pre">-register-file-size</span></tt>. A value of zero for this option means <em>unbounded</em>.
+By knowing how many registers are available for renaming, MCA can predict
+dispatch stalls caused by the lack of registers.</p>
+<p>The number of reorder buffer entries consumed by an instruction depends on the
+number of micro-opcodes specified by the target scheduling model. MCA’s
+reorder buffer’s purpose is to track the progress of instructions that are
+“in-flight,” and to retire instructions in program order. The number of
+entries in the reorder buffer defaults to the <cite>MicroOpBufferSize</cite> provided by
+the target scheduling model.</p>
+<p>Instructions that are dispatched to the schedulers consume scheduler buffer
+entries. <strong class="program">llvm-mca</strong> queries the scheduling model to determine the set
+of buffered resources consumed by an instruction. Buffered resources are
+treated like scheduler resources.</p>
+</div>
+<div class="section" id="instruction-issue">
+<h4>Instruction Issue<a class="headerlink" href="#instruction-issue" title="Permalink to this headline">¶</a></h4>
+<p>Each processor scheduler implements a buffer of instructions. An instruction
+has to wait in the scheduler’s buffer until input register operands become
+available. Only at that point, does the instruction becomes eligible for
+execution and may be issued (potentially out-of-order) for execution.
+Instruction latencies are computed by <strong class="program">llvm-mca</strong> with the help of the
+scheduling model.</p>
+<p><strong class="program">llvm-mca</strong>‘s scheduler is designed to simulate multiple processor
+schedulers. The scheduler is responsible for tracking data dependencies, and
+dynamically selecting which processor resources are consumed by instructions.
+It delegates the management of processor resource units and resource groups to a
+resource manager. The resource manager is responsible for selecting resource
+units that are consumed by instructions. For example, if an instruction
+consumes 1cy of a resource group, the resource manager selects one of the
+available units from the group; by default, the resource manager uses a
+round-robin selector to guarantee that resource usage is uniformly distributed
+between all units of a group.</p>
+<p><strong class="program">llvm-mca</strong>‘s scheduler implements three instruction queues:</p>
+<ul class="simple">
+<li>WaitQueue: a queue of instructions whose operands are not ready.</li>
+<li>ReadyQueue: a queue of instructions ready to execute.</li>
+<li>IssuedQueue: a queue of instructions executing.</li>
+</ul>
+<p>Depending on the operand availability, instructions that are dispatched to the
+scheduler are either placed into the WaitQueue or into the ReadyQueue.</p>
+<p>Every cycle, the scheduler checks if instructions can be moved from the
+WaitQueue to the ReadyQueue, and if instructions from the ReadyQueue can be
+issued to the underlying pipelines. The algorithm prioritizes older instructions
+over younger instructions.</p>
+</div>
+<div class="section" id="write-back-and-retire-stage">
+<h4>Write-Back and Retire Stage<a class="headerlink" href="#write-back-and-retire-stage" title="Permalink to this headline">¶</a></h4>
+<p>Issued instructions are moved from the ReadyQueue to the IssuedQueue. There,
+instructions wait until they reach the write-back stage. At that point, they
+get removed from the queue and the retire control unit is notified.</p>
+<p>When instructions are executed, the retire control unit flags the
+instruction as “ready to retire.”</p>
+<p>Instructions are retired in program order. The register file is notified of
+the retirement so that it can free the physical registers that were allocated
+for the instruction during the register renaming stage.</p>
+</div>
+<div class="section" id="load-store-unit-and-memory-consistency-model">
+<h4>Load/Store Unit and Memory Consistency Model<a class="headerlink" href="#load-store-unit-and-memory-consistency-model" title="Permalink to this headline">¶</a></h4>
+<p>To simulate an out-of-order execution of memory operations, <strong class="program">llvm-mca</strong>
+utilizes a simulated load/store unit (LSUnit) to simulate the speculative
+execution of loads and stores.</p>
+<p>Each load (or store) consumes an entry in the load (or store) queue. Users can
+specify flags <tt class="docutils literal"><span class="pre">-lqueue</span></tt> and <tt class="docutils literal"><span class="pre">-squeue</span></tt> to limit the number of entries in the
+load and store queues respectively. The queues are unbounded by default.</p>
+<p>The LSUnit implements a relaxed consistency model for memory loads and stores.
+The rules are:</p>
+<ol class="arabic simple">
+<li>A younger load is allowed to pass an older load only if there are no
+intervening stores or barriers between the two loads.</li>
+<li>A younger load is allowed to pass an older store provided that the load does
+not alias with the store.</li>
+<li>A younger store is not allowed to pass an older store.</li>
+<li>A younger store is not allowed to pass an older load.</li>
+</ol>
+<p>By default, the LSUnit optimistically assumes that loads do not alias
+(<cite>-noalias=true</cite>) store operations. Under this assumption, younger loads are
+always allowed to pass older stores. Essentially, the LSUnit does not attempt
+to run any alias analysis to predict when loads and stores do not alias with
+each other.</p>
+<p>Note that, in the case of write-combining memory, rule 3 could be relaxed to
+allow reordering of non-aliasing store operations. That being said, at the
+moment, there is no way to further relax the memory model (<tt class="docutils literal"><span class="pre">-noalias</span></tt> is the
+only option). Essentially, there is no option to specify a different memory
+type (e.g., write-back, write-combining, write-through; etc.) and consequently
+to weaken, or strengthen, the memory model.</p>
+<p>Other limitations are:</p>
+<ul class="simple">
+<li>The LSUnit does not know when store-to-load forwarding may occur.</li>
+<li>The LSUnit does not know anything about cache hierarchy and memory types.</li>
+<li>The LSUnit does not know how to identify serializing operations and memory
+fences.</li>
+</ul>
+<p>The LSUnit does not attempt to predict if a load or store hits or misses the L1
+cache. It only knows if an instruction “MayLoad” and/or “MayStore.” For
+loads, the scheduling model provides an “optimistic” load-to-use latency (which
+usually matches the load-to-use latency for when there is a hit in the L1D).</p>
+<p><strong class="program">llvm-mca</strong> does not know about serializing operations or memory-barrier
+like instructions. The LSUnit conservatively assumes that an instruction which
+has both “MayLoad” and unmodeled side effects behaves like a “soft”
+load-barrier. That means, it serializes loads without forcing a flush of the
+load queue. Similarly, instructions that “MayStore” and have unmodeled side
+effects are treated like store barriers. A full memory barrier is a “MayLoad”
+and “MayStore” instruction with unmodeled side effects. This is inaccurate, but
+it is the best that we can do at the moment with the current information
+available in LLVM.</p>
+<p>A load/store barrier consumes one entry of the load/store queue. A load/store
+barrier enforces ordering of loads/stores. A younger load cannot pass a load
+barrier. Also, a younger store cannot pass a store barrier. A younger load
+has to wait for the memory/load barrier to execute. A load/store barrier is
+“executed” when it becomes the oldest entry in the load/store queue(s). That
+also means, by construction, all of the older loads/stores have been executed.</p>
+<p>In conclusion, the full set of load/store consistency rules are:</p>
+<ol class="arabic simple">
+<li>A store may not pass a previous store.</li>
+<li>A store may not pass a previous load (regardless of <tt class="docutils literal"><span class="pre">-noalias</span></tt>).</li>
+<li>A store has to wait until an older store barrier is fully executed.</li>
+<li>A load may pass a previous load.</li>
+<li>A load may not pass a previous store unless <tt class="docutils literal"><span class="pre">-noalias</span></tt> is set.</li>
+<li>A load has to wait until an older load barrier is fully executed.</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="bugpoint.html" title="bugpoint - automatic test case reduction tool"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="dsymutil.html" title="dsymutil - manipulate archived DWARF debug symbol files"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.1/docs/CommandGuide/llvm-nm.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.1/docs/CommandGuide/llvm-nm.html?rev=349965&view=auto
==============================================================================
--- www-releases/trunk/7.0.1/docs/CommandGuide/llvm-nm.html (added)
+++ www-releases/trunk/7.0.1/docs/CommandGuide/llvm-nm.html Fri Dec 21 13:53:02 2018
@@ -0,0 +1,270 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>llvm-nm - list LLVM bitcode and object fileâs symbol table — LLVM 7 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 7 documentation" href="../index.html" />
+ <link rel="up" title="LLVM Command Guide" href="index.html" />
+ <link rel="next" title="llvm-config - Print LLVM compilation options" href="llvm-config.html" />
+ <link rel="prev" title="llvm-lib - LLVM lib.exe compatible library tool" href="llvm-lib.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="llvm-config.html" title="llvm-config - Print LLVM compilation options"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="llvm-lib.html" title="llvm-lib - LLVM lib.exe compatible library tool"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" accesskey="U">LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-nm-list-llvm-bitcode-and-object-file-s-symbol-table">
+<h1>llvm-nm - list LLVM bitcode and object file’s symbol table<a class="headerlink" href="#llvm-nm-list-llvm-bitcode-and-object-file-s-symbol-table" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="synopsis">
+<h2>SYNOPSIS<a class="headerlink" href="#synopsis" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-nm</strong> [<em>options</em>] [<em>filenames...</em>]</p>
+</div>
+<div class="section" id="description">
+<h2>DESCRIPTION<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
+<p>The <strong class="program">llvm-nm</strong> utility lists the names of symbols from the LLVM bitcode
+files, object files, or <strong class="program">ar</strong> archives containing them, named on the
+command line. Each symbol is listed along with some simple information about
+its provenance. If no file name is specified, or <em>-</em> is used as a file name,
+<strong class="program">llvm-nm</strong> will process a file on its standard input stream.</p>
+<p><strong class="program">llvm-nm</strong>‘s default output format is the traditional BSD <strong class="program">nm</strong>
+output format. Each such output record consists of an (optional) 8-digit
+hexadecimal address, followed by a type code character, followed by a name, for
+each symbol. One record is printed per line; fields are separated by spaces.
+When the address is omitted, it is replaced by 8 spaces.</p>
+<p>Type code characters currently supported, and their meanings, are as follows:</p>
+<p>U</p>
+<blockquote>
+<div>Named object is referenced but undefined in this bitcode file</div></blockquote>
+<p>C</p>
+<blockquote>
+<div>Common (multiple definitions link together into one def)</div></blockquote>
+<p>W</p>
+<blockquote>
+<div>Weak reference (multiple definitions link together into zero or one definitions)</div></blockquote>
+<p>t</p>
+<blockquote>
+<div>Local function (text) object</div></blockquote>
+<p>T</p>
+<blockquote>
+<div>Global function (text) object</div></blockquote>
+<p>d</p>
+<blockquote>
+<div>Local data object</div></blockquote>
+<p>D</p>
+<blockquote>
+<div>Global data object</div></blockquote>
+<p>?</p>
+<blockquote>
+<div>Something unrecognizable</div></blockquote>
+<p>Because LLVM bitcode files typically contain objects that are not considered to
+have addresses until they are linked into an executable image or dynamically
+compiled “just-in-time”, <strong class="program">llvm-nm</strong> does not print an address for any
+symbol in an LLVM bitcode file, even symbols which are defined in the bitcode
+file.</p>
+</div>
+<div class="section" id="options">
+<h2>OPTIONS<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h2>
+<dl class="option">
+<dt id="cmdoption-llvm-nm-B">
+<tt class="descname">-B</tt><tt class="descclassname"> (default)</tt><a class="headerlink" href="#cmdoption-llvm-nm-B" title="Permalink to this definition">¶</a></dt>
+<dd><p>Use BSD output format. Alias for <cite>–format=bsd</cite>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm-P">
+<tt class="descname">-P</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm-P" title="Permalink to this definition">¶</a></dt>
+<dd><p>Use POSIX.2 output format. Alias for <cite>–format=posix</cite>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--debug-syms">
+<tt class="descname">--debug-syms</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-a</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--debug-syms" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show all symbols, even debugger only.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--defined-only">
+<tt class="descname">--defined-only</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--defined-only" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print only symbols defined in this file (as opposed to
+symbols which may be referenced by objects in this file, but not
+defined in this file.)</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--dynamic">
+<tt class="descname">--dynamic</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-D</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--dynamic" title="Permalink to this definition">¶</a></dt>
+<dd><p>Display dynamic symbols instead of normal symbols.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--extern-only">
+<tt class="descname">--extern-only</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-g</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--extern-only" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print only symbols whose definitions are external; that is, accessible
+from other files.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--no-weak">
+<tt class="descname">--no-weak</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-W</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--no-weak" title="Permalink to this definition">¶</a></dt>
+<dd><p>Don’t print any weak symbols in the output.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--format">
+<tt class="descname">--format</tt><tt class="descclassname">=format</tt><tt class="descclassname">, </tt><tt class="descname">-f</tt><tt class="descclassname"> format</tt><a class="headerlink" href="#cmdoption-llvm-nm--format" title="Permalink to this definition">¶</a></dt>
+<dd><p>Select an output format; <em>format</em> may be <em>sysv</em>, <em>posix</em>, or <em>bsd</em>. The default
+is <em>bsd</em>.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm-help">
+<tt class="descname">-help</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm-help" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print a summary of command-line options and their meanings.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--no-sort">
+<tt class="descname">--no-sort</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-p</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--no-sort" title="Permalink to this definition">¶</a></dt>
+<dd><p>Shows symbols in order encountered.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--numeric-sort">
+<tt class="descname">--numeric-sort</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-n</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-v</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--numeric-sort" title="Permalink to this definition">¶</a></dt>
+<dd><p>Sort symbols by address.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--print-file-name">
+<tt class="descname">--print-file-name</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-A</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-o</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--print-file-name" title="Permalink to this definition">¶</a></dt>
+<dd><p>Precede each symbol with the file it came from.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--print-size">
+<tt class="descname">--print-size</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-S</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--print-size" title="Permalink to this definition">¶</a></dt>
+<dd><p>Show symbol size instead of address.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--size-sort">
+<tt class="descname">--size-sort</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--size-sort" title="Permalink to this definition">¶</a></dt>
+<dd><p>Sort symbols by size.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--undefined-only">
+<tt class="descname">--undefined-only</tt><tt class="descclassname"></tt><tt class="descclassname">, </tt><tt class="descname">-u</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--undefined-only" title="Permalink to this definition">¶</a></dt>
+<dd><p>Print only symbols referenced but not defined in this file.</p>
+</dd></dl>
+
+<dl class="option">
+<dt id="cmdoption-llvm-nm--radix">
+<tt class="descname">--radix</tt><tt class="descclassname">=RADIX</tt><tt class="descclassname">, </tt><tt class="descname">-t</tt><tt class="descclassname"></tt><a class="headerlink" href="#cmdoption-llvm-nm--radix" title="Permalink to this definition">¶</a></dt>
+<dd><p>Specify the radix of the symbol address(es). Values accepted d(decimal),
+x(hexadecomal) and o(octal).</p>
+</dd></dl>
+
+</div>
+<div class="section" id="bugs">
+<h2>BUGS<a class="headerlink" href="#bugs" title="Permalink to this headline">¶</a></h2>
+<blockquote>
+<div><ul class="simple">
+<li><strong class="program">llvm-nm</strong> does not support the full set of arguments that GNU
+<strong class="program">nm</strong> does.</li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="exit-status">
+<h2>EXIT STATUS<a class="headerlink" href="#exit-status" title="Permalink to this headline">¶</a></h2>
+<p><strong class="program">llvm-nm</strong> exits with an exit code of zero.</p>
+</div>
+<div class="section" id="see-also">
+<h2>SEE ALSO<a class="headerlink" href="#see-also" title="Permalink to this headline">¶</a></h2>
+<p>llvm-dis, ar(1), nm(1)</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="llvm-config.html" title="llvm-config - Print LLVM compilation options"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="llvm-lib.html" title="llvm-lib - LLVM lib.exe compatible library tool"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li><a href="index.html" >LLVM Command Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-12-21.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
More information about the llvm-commits
mailing list