[www-releases] r372328 - Check in 9.0.0 source and docs
Hans Wennborg via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 19 07:32:55 PDT 2019
Added: www-releases/trunk/9.0.0/docs/StackMaps.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/StackMaps.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/StackMaps.html (added)
+++ www-releases/trunk/9.0.0/docs/StackMaps.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,579 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Stack maps and patch points in LLVM — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Design and Usage of the InAlloca Attribute" href="InAlloca.html" />
+ <link rel="prev" title="AMDGPU Instructions Notation" href="AMDGPUInstructionNotation.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" role="navigation" aria-label="related navigation">
+ <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="InAlloca.html" title="Design and Usage of the InAlloca Attribute"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="AMDGPUInstructionNotation.html" title="AMDGPU Instructions Notation"
+ 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" role="main">
+
+ <div class="section" id="stack-maps-and-patch-points-in-llvm">
+<h1>Stack maps and patch points in LLVM<a class="headerlink" href="#stack-maps-and-patch-points-in-llvm" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#definitions" id="id5">Definitions</a></li>
+<li><a class="reference internal" href="#motivation" id="id6">Motivation</a></li>
+<li><a class="reference internal" href="#intrinsics" id="id7">Intrinsics</a><ul>
+<li><a class="reference internal" href="#llvm-experimental-stackmap-intrinsic" id="id8">â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code>â Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-patchpoint-intrinsic" id="id9">â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint.*</span></code>â Intrinsic</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#stack-map-format" id="id10">Stack Map Format</a><ul>
+<li><a class="reference internal" href="#stack-map-section" id="id11">Stack Map Section</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#stack-map-usage" id="id12">Stack Map Usage</a><ul>
+<li><a class="reference internal" href="#direct-stack-map-entries" id="id13">Direct Stack Map Entries</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#supported-architectures" id="id14">Supported Architectures</a></li>
+</ul>
+</div>
+<div class="section" id="definitions">
+<h2><a class="toc-backref" href="#id5">Definitions</a><a class="headerlink" href="#definitions" title="Permalink to this headline">¶</a></h2>
+<p>In this document we refer to the âruntimeâ collectively as all
+components that serve as the LLVM client, including the LLVM IR
+generator, object code consumer, and code patcher.</p>
+<p>A stack map records the location of <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code> at a particular
+instruction address. These <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code> do not refer to all the
+LLVM values live across the stack map. Instead, they are only the
+values that the runtime requires to be live at this point. For
+example, they may be the values the runtime will need to resume
+program execution at that point independent of the compiled function
+containing the stack map.</p>
+<p>LLVM emits stack map data into the object code within a designated
+<a class="reference internal" href="#stackmap-section"><span class="std std-ref">Stack Map Section</span></a>. This stack map data contains a record for
+each stack map. The record stores the stack mapâs instruction address
+and contains a entry for each mapped value. Each entry encodes a
+valueâs location as a register, stack offset, or constant.</p>
+<p>A patch point is an instruction address at which space is reserved for
+patching a new instruction sequence at run time. Patch points look
+much like calls to LLVM. They take arguments that follow a calling
+convention and may return a value. They also imply stack map
+generation, which allows the runtime to locate the patchpoint and
+find the location of <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code> at that point.</p>
+</div>
+<div class="section" id="motivation">
+<h2><a class="toc-backref" href="#id6">Motivation</a><a class="headerlink" href="#motivation" title="Permalink to this headline">¶</a></h2>
+<p>This functionality is currently experimental but is potentially useful
+in a variety of settings, the most obvious being a runtime (JIT)
+compiler. Example applications of the patchpoint intrinsics are
+implementing an inline call cache for polymorphic method dispatch or
+optimizing the retrieval of properties in dynamically typed languages
+such as JavaScript.</p>
+<p>The intrinsics documented here are currently used by the JavaScript
+compiler within the open source WebKit project, see the <a class="reference external" href="https://trac.webkit.org/wiki/FTLJIT">FTL JIT</a>, but they are designed to be
+used whenever stack maps or code patching are needed. Because the
+intrinsics have experimental status, compatibility across LLVM
+releases is not guaranteed.</p>
+<p>The stack map functionality described in this document is separate
+from the functionality described in
+<a class="reference internal" href="GarbageCollection.html#stack-map"><span class="std std-ref">Computing stack maps</span></a>. <cite>GCFunctionMetadata</cite> provides the location of
+pointers into a collected heap captured by the <cite>GCRoot</cite> intrinsic,
+which can also be considered a âstack mapâ. Unlike the stack maps
+defined above, the <cite>GCFunctionMetadata</cite> stack map interface does not
+provide a way to associate live register values of arbitrary type with
+an instruction address, nor does it specify a format for the resulting
+stack map. The stack maps described here could potentially provide
+richer information to a garbage collecting runtime, but that usage
+will not be discussed in this document.</p>
+</div>
+<div class="section" id="intrinsics">
+<h2><a class="toc-backref" href="#id7">Intrinsics</a><a class="headerlink" href="#intrinsics" title="Permalink to this headline">¶</a></h2>
+<p>The following two kinds of intrinsics can be used to implement stack
+maps and patch points: <code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code> and
+<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint</span></code>. Both kinds of intrinsics generate a
+stack map record, and they both allow some form of code patching. They
+can be used independently (i.e. <code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint</span></code>
+implicitly generates a stack map without the need for an additional
+call to <code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code>). The choice of which to use
+depends on whether it is necessary to reserve space for code patching
+and whether any of the intrinsic arguments should be lowered according
+to calling conventions. <code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code> does not
+reserve any space, nor does it expect any call arguments. If the
+runtime patches code at the stack mapâs address, it will destructively
+overwrite the program text. This is unlike
+<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint</span></code>, which reserves space for in-place
+patching without overwriting surrounding code. The
+<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint</span></code> intrinsic also lowers a specified
+number of arguments according to its calling convention. This allows
+patched code to make in-place function calls without marshaling.</p>
+<p>Each instance of one of these intrinsics generates a stack map record
+in the <a class="reference internal" href="#stackmap-section"><span class="std std-ref">Stack Map Section</span></a>. The record includes an ID, allowing
+the runtime to uniquely identify the stack map, and the offset within
+the code from the beginning of the enclosing function.</p>
+<div class="section" id="llvm-experimental-stackmap-intrinsic">
+<h3><a class="toc-backref" href="#id8">â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code>â Intrinsic</a><a class="headerlink" href="#llvm-experimental-stackmap-intrinsic" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="syntax">
+<h4>Syntax:<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">declare</span> <span class="n">void</span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">stackmap</span><span class="p">(</span><span class="n">i64</span> <span class="o"><</span><span class="nb">id</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">numShadowBytes</span><span class="o">></span><span class="p">,</span> <span class="o">...</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="overview">
+<h4>Overview:<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h4>
+<p>The â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code>â intrinsic records the location of
+specified values in the stack map without generating any code.</p>
+</div>
+<div class="section" id="operands">
+<h4>Operands:<a class="headerlink" href="#operands" title="Permalink to this headline">¶</a></h4>
+<p>The first operand is an ID to be encoded within the stack map. The
+second operand is the number of shadow bytes following the
+intrinsic. The variable number of operands that follow are the <code class="docutils literal notranslate"><span class="pre">live</span>
+<span class="pre">values</span></code> for which locations will be recorded in the stack map.</p>
+<p>To use this intrinsic as a bare-bones stack map, with no code patching
+support, the number of shadow bytes can be set to zero.</p>
+</div>
+<div class="section" id="semantics">
+<h4>Semantics:<a class="headerlink" href="#semantics" title="Permalink to this headline">¶</a></h4>
+<p>The stack map intrinsic generates no code in place, unless nops are
+needed to cover its shadow (see below). However, its offset from
+function entry is stored in the stack map. This is the relative
+instruction address immediately following the instructions that
+precede the stack map.</p>
+<p>The stack map ID allows a runtime to locate the desired stack map
+record. LLVM passes this ID through directly to the stack map
+record without checking uniqueness.</p>
+<p>LLVM guarantees a shadow of instructions following the stack mapâs
+instruction offset during which neither the end of the basic block nor
+another call to <code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap</span></code> or
+<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint</span></code> may occur. This allows the runtime to
+patch the code at this point in response to an event triggered from
+outside the code. The code for instructions following the stack map
+may be emitted in the stack mapâs shadow, and these instructions may
+be overwritten by destructive patching. Without shadow bytes, this
+destructive patching could overwrite program text or data outside the
+current function. We disallow overlapping stack map shadows so that
+the runtime does not need to consider this corner case.</p>
+<p>For example, a stack map with 8 byte shadow:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">call</span> <span class="kt">void</span> <span class="vg">@runtime</span><span class="p">()</span>
+<span class="k">call</span> <span class="kt">void</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="p">...)*</span> <span class="vg">@llvm.experimental.stackmap</span><span class="p">(</span><span class="k">i64</span> <span class="m">77</span><span class="p">,</span> <span class="k">i32</span> <span class="m">8</span><span class="p">,</span>
+ <span class="k">i64</span><span class="p">*</span> <span class="nv">%ptr</span><span class="p">)</span>
+<span class="nv">%val</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i64</span><span class="p">*</span> <span class="nv">%ptr</span>
+<span class="nv">%add</span> <span class="p">=</span> <span class="k">add</span> <span class="k">i64</span> <span class="nv">%val</span><span class="p">,</span> <span class="m">3</span>
+<span class="k">ret</span> <span class="k">i64</span> <span class="nv">%add</span>
+</pre></div>
+</div>
+<p>May require one byte of nop-padding:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>0x00 callq _runtime
+0x05 nop <--- stack map address
+0x06 movq (%rdi), %rax
+0x07 addq $3, %rax
+0x0a popq %rdx
+0x0b ret <---- end of 8-byte shadow
+</pre></div>
+</div>
+<p>Now, if the runtime needs to invalidate the compiled code, it may
+patch 8 bytes of code at the stack mapâs address at follows:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>0x00 callq _runtime
+0x05 movl $0xffff, %rax <--- patched code at stack map address
+0x0a callq *%rax <---- end of 8-byte shadow
+</pre></div>
+</div>
+<p>This way, after the normal call to the runtime returns, the code will
+execute a patched call to a special entry point that can rebuild a
+stack frame from the values located by the stack map.</p>
+</div>
+</div>
+<div class="section" id="llvm-experimental-patchpoint-intrinsic">
+<h3><a class="toc-backref" href="#id9">â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint.*</span></code>â Intrinsic</a><a class="headerlink" href="#llvm-experimental-patchpoint-intrinsic" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id1">
+<h4>Syntax:<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">declare</span> <span class="n">void</span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">patchpoint</span><span class="o">.</span><span class="n">void</span><span class="p">(</span><span class="n">i64</span> <span class="o"><</span><span class="nb">id</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">numBytes</span><span class="o">></span><span class="p">,</span>
+ <span class="n">i8</span><span class="o">*</span> <span class="o"><</span><span class="n">target</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">numArgs</span><span class="o">></span><span class="p">,</span> <span class="o">...</span><span class="p">)</span>
+<span class="n">declare</span> <span class="n">i64</span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">patchpoint</span><span class="o">.</span><span class="n">i64</span><span class="p">(</span><span class="n">i64</span> <span class="o"><</span><span class="nb">id</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">numBytes</span><span class="o">></span><span class="p">,</span>
+ <span class="n">i8</span><span class="o">*</span> <span class="o"><</span><span class="n">target</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">numArgs</span><span class="o">></span><span class="p">,</span> <span class="o">...</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="id2">
+<h4>Overview:<a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h4>
+<p>The â<code class="docutils literal notranslate"><span class="pre">llvm.experimental.patchpoint.*</span></code>â intrinsics creates a function
+call to the specified <code class="docutils literal notranslate"><span class="pre"><target></span></code> and records the location of specified
+values in the stack map.</p>
+</div>
+<div class="section" id="id3">
+<h4>Operands:<a class="headerlink" href="#id3" title="Permalink to this headline">¶</a></h4>
+<p>The first operand is an ID, the second operand is the number of bytes
+reserved for the patchable region, the third operand is the target
+address of a function (optionally null), and the fourth operand
+specifies how many of the following variable operands are considered
+function call arguments. The remaining variable number of operands are
+the <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code> for which locations will be recorded in the stack
+map.</p>
+</div>
+<div class="section" id="id4">
+<h4>Semantics:<a class="headerlink" href="#id4" title="Permalink to this headline">¶</a></h4>
+<p>The patch point intrinsic generates a stack map. It also emits a
+function call to the address specified by <code class="docutils literal notranslate"><span class="pre"><target></span></code> if the address
+is not a constant null. The function call and its arguments are
+lowered according to the calling convention specified at the
+intrinsicâs callsite. Variants of the intrinsic with non-void return
+type also return a value according to calling convention.</p>
+<p>On PowerPC, note that <code class="docutils literal notranslate"><span class="pre"><target></span></code> must be the ABI function pointer for the
+intended target of the indirect call. Specifically, when compiling for the
+ELF V1 ABI, <code class="docutils literal notranslate"><span class="pre"><target></span></code> is the function-descriptor address normally used as
+the C/C++ function-pointer representation.</p>
+<p>Requesting zero patch point arguments is valid. In this case, all
+variable operands are handled just like
+<code class="docutils literal notranslate"><span class="pre">llvm.experimental.stackmap.*</span></code>. The difference is that space will
+still be reserved for patching, a call will be emitted, and a return
+value is allowed.</p>
+<p>The location of the arguments are not normally recorded in the stack
+map because they are already fixed by the calling convention. The
+remaining <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code> will have their location recorded, which
+could be a register, stack location, or constant. A special calling
+convention has been introduced for use with stack maps, anyregcc,
+which forces the arguments to be loaded into registers but allows
+those register to be dynamically allocated. These argument registers
+will have their register locations recorded in the stack map in
+addition to the remaining <code class="docutils literal notranslate"><span class="pre">live</span> <span class="pre">values</span></code>.</p>
+<p>The patch point also emits nops to cover at least <code class="docutils literal notranslate"><span class="pre"><numBytes></span></code> of
+instruction encoding space. Hence, the client must ensure that
+<code class="docutils literal notranslate"><span class="pre"><numBytes></span></code> is enough to encode a call to the target address on the
+supported targets. If the call target is constant null, then there is
+no minimum requirement. A zero-byte null target patchpoint is
+valid.</p>
+<p>The runtime may patch the code emitted for the patch point, including
+the call sequence and nops. However, the runtime may not assume
+anything about the code LLVM emits within the reserved space. Partial
+patching is not allowed. The runtime must patch all reserved bytes,
+padding with nops if necessary.</p>
+<p>This example shows a patch point reserving 15 bytes, with one argument
+in $rdi, and a return value in $rax per native calling convention:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="nv">%target</span> <span class="p">=</span> <span class="k">inttoptr</span> <span class="k">i64</span> <span class="m">-281474976710654</span> <span class="k">to</span> <span class="k">i8</span><span class="p">*</span>
+<span class="nv">%val</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i64</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="p">...)*</span>
+ <span class="vg">@llvm.experimental.patchpoint.i64</span><span class="p">(</span><span class="k">i64</span> <span class="m">78</span><span class="p">,</span> <span class="k">i32</span> <span class="m">15</span><span class="p">,</span>
+ <span class="k">i8</span><span class="p">*</span> <span class="nv">%target</span><span class="p">,</span> <span class="k">i32</span> <span class="m">1</span><span class="p">,</span> <span class="k">i64</span><span class="p">*</span> <span class="nv">%ptr</span><span class="p">)</span>
+<span class="nv">%add</span> <span class="p">=</span> <span class="k">add</span> <span class="k">i64</span> <span class="nv">%val</span><span class="p">,</span> <span class="m">3</span>
+<span class="k">ret</span> <span class="k">i64</span> <span class="nv">%add</span>
+</pre></div>
+</div>
+<p>May generate:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>0x00 movabsq $0xffff000000000002, %r11 <--- patch point address
+0x0a callq *%r11
+0x0d nop
+0x0e nop <--- end of reserved 15-bytes
+0x0f addq $0x3, %rax
+0x10 movl %rax, 8(%rsp)
+</pre></div>
+</div>
+<p>Note that no stack map locations will be recorded. If the patched code
+sequence does not need arguments fixed to specific calling convention
+registers, then the <code class="docutils literal notranslate"><span class="pre">anyregcc</span></code> convention may be used:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>%val = call anyregcc @llvm.experimental.patchpoint(i64 78, i32 15,
+ i8* %target, i32 1,
+ i64* %ptr)
+</pre></div>
+</div>
+<p>The stack map now indicates the location of the %ptr argument and
+return value:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>Stack Map: ID=78, Loc0=%r9 Loc1=%r8
+</pre></div>
+</div>
+<p>The patch code sequence may now use the argument that happened to be
+allocated in %r8 and return a value allocated in %r9:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>0x00 movslq 4(%r8) %r9 <--- patched code at patch point address
+0x03 nop
+...
+0x0e nop <--- end of reserved 15-bytes
+0x0f addq $0x3, %r9
+0x10 movl %r9, 8(%rsp)
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+<div class="section" id="stack-map-format">
+<span id="stackmap-format"></span><h2><a class="toc-backref" href="#id10">Stack Map Format</a><a class="headerlink" href="#stack-map-format" title="Permalink to this headline">¶</a></h2>
+<p>The existence of a stack map or patch point intrinsic within an LLVM
+Module forces code emission to create a <a class="reference internal" href="#stackmap-section"><span class="std std-ref">Stack Map Section</span></a>. The
+format of this section follows:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>Header {
+ uint8 : Stack Map Version (current version is 3)
+ uint8 : Reserved (expected to be 0)
+ uint16 : Reserved (expected to be 0)
+}
+uint32 : NumFunctions
+uint32 : NumConstants
+uint32 : NumRecords
+StkSizeRecord[NumFunctions] {
+ uint64 : Function Address
+ uint64 : Stack Size
+ uint64 : Record Count
+}
+Constants[NumConstants] {
+ uint64 : LargeConstant
+}
+StkMapRecord[NumRecords] {
+ uint64 : PatchPoint ID
+ uint32 : Instruction Offset
+ uint16 : Reserved (record flags)
+ uint16 : NumLocations
+ Location[NumLocations] {
+ uint8 : Register | Direct | Indirect | Constant | ConstantIndex
+ uint8 : Reserved (expected to be 0)
+ uint16 : Location Size
+ uint16 : Dwarf RegNum
+ uint16 : Reserved (expected to be 0)
+ int32 : Offset or SmallConstant
+ }
+ uint32 : Padding (only if required to align to 8 byte)
+ uint16 : Padding
+ uint16 : NumLiveOuts
+ LiveOuts[NumLiveOuts]
+ uint16 : Dwarf RegNum
+ uint8 : Reserved
+ uint8 : Size in Bytes
+ }
+ uint32 : Padding (only if required to align to 8 byte)
+}
+</pre></div>
+</div>
+<p>The first byte of each location encodes a type that indicates how to
+interpret the <code class="docutils literal notranslate"><span class="pre">RegNum</span></code> and <code class="docutils literal notranslate"><span class="pre">Offset</span></code> fields as follows:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="13%" />
+<col width="16%" />
+<col width="30%" />
+<col width="42%" />
+</colgroup>
+<tbody valign="top">
+<tr class="row-odd"><td>Encoding</td>
+<td>Type</td>
+<td>Value</td>
+<td>Description</td>
+</tr>
+<tr class="row-even"><td>0x1</td>
+<td>Register</td>
+<td>Reg</td>
+<td>Value in a register</td>
+</tr>
+<tr class="row-odd"><td>0x2</td>
+<td>Direct</td>
+<td>Reg + Offset</td>
+<td>Frame index value</td>
+</tr>
+<tr class="row-even"><td>0x3</td>
+<td>Indirect</td>
+<td>[Reg + Offset]</td>
+<td>Spilled value</td>
+</tr>
+<tr class="row-odd"><td>0x4</td>
+<td>Constant</td>
+<td>Offset</td>
+<td>Small constant</td>
+</tr>
+<tr class="row-even"><td>0x5</td>
+<td>ConstIndex</td>
+<td>Constants[Offset]</td>
+<td>Large constant</td>
+</tr>
+</tbody>
+</table>
+<p>In the common case, a value is available in a register, and the
+<code class="docutils literal notranslate"><span class="pre">Offset</span></code> field will be zero. Values spilled to the stack are encoded
+as <code class="docutils literal notranslate"><span class="pre">Indirect</span></code> locations. The runtime must load those values from a
+stack address, typically in the form <code class="docutils literal notranslate"><span class="pre">[BP</span> <span class="pre">+</span> <span class="pre">Offset]</span></code>. If an
+<code class="docutils literal notranslate"><span class="pre">alloca</span></code> value is passed directly to a stack map intrinsic, then
+LLVM may fold the frame index into the stack map as an optimization to
+avoid allocating a register or stack slot. These frame indices will be
+encoded as <code class="docutils literal notranslate"><span class="pre">Direct</span></code> locations in the form <code class="docutils literal notranslate"><span class="pre">BP</span> <span class="pre">+</span> <span class="pre">Offset</span></code>. LLVM may
+also optimize constants by emitting them directly in the stack map,
+either in the <code class="docutils literal notranslate"><span class="pre">Offset</span></code> of a <code class="docutils literal notranslate"><span class="pre">Constant</span></code> location or in the constant
+pool, referred to by <code class="docutils literal notranslate"><span class="pre">ConstantIndex</span></code> locations.</p>
+<p>At each callsite, a âliveoutâ register list is also recorded. These
+are the registers that are live across the stackmap and therefore must
+be saved by the runtime. This is an important optimization when the
+patchpoint intrinsic is used with a calling convention that by default
+preserves most registers as callee-save.</p>
+<p>Each entry in the liveout register list contains a DWARF register
+number and size in bytes. The stackmap format deliberately omits
+specific subregister information. Instead the runtime must interpret
+this information conservatively. For example, if the stackmap reports
+one byte at <code class="docutils literal notranslate"><span class="pre">%rax</span></code>, then the value may be in either <code class="docutils literal notranslate"><span class="pre">%al</span></code> or
+<code class="docutils literal notranslate"><span class="pre">%ah</span></code>. It doesnât matter in practice, because the runtime will
+simply save <code class="docutils literal notranslate"><span class="pre">%rax</span></code>. However, if the stackmap reports 16 bytes at
+<code class="docutils literal notranslate"><span class="pre">%ymm0</span></code>, then the runtime can safely optimize by saving only
+<code class="docutils literal notranslate"><span class="pre">%xmm0</span></code>.</p>
+<p>The stack map format is a contract between an LLVM SVN revision and
+the runtime. It is currently experimental and may change in the short
+term, but minimizing the need to update the runtime is
+important. Consequently, the stack map design is motivated by
+simplicity and extensibility. Compactness of the representation is
+secondary because the runtime is expected to parse the data
+immediately after compiling a module and encode the information in its
+own format. Since the runtime controls the allocation of sections, it
+can reuse the same stack map space for multiple modules.</p>
+<p>Stackmap support is currently only implemented for 64-bit
+platforms. However, a 32-bit implementation should be able to use the
+same format with an insignificant amount of wasted space.</p>
+<div class="section" id="stack-map-section">
+<span id="stackmap-section"></span><h3><a class="toc-backref" href="#id11">Stack Map Section</a><a class="headerlink" href="#stack-map-section" title="Permalink to this headline">¶</a></h3>
+<p>A JIT compiler can easily access this section by providing its own
+memory manager via the LLVM C API
+<code class="docutils literal notranslate"><span class="pre">LLVMCreateSimpleMCJITMemoryManager()</span></code>. When creating the memory
+manager, the JIT provides a callback:
+<code class="docutils literal notranslate"><span class="pre">LLVMMemoryManagerAllocateDataSectionCallback()</span></code>. When LLVM creates
+this section, it invokes the callback and passes the section name. The
+JIT can record the in-memory address of the section at this time and
+later parse it to recover the stack map data.</p>
+<p>For MachO (e.g. on Darwin), the stack map section name is
+â__llvm_stackmapsâ. The segment name is â__LLVM_STACKMAPSâ.</p>
+<p>For ELF (e.g. on Linux), the stack map section name is
+â.llvm_stackmapsâ. The segment name is â__LLVM_STACKMAPSâ.</p>
+</div>
+</div>
+<div class="section" id="stack-map-usage">
+<h2><a class="toc-backref" href="#id12">Stack Map Usage</a><a class="headerlink" href="#stack-map-usage" title="Permalink to this headline">¶</a></h2>
+<p>The stack map support described in this document can be used to
+precisely determine the location of values at a specific position in
+the code. LLVM does not maintain any mapping between those values and
+any higher-level entity. The runtime must be able to interpret the
+stack map record given only the ID, offset, and the order of the
+locations, records, and functions, which LLVM preserves.</p>
+<p>Note that this is quite different from the goal of debug information,
+which is a best-effort attempt to track the location of named
+variables at every instruction.</p>
+<p>An important motivation for this design is to allow a runtime to
+commandeer a stack frame when execution reaches an instruction address
+associated with a stack map. The runtime must be able to rebuild a
+stack frame and resume program execution using the information
+provided by the stack map. For example, execution may resume in an
+interpreter or a recompiled version of the same function.</p>
+<p>This usage restricts LLVM optimization. Clearly, LLVM must not move
+stores across a stack map. However, loads must also be handled
+conservatively. If the load may trigger an exception, hoisting it
+above a stack map could be invalid. For example, the runtime may
+determine that a load is safe to execute without a type check given
+the current state of the type system. If the type system changes while
+some activation of the loadâs function exists on the stack, the load
+becomes unsafe. The runtime can prevent subsequent execution of that
+load by immediately patching any stack map location that lies between
+the current call site and the load (typically, the runtime would
+simply patch all stack map locations to invalidate the function). If
+the compiler had hoisted the load above the stack map, then the
+program could crash before the runtime could take back control.</p>
+<p>To enforce these semantics, stackmap and patchpoint intrinsics are
+considered to potentially read and write all memory. This may limit
+optimization more than some clients desire. This limitation may be
+avoided by marking the call site as âreadonlyâ. In the future we may
+also allow meta-data to be added to the intrinsic call to express
+aliasing, thereby allowing optimizations to hoist certain loads above
+stack maps.</p>
+<div class="section" id="direct-stack-map-entries">
+<h3><a class="toc-backref" href="#id13">Direct Stack Map Entries</a><a class="headerlink" href="#direct-stack-map-entries" title="Permalink to this headline">¶</a></h3>
+<p>As shown in <a class="reference internal" href="#stackmap-section"><span class="std std-ref">Stack Map Section</span></a>, a Direct stack map location
+records the address of frame index. This address is itself the value
+that the runtime requested. This differs from Indirect locations,
+which refer to a stack locations from which the requested values must
+be loaded. Direct locations can communicate the address if an alloca,
+while Indirect locations handle register spills.</p>
+<p>For example:</p>
+<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>entry:
+ %a = alloca i64...
+ llvm.experimental.stackmap(i64 <ID>, i32 <shadowBytes>, i64* %a)
+</pre></div>
+</div>
+<p>The runtime can determine this allocaâs relative location on the
+stack immediately after compilation, or at any time thereafter. This
+differs from Register and Indirect locations, because the runtime can
+only read the values in those locations when execution reaches the
+instruction address of the stack map.</p>
+<p>This functionality requires LLVM to treat entry-block allocas
+specially when they are directly consumed by an intrinsics. (This is
+the same requirement imposed by the llvm.gcroot intrinsic.) LLVM
+transformations must not substitute the alloca with any intervening
+value. This can be verified by the runtime simply by checking that the
+stack mapâs location is a Direct location type.</p>
+</div>
+</div>
+<div class="section" id="supported-architectures">
+<h2><a class="toc-backref" href="#id14">Supported Architectures</a><a class="headerlink" href="#supported-architectures" title="Permalink to this headline">¶</a></h2>
+<p>Support for StackMap generation and the related intrinsics requires
+some code for each backend. Today, only a subset of LLVMâs backends
+are supported. The currently supported architectures are X86_64,
+PowerPC, and Aarch64.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="InAlloca.html" title="Design and Usage of the InAlloca Attribute"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="AMDGPUInstructionNotation.html" title="AMDGPU Instructions Notation"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/StackSafetyAnalysis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/StackSafetyAnalysis.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/StackSafetyAnalysis.html (added)
+++ www-releases/trunk/9.0.0/docs/StackSafetyAnalysis.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,131 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Stack Safety Analysis — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Contributing to LLVM" href="Contributing.html" />
+ <link rel="prev" title="Speculative Load Hardening" href="SpeculativeLoadHardening.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" role="navigation" aria-label="related navigation">
+ <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="SpeculativeLoadHardening.html" title="Speculative Load Hardening"
+ 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" role="main">
+
+ <div class="section" id="stack-safety-analysis">
+<h1>Stack Safety Analysis<a class="headerlink" href="#stack-safety-analysis" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction">
+<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The Stack Safety Analysis determines if stack allocated variables can be
+considered âsafeâ from memory access bugs.</p>
+<p>The primary purpose of the analysis is to be used by sanitizers to avoid
+unnecessary instrumentation of âsafeâ variables. SafeStack is going to be the
+first user.</p>
+<p>âsafeâ variables can be defined as variables that can not be used out-of-scope
+(e.g. use-after-return) or accessed out of bounds. In the future it can be
+extended to track other variable properties. E.g. we plan to extend
+implementation with a check to make sure that variable is always initialized
+before every read to optimize use-of-uninitialized-memory checks.</p>
+</div>
+<div class="section" id="how-it-works">
+<h2>How it works<a class="headerlink" href="#how-it-works" title="Permalink to this headline">¶</a></h2>
+<p>The analysis is implemented in two stages:</p>
+<p>The intra-procedural, or âlocalâ, stage performs a depth-first search inside
+functions to collect all uses of each alloca, including loads/stores and uses as
+arguments functions. After this stage we know which parts of the alloca are used
+by functions itself but we donât know what happens after it is passed as
+an argument to another function.</p>
+<p>The inter-procedural, or âglobalâ, stage, resolves what happens to allocas after
+they are passed as function arguments. This stage performs a depth-first search
+on function calls inside a single module and propagates allocas usage through
+functions calls.</p>
+<p>When used with ThinLTO, the global stage performs a whole program analysis over
+the Module Summary Index.</p>
+</div>
+<div class="section" id="testing">
+<h2>Testing<a class="headerlink" href="#testing" title="Permalink to this headline">¶</a></h2>
+<p>The analysis is covered with lit tests.</p>
+<p>We expect that users can tolerate false classification of variables as
+âunsafeâ when in-fact itâs âsafeâ. This may lead to inefficient code. However, we
+canât accept false âsafeâ classification which may cause sanitizers to miss actual
+bugs in instrumented code. To avoid that we want additional validation tool.</p>
+<p>AddressSanitizer may help with this validation. We can instrument all variables
+as usual but additionally store stack-safe information in the
+<code class="docutils literal notranslate"><span class="pre">ASanStackVariableDescription</span></code>. Then if AddressSanitizer detects a bug on
+a âsafeâ variable we can produce an additional report to let the user know that
+probably Stack Safety Analysis failed and we should check for a bug in the
+compiler.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="SpeculativeLoadHardening.html" title="Speculative Load Hardening"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/Statepoints.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/Statepoints.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/Statepoints.html (added)
+++ www-releases/trunk/9.0.0/docs/Statepoints.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,978 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Garbage Collection Safepoints in LLVM — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="MergeFunctions pass, how it works" href="MergeFunctions.html" />
+ <link rel="prev" title="LLVM Code Coverage Mapping Format" href="CoverageMappingFormat.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" role="navigation" aria-label="related navigation">
+ <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="MergeFunctions.html" title="MergeFunctions pass, how it works"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="CoverageMappingFormat.html" title="LLVM Code Coverage Mapping 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" role="main">
+
+ <div class="section" id="garbage-collection-safepoints-in-llvm">
+<h1>Garbage Collection Safepoints in LLVM<a class="headerlink" href="#garbage-collection-safepoints-in-llvm" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#status" id="id11">Status</a></li>
+<li><a class="reference internal" href="#overview-core-concepts" id="id12">Overview & Core Concepts</a><ul>
+<li><a class="reference internal" href="#abstract-machine-model" id="id13">Abstract Machine Model</a></li>
+<li><a class="reference internal" href="#explicit-representation" id="id14">Explicit Representation</a></li>
+<li><a class="reference internal" href="#simplifications-for-non-relocating-gcs" id="id15">Simplifications for Non-Relocating GCs</a></li>
+<li><a class="reference internal" href="#recording-on-stack-regions" id="id16">Recording On Stack Regions</a></li>
+<li><a class="reference internal" href="#base-derived-pointers" id="id17">Base & Derived Pointers</a></li>
+<li><a class="reference internal" href="#gc-transitions" id="id18">GC Transitions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#intrinsics" id="id19">Intrinsics</a><ul>
+<li><a class="reference internal" href="#llvm-experimental-gc-statepoint-intrinsic" id="id20">âllvm.experimental.gc.statepointâ Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-gc-result-intrinsic" id="id21">âllvm.experimental.gc.resultâ Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-gc-relocate-intrinsic" id="id22">âllvm.experimental.gc.relocateâ Intrinsic</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#stack-map-format" id="id23">Stack Map Format</a></li>
+<li><a class="reference internal" href="#safepoint-semantics-verification" id="id24">Safepoint Semantics & Verification</a></li>
+<li><a class="reference internal" href="#utility-passes-for-safepoint-insertion" id="id25">Utility Passes for Safepoint Insertion</a><ul>
+<li><a class="reference internal" href="#rewritestatepointsforgc" id="id26">RewriteStatepointsForGC</a></li>
+<li><a class="reference internal" href="#placesafepoints" id="id27">PlaceSafepoints</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#supported-architectures" id="id28">Supported Architectures</a></li>
+<li><a class="reference internal" href="#limitations-and-half-baked-ideas" id="id29">Limitations and Half Baked Ideas</a><ul>
+<li><a class="reference internal" href="#mixing-references-and-raw-pointers" id="id30">Mixing References and Raw Pointers</a></li>
+<li><a class="reference internal" href="#objects-on-the-stack" id="id31">Objects on the Stack</a></li>
+<li><a class="reference internal" href="#lowering-quality-and-representation-overhead" id="id32">Lowering Quality and Representation Overhead</a></li>
+<li><a class="reference internal" href="#relocations-along-exceptional-edges" id="id33">Relocations Along Exceptional Edges</a></li>
+<li><a class="reference internal" href="#support-for-alternate-stackmap-formats" id="id34">Support for alternate stackmap formats</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#bugs-and-enhancements" id="id35">Bugs and Enhancements</a></li>
+</ul>
+</div>
+<div class="section" id="status">
+<h2><a class="toc-backref" href="#id11">Status</a><a class="headerlink" href="#status" title="Permalink to this headline">¶</a></h2>
+<p>This document describes a set of extensions to LLVM to support garbage
+collection. By now, these mechanisms are well proven with commercial java
+implementation with a fully relocating collector having shipped using them.
+There are a couple places where bugs might still linger; these are called out
+below.</p>
+<p>They are still listed as âexperimentalâ to indicate that no forward or backward
+compatibility guarantees are offered across versions. If your use case is such
+that you need some form of forward compatibility guarantee, please raise the
+issue on the llvm-dev mailing list.</p>
+<p>LLVM still supports an alternate mechanism for conservative garbage collection
+support using the <code class="docutils literal notranslate"><span class="pre">gcroot</span></code> intrinsic. The <code class="docutils literal notranslate"><span class="pre">gcroot</span></code> mechanism is mostly of
+historical interest at this point with one exception - its implementation of
+shadow stacks has been used successfully by a number of language frontends and
+is still supported.</p>
+</div>
+<div class="section" id="overview-core-concepts">
+<h2><a class="toc-backref" href="#id12">Overview & Core Concepts</a><a class="headerlink" href="#overview-core-concepts" title="Permalink to this headline">¶</a></h2>
+<p>To collect dead objects, garbage collectors must be able to identify
+any references to objects contained within executing code, and,
+depending on the collector, potentially update them. The collector
+does not need this information at all points in code - that would make
+the problem much harder - but only at well-defined points in the
+execution known as âsafepointsâ For most collectors, it is sufficient
+to track at least one copy of each unique pointer value. However, for
+a collector which wishes to relocate objects directly reachable from
+running code, a higher standard is required.</p>
+<p>One additional challenge is that the compiler may compute intermediate
+results (âderived pointersâ) which point outside of the allocation or
+even into the middle of another allocation. The eventual use of this
+intermediate value must yield an address within the bounds of the
+allocation, but such âexterior derived pointersâ may be visible to the
+collector. Given this, a garbage collector can not safely rely on the
+runtime value of an address to indicate the object it is associated
+with. If the garbage collector wishes to move any object, the
+compiler must provide a mapping, for each pointer, to an indication of
+its allocation.</p>
+<p>To simplify the interaction between a collector and the compiled code,
+most garbage collectors are organized in terms of three abstractions:
+load barriers, store barriers, and safepoints.</p>
+<ol class="arabic simple">
+<li>A load barrier is a bit of code executed immediately after the
+machine load instruction, but before any use of the value loaded.
+Depending on the collector, such a barrier may be needed for all
+loads, merely loads of a particular type (in the original source
+language), or none at all.</li>
+<li>Analogously, a store barrier is a code fragment that runs
+immediately before the machine store instruction, but after the
+computation of the value stored. The most common use of a store
+barrier is to update a âcard tableâ in a generational garbage
+collector.</li>
+<li>A safepoint is a location at which pointers visible to the compiled
+code (i.e. currently in registers or on the stack) are allowed to
+change. After the safepoint completes, the actual pointer value
+may differ, but the âobjectâ (as seen by the source language)
+pointed to will not.</li>
+</ol>
+<blockquote>
+<div>Note that the term âsafepointâ is somewhat overloaded. It refers to
+both the location at which the machine state is parsable and the
+coordination protocol involved in bring application threads to a
+point at which the collector can safely use that information. The
+term âstatepointâ as used in this document refers exclusively to the
+former.</div></blockquote>
+<p>This document focuses on the last item - compiler support for
+safepoints in generated code. We will assume that an outside
+mechanism has decided where to place safepoints. From our
+perspective, all safepoints will be function calls. To support
+relocation of objects directly reachable from values in compiled code,
+the collector must be able to:</p>
+<ol class="arabic simple">
+<li>identify every copy of a pointer (including copies introduced by
+the compiler itself) at the safepoint,</li>
+<li>identify which object each pointer relates to, and</li>
+<li>potentially update each of those copies.</li>
+</ol>
+<p>This document describes the mechanism by which an LLVM based compiler
+can provide this information to a language runtime/collector, and
+ensure that all pointers can be read and updated if desired.</p>
+<div class="section" id="abstract-machine-model">
+<h3><a class="toc-backref" href="#id13">Abstract Machine Model</a><a class="headerlink" href="#abstract-machine-model" title="Permalink to this headline">¶</a></h3>
+<p>At a high level, LLVM has been extended to support compiling to an abstract
+machine which extends the actual target with a non-integral pointer type
+suitable for representing a garbage collected reference to an object. In
+particular, such non-integral pointer type have no defined mapping to an
+integer representation. This semantic quirk allows the runtime to pick a
+integer mapping for each point in the program allowing relocations of objects
+without visible effects.</p>
+<p>This high level abstract machine model is used for most of the optimizer. As
+a result, transform passes do not need to be extended to look through explicit
+relocation sequence. Before starting code generation, we switch
+representations to an explicit form. The exact location chosen for lowering
+is an implementation detail.</p>
+<p>Note that most of the value of the abstract machine model comes for collectors
+which need to model potentially relocatable objects. For a compiler which
+supports only a non-relocating collector, you may wish to consider starting
+with the fully explicit form.</p>
+<p>Warning: There is one currently known semantic hole in the definition of
+non-integral pointers which has not been addressed upstream. To work around
+this, you need to disable speculation of loads unless the memory type
+(non-integral pointer vs anything else) is known to unchanged. That is, it is
+not safe to speculate a load if doing causes a non-integral pointer value to
+be loaded as any other type or vice versa. In practice, this restriction is
+well isolated to isSafeToSpeculate in ValueTracking.cpp.</p>
+</div>
+<div class="section" id="explicit-representation">
+<h3><a class="toc-backref" href="#id14">Explicit Representation</a><a class="headerlink" href="#explicit-representation" title="Permalink to this headline">¶</a></h3>
+<p>A frontend could directly generate this low level explicit form, but
+doing so may inhibit optimization. Instead, it is recommended that
+compilers with relocating collectors target the abstract machine model just
+described.</p>
+<p>The heart of the explicit approach is to construct (or rewrite) the IR in a
+manner where the possible updates performed by the garbage collector are
+explicitly visible in the IR. Doing so requires that we:</p>
+<ol class="arabic simple">
+<li>create a new SSA value for each potentially relocated pointer, and
+ensure that no uses of the original (non relocated) value is
+reachable after the safepoint,</li>
+<li>specify the relocation in a way which is opaque to the compiler to
+ensure that the optimizer can not introduce new uses of an
+unrelocated value after a statepoint. This prevents the optimizer
+from performing unsound optimizations.</li>
+<li>recording a mapping of live pointers (and the allocation theyâre
+associated with) for each statepoint.</li>
+</ol>
+<p>At the most abstract level, inserting a safepoint can be thought of as
+replacing a call instruction with a call to a multiple return value
+function which both calls the original target of the call, returns
+its result, and returns updated values for any live pointers to
+garbage collected objects.</p>
+<blockquote>
+<div>Note that the task of identifying all live pointers to garbage
+collected values, transforming the IR to expose a pointer giving the
+base object for every such live pointer, and inserting all the
+intrinsics correctly is explicitly out of scope for this document.
+The recommended approach is to use the <a class="reference internal" href="#statepoint-utilities"><span class="std std-ref">utility passes</span></a> described below.</div></blockquote>
+<p>This abstract function call is concretely represented by a sequence of
+intrinsic calls known collectively as a âstatepoint relocation sequenceâ.</p>
+<p>Letâs consider a simple call in LLVM IR:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</span><span class="p">()</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Depending on our language we may need to allow a safepoint during the execution
+of <code class="docutils literal notranslate"><span class="pre">foo</span></code>. If so, we need to let the collector update local values in the
+current frame. If we donât, weâll be accessing a potential invalid reference
+once we eventually return from the call.</p>
+<p>In this example, we need to relocate the SSA value <code class="docutils literal notranslate"><span class="pre">%obj</span></code>. Since we canât
+actually change the value in the SSA value <code class="docutils literal notranslate"><span class="pre">%obj</span></code>, we need to introduce a new
+SSA value <code class="docutils literal notranslate"><span class="pre">%obj.relocated</span></code> which represents the potentially changed value of
+<code class="docutils literal notranslate"><span class="pre">%obj</span></code> after the safepoint and update any following uses appropriately. The
+resulting relocation sequence is:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="nv nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">call</span> <span class="kt">token</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="kt">void</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="p">...)*</span> <span class="vg">@llvm.experimental.gc.statepoint.p0f_isVoidf</span><span class="p">(</span><span class="k">i64</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</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">0</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">0</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="nv">%obj.relocated</span> <span class="p">=</span> <span class="k">call</span> <span class="k">coldcc</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@llvm.experimental.gc.relocate.p1i8</span><span class="p">(</span><span class="kt">token</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj.relocated</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Ideally, this sequence would have been represented as a M argument, N
+return value function (where M is the number of values being
+relocated + the original call arguments and N is the original return
+value + each relocated value), but LLVM does not easily support such a
+representation.</p>
+<p>Instead, the statepoint intrinsic marks the actual site of the
+safepoint or statepoint. The statepoint returns a token value (which
+exists only at compile time). To get back the original return value
+of the call, we use the <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> intrinsic. To get the relocation
+of each pointer in turn, we use the <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> intrinsic with the
+appropriate index. Note that both the <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> and <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> are
+tied to the statepoint. The combination forms a âstatepoint relocation
+sequenceâ and represents the entirety of a parseable call or âstatepointâ.</p>
+<p>When lowered, this example would generate the following x86 assembly:</p>
+<div class="highlight-gas notranslate"><div class="highlight"><pre><span></span> <span class="na">.globl</span> <span class="no">test1</span>
+ <span class="na">.align</span> <span class="mi">16</span><span class="p">,</span> <span class="mi">0x90</span>
+ <span class="nf">pushq</span> <span class="nv">%rax</span>
+ <span class="nf">callq</span> <span class="no">foo</span>
+<span class="nl">.Ltmp1:</span>
+ <span class="nf">movq</span> <span class="p">(</span><span class="nv">%rsp</span><span class="p">),</span> <span class="nv">%rax</span> <span class="c"># This load is redundant (oops!)</span>
+ <span class="nf">popq</span> <span class="nv">%rdx</span>
+ <span class="nf">retq</span>
+</pre></div>
+</div>
+<p>Each of the potentially relocated values has been spilled to the
+stack, and a record of that location has been recorded to the
+<a class="reference internal" href="StackMaps.html#stackmap-section"><span class="std std-ref">Stack Map section</span></a>. If the garbage collector
+needs to update any of these pointers during the call, it knows
+exactly what to change.</p>
+<p>The relevant parts of the StackMap section for our example are:</p>
+<div class="highlight-gas notranslate"><div class="highlight"><pre><span></span><span class="c"># This describes the call site</span>
+<span class="c"># Stack Maps: callsite 2882400000</span>
+ <span class="na">.quad</span> <span class="mi">2882400000</span>
+ <span class="na">.long</span> <span class="no">.Ltmp1-test1</span>
+ <span class="na">.short</span> <span class="mi">0</span>
+<span class="c"># .. 8 entries skipped ..</span>
+<span class="c"># This entry describes the spill slot which is directly addressable</span>
+<span class="c"># off RSP with offset 0. Given the value was spilled with a pushq,</span>
+<span class="c"># that makes sense.</span>
+<span class="c"># Stack Maps: Loc 8: Direct RSP [encoding: .byte 2, .byte 8, .short 7, .int 0]</span>
+ <span class="na">.byte</span> <span class="mi">2</span>
+ <span class="na">.byte</span> <span class="mi">8</span>
+ <span class="na">.short</span> <span class="mi">7</span>
+ <span class="na">.long</span> <span class="mi">0</span>
+</pre></div>
+</div>
+<p>This example was taken from the tests for the <a class="reference internal" href="#rewritestatepointsforgc"><span class="std std-ref">RewriteStatepointsForGC</span></a>
+utility pass. As such, its full StackMap can be easily examined with the
+following command.</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>opt -rewrite-statepoints-for-gc test/Transforms/RewriteStatepointsForGC/basics.ll -S <span class="p">|</span> llc -debug-only<span class="o">=</span>stackmaps
+</pre></div>
+</div>
+</div>
+<div class="section" id="simplifications-for-non-relocating-gcs">
+<h3><a class="toc-backref" href="#id15">Simplifications for Non-Relocating GCs</a><a class="headerlink" href="#simplifications-for-non-relocating-gcs" title="Permalink to this headline">¶</a></h3>
+<p>Some of the complexity in the previous example is unnecessary for a
+non-relocating collector. While a non-relocating collector still needs the
+information about which location contain live references, it doesnât need to
+represent explicit relocations. As such, the previously described explicit
+lowering can be simplified to remove all of the <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> intrinsic
+calls and leave uses in terms of the original reference value.</p>
+<p>Hereâs the explicit lowering for the previous example for a non-relocating
+collector:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">token</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="kt">void</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="p">...)*</span> <span class="vg">@llvm.experimental.gc.statepoint.p0f_isVoidf</span><span class="p">(</span><span class="k">i64</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</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">0</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">0</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="recording-on-stack-regions">
+<h3><a class="toc-backref" href="#id16">Recording On Stack Regions</a><a class="headerlink" href="#recording-on-stack-regions" title="Permalink to this headline">¶</a></h3>
+<p>In addition to the explicit relocation form previously described, the
+statepoint infrastructure also allows the listing of allocas within the gc
+pointer list. Allocas can be listed with or without additional explicit gc
+pointer values and relocations.</p>
+<p>An alloca in the gc region of the statepoint operand list will cause the
+address of the stack region to be listed in the stackmap for the statepoint.</p>
+<p>This mechanism can be used to describe explicit spill slots if desired. It
+then becomes the generatorâs responsibility to ensure that values are
+spill/filled to/from the alloca as needed on either side of the safepoint.
+Note that there is no way to indicate a corresponding base pointer for such
+an explicitly specified spill slot, so usage is restricted to values for
+which the associated collector can derive the object base from the pointer
+itself.</p>
+<p>This mechanism can be used to describe on stack objects containing
+references provided that the collector can map from the location on the
+stack to a heap map describing the internal layout of the references the
+collector needs to process.</p>
+<p>WARNING: At the moment, this alternate form is not well exercised. It is
+recommended to use this with caution and expect to have to fix a few bugs.
+In particular, the RewriteStatepointsForGC utility pass does not do
+anything for allocas today.</p>
+</div>
+<div class="section" id="base-derived-pointers">
+<h3><a class="toc-backref" href="#id17">Base & Derived Pointers</a><a class="headerlink" href="#base-derived-pointers" title="Permalink to this headline">¶</a></h3>
+<p>A âbase pointerâ is one which points to the starting address of an allocation
+(object). A âderived pointerâ is one which is offset from a base pointer by
+some amount. When relocating objects, a garbage collector needs to be able
+to relocate each derived pointer associated with an allocation to the same
+offset from the new address.</p>
+<p>âInterior derived pointersâ remain within the bounds of the allocation
+theyâre associated with. As a result, the base object can be found at
+runtime provided the bounds of allocations are known to the runtime system.</p>
+<p>âExterior derived pointersâ are outside the bounds of the associated object;
+they may even fall within <em>another</em> allocations address range. As a result,
+there is no way for a garbage collector to determine which allocation they
+are associated with at runtime and compiler support is needed.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> intrinsic supports an explicit operand for describing the
+allocation associated with a derived pointer. This operand is frequently
+referred to as the base operand, but does not strictly speaking have to be
+a base pointer, but it does need to lie within the bounds of the associated
+allocation. Some collectors may require that the operand be an actual base
+pointer rather than merely an internal derived pointer. Note that during
+lowering both the base and derived pointer operands are required to be live
+over the associated call safepoint even if the base is otherwise unused
+afterwards.</p>
+<p>If we extend our previous example to include a pointless derived pointer,
+we get:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="nv">%gep</span> <span class="p">=</span> <span class="k">getelementptr</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">,</span> <span class="k">i64</span> <span class="m">20000</span>
+ <span class="nv">%token</span> <span class="p">=</span> <span class="k">call</span> <span class="kt">token</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="kt">void</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="p">...)*</span> <span class="vg">@llvm.experimental.gc.statepoint.p0f_isVoidf</span><span class="p">(</span><span class="k">i64</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</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">0</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">0</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%gep</span><span class="p">)</span>
+ <span class="nv">%obj.relocated</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@llvm.experimental.gc.relocate.p1i8</span><span class="p">(</span><span class="kt">token</span> <span class="nv">%token</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">)</span>
+ <span class="nv">%gep.relocated</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@llvm.experimental.gc.relocate.p1i8</span><span class="p">(</span><span class="kt">token</span> <span class="nv">%token</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">,</span> <span class="k">i32</span> <span class="m">8</span><span class="p">)</span>
+ <span class="nv">%p</span> <span class="p">=</span> <span class="k">getelementptr</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%gep</span><span class="p">,</span> <span class="k">i64</span> <span class="m">-20000</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%p</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Note that in this example %p and %obj.relocate are the same address and we
+could replace one with the other, potentially removing the derived pointer
+from the live set at the safepoint entirely.</p>
+</div>
+<div class="section" id="gc-transitions">
+<span id="gc-transition-args"></span><h3><a class="toc-backref" href="#id18">GC Transitions</a><a class="headerlink" href="#gc-transitions" title="Permalink to this headline">¶</a></h3>
+<p>As a practical consideration, many garbage-collected systems allow code that is
+collector-aware (âmanaged codeâ) to call code that is not collector-aware
+(âunmanaged codeâ). It is common that such calls must also be safepoints, since
+it is desirable to allow the collector to run during the execution of
+unmanaged code. Furthermore, it is common that coordinating the transition from
+managed to unmanaged code requires extra code generation at the call site to
+inform the collector of the transition. In order to support these needs, a
+statepoint may be marked as a GC transition, and data that is necessary to
+perform the transition (if any) may be provided as additional arguments to the
+statepoint.</p>
+<blockquote>
+<div>Note that although in many cases statepoints may be inferred to be GC
+transitions based on the function symbols involved (e.g. a call from a
+function with GC strategy âfooâ to a function with GC strategy âbarâ),
+indirect calls that are also GC transitions must also be supported. This
+requirement is the driving force behind the decision to require that GC
+transitions are explicitly marked.</div></blockquote>
+<p>Letâs revisit the sample given above, this time treating the call to <code class="docutils literal notranslate"><span class="pre">@foo</span></code>
+as a GC transition. Depending on our target, the transition code may need to
+access some extra state in order to inform the collector of the transition.
+Letâs assume a hypothetical GCâsomewhat unimaginatively named âhypothetical-gcâ
+âthat requires that a TLS variable must be written to before and after a call
+to unmanaged code. The resulting relocation sequence is:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="vg">@flag</span> <span class="p">=</span> <span class="k">thread_local</span> <span class="k">global</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="k">align</span> <span class="m">4</span>
+
+<span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)</span> <span class="p">*</span><span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"hypothetical-gc"</span> <span class="p">{</span>
+
+ <span class="nv nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">call</span> <span class="kt">token</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="kt">void</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="p">...)*</span> <span class="vg">@llvm.experimental.gc.statepoint.p0f_isVoidf</span><span class="p">(</span><span class="k">i64</span> <span class="m">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</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">1</span><span class="p">,</span> <span class="k">i32</span><span class="p">*</span> <span class="vg">@Flag</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="nv">%obj.relocated</span> <span class="p">=</span> <span class="k">call</span> <span class="k">coldcc</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@llvm.experimental.gc.relocate.p1i8</span><span class="p">(</span><span class="kt">token</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">,</span> <span class="k">i32</span> <span class="m">7</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj.relocated</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>During lowering, this will result in a instruction selection DAG that looks
+something like:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">CALLSEQ_START</span>
+<span class="o">...</span>
+<span class="n">GC_TRANSITION_START</span> <span class="p">(</span><span class="n">lowered</span> <span class="n">i32</span> <span class="o">*</span><span class="nd">@Flag</span><span class="p">),</span> <span class="n">SRCVALUE</span> <span class="n">i32</span><span class="o">*</span> <span class="n">Flag</span>
+<span class="n">STATEPOINT</span>
+<span class="n">GC_TRANSITION_END</span> <span class="p">(</span><span class="n">lowered</span> <span class="n">i32</span> <span class="o">*</span><span class="nd">@Flag</span><span class="p">),</span> <span class="n">SRCVALUE</span> <span class="n">i32</span> <span class="o">*</span><span class="n">Flag</span>
+<span class="o">...</span>
+<span class="n">CALLSEQ_END</span>
+</pre></div>
+</div>
+<p>In order to generate the necessary transition code, the backend for each target
+supported by âhypothetical-gcâ must be modified to lower <code class="docutils literal notranslate"><span class="pre">GC_TRANSITION_START</span></code>
+and <code class="docutils literal notranslate"><span class="pre">GC_TRANSITION_END</span></code> nodes appropriately when the âhypothetical-gcâ
+strategy is in use for a particular function. Assuming that such lowering has
+been added for X86, the generated assembly would be:</p>
+<div class="highlight-gas notranslate"><div class="highlight"><pre><span></span> <span class="na">.globl</span> <span class="no">test1</span>
+ <span class="na">.align</span> <span class="mi">16</span><span class="p">,</span> <span class="mi">0x90</span>
+ <span class="nf">pushq</span> <span class="nv">%rax</span>
+ <span class="nf">movl</span> <span class="no">$1</span><span class="p">,</span> <span class="nv">%fs</span><span class="p">:</span><span class="no">Flag at TPOFF</span>
+ <span class="nf">callq</span> <span class="no">foo</span>
+ <span class="nf">movl</span> <span class="no">$0</span><span class="p">,</span> <span class="nv">%fs</span><span class="p">:</span><span class="no">Flag at TPOFF</span>
+<span class="nl">.Ltmp1:</span>
+ <span class="nf">movq</span> <span class="p">(</span><span class="nv">%rsp</span><span class="p">),</span> <span class="nv">%rax</span> <span class="c"># This load is redundant (oops!)</span>
+ <span class="nf">popq</span> <span class="nv">%rdx</span>
+ <span class="nf">retq</span>
+</pre></div>
+</div>
+<p>Note that the design as presented above is not fully implemented: in particular,
+strategy-specific lowering is not present, and all GC transitions are emitted as
+as single no-op before and after the call instruction. These no-ops are often
+removed by the backend during dead machine instruction elimination.</p>
+</div>
+</div>
+<div class="section" id="intrinsics">
+<h2><a class="toc-backref" href="#id19">Intrinsics</a><a class="headerlink" href="#intrinsics" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="llvm-experimental-gc-statepoint-intrinsic">
+<h3><a class="toc-backref" href="#id20">âllvm.experimental.gc.statepointâ Intrinsic</a><a class="headerlink" href="#llvm-experimental-gc-statepoint-intrinsic" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="syntax">
+<h4>Syntax:<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">declare</span> <span class="n">token</span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">gc</span><span class="o">.</span><span class="n">statepoint</span><span class="p">(</span><span class="n">i64</span> <span class="o"><</span><span class="nb">id</span><span class="o">></span><span class="p">,</span> <span class="n">i32</span> <span class="o"><</span><span class="n">num</span> <span class="n">patch</span> <span class="nb">bytes</span><span class="o">></span><span class="p">,</span>
+ <span class="n">func_type</span> <span class="o"><</span><span class="n">target</span><span class="o">></span><span class="p">,</span>
+ <span class="n">i64</span> <span class="o"><</span><span class="c1">#call args>, i64 <flags>,</span>
+ <span class="o">...</span> <span class="p">(</span><span class="n">call</span> <span class="n">parameters</span><span class="p">),</span>
+ <span class="n">i64</span> <span class="o"><</span><span class="c1"># transition args>, ... (transition parameters),</span>
+ <span class="n">i64</span> <span class="o"><</span><span class="c1"># deopt args>, ... (deopt parameters),</span>
+ <span class="o">...</span> <span class="p">(</span><span class="n">gc</span> <span class="n">parameters</span><span class="p">))</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="overview">
+<h4>Overview:<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h4>
+<p>The statepoint intrinsic represents a call which is parse-able by the
+runtime.</p>
+</div>
+<div class="section" id="operands">
+<h4>Operands:<a class="headerlink" href="#operands" title="Permalink to this headline">¶</a></h4>
+<p>The âidâ operand is a constant integer that is reported as the ID
+field in the generated stackmap. LLVM does not interpret this
+parameter in any way and its meaning is up to the statepoint user to
+decide. Note that LLVM is free to duplicate code containing
+statepoint calls, and this may transform IR that had a unique âidâ per
+lexical call to statepoint to IR that does not.</p>
+<p>If ânum patch bytesâ is non-zero then the call instruction
+corresponding to the statepoint is not emitted and LLVM emits ânum
+patch bytesâ bytes of nops in its place. LLVM will emit code to
+prepare the function arguments and retrieve the function return value
+in accordance to the calling convention; the former before the nop
+sequence and the latter after the nop sequence. It is expected that
+the user will patch over the ânum patch bytesâ bytes of nops with a
+calling sequence specific to their runtime before executing the
+generated machine code. There are no guarantees with respect to the
+alignment of the nop sequence. Unlike <a class="reference internal" href="StackMaps.html"><span class="doc">Stack maps and patch points in LLVM</span></a> statepoints do
+not have a concept of shadow bytes. Note that semantically the
+statepoint still represents a call or invoke to âtargetâ, and the nop
+sequence after patching is expected to represent an operation
+equivalent to a call or invoke to âtargetâ.</p>
+<p>The âtargetâ operand is the function actually being called. The
+target can be specified as either a symbolic LLVM function, or as an
+arbitrary Value of appropriate function type. Note that the function
+type must match the signature of the callee and the types of the âcall
+parametersâ arguments.</p>
+<p>The â#call argsâ operand is the number of arguments to the actual
+call. It must exactly match the number of arguments passed in the
+âcall parametersâ variable length section.</p>
+<p>The âflagsâ operand is used to specify extra information about the
+statepoint. This is currently only used to mark certain statepoints
+as GC transitions. This operand is a 64-bit integer with the following
+layout, where bit 0 is the least significant bit:</p>
+<blockquote>
+<div><table border="1" class="docutils">
+<colgroup>
+<col width="12%" />
+<col width="88%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Bit #</th>
+<th class="head">Usage</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>Set if the statepoint is a GC transition, cleared
+otherwise.</td>
+</tr>
+<tr class="row-odd"><td>1-63</td>
+<td>Reserved for future use; must be cleared.</td>
+</tr>
+</tbody>
+</table>
+</div></blockquote>
+<p>The âcall parametersâ arguments are simply the arguments which need to
+be passed to the call target. They will be lowered according to the
+specified calling convention and otherwise handled like a normal call
+instruction. The number of arguments must exactly match what is
+specified in â# call argsâ. The types must match the signature of
+âtargetâ.</p>
+<p>The âtransition parametersâ arguments contain an arbitrary list of
+Values which need to be passed to GC transition code. They will be
+lowered and passed as operands to the appropriate GC_TRANSITION nodes
+in the selection DAG. It is assumed that these arguments must be
+available before and after (but not necessarily during) the execution
+of the callee. The â# transition argsâ field indicates how many operands
+are to be interpreted as âtransition parametersâ.</p>
+<p>The âdeopt parametersâ arguments contain an arbitrary list of Values
+which is meaningful to the runtime. The runtime may read any of these
+values, but is assumed not to modify them. If the garbage collector
+might need to modify one of these values, it must also be listed in
+the âgc pointerâ argument list. The â# deopt argsâ field indicates
+how many operands are to be interpreted as âdeopt parametersâ.</p>
+<p>The âgc parametersâ arguments contain every pointer to a garbage
+collector object which potentially needs to be updated by the garbage
+collector. Note that the argument list must explicitly contain a base
+pointer for every derived pointer listed. The order of arguments is
+unimportant. Unlike the other variable length parameter sets, this
+list is not length prefixed.</p>
+</div>
+<div class="section" id="semantics">
+<h4>Semantics:<a class="headerlink" href="#semantics" title="Permalink to this headline">¶</a></h4>
+<p>A statepoint is assumed to read and write all memory. As a result,
+memory operations can not be reordered past a statepoint. It is
+illegal to mark a statepoint as being either âreadonlyâ or âreadnoneâ.</p>
+<p>Note that legal IR can not perform any memory operation on a âgc
+pointerâ argument of the statepoint in a location statically reachable
+from the statepoint. Instead, the explicitly relocated value (from a
+<code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code>) must be used.</p>
+</div>
+</div>
+<div class="section" id="llvm-experimental-gc-result-intrinsic">
+<h3><a class="toc-backref" href="#id21">âllvm.experimental.gc.resultâ Intrinsic</a><a class="headerlink" href="#llvm-experimental-gc-result-intrinsic" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id1">
+<h4>Syntax:<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">declare</span> <span class="nb">type</span><span class="o">*</span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">gc</span><span class="o">.</span><span class="n">result</span><span class="p">(</span><span class="n">token</span> <span class="o">%</span><span class="n">statepoint_token</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="id2">
+<h4>Overview:<a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h4>
+<p><code class="docutils literal notranslate"><span class="pre">gc.result</span></code> extracts the result of the original call instruction
+which was replaced by the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>. The <code class="docutils literal notranslate"><span class="pre">gc.result</span></code>
+intrinsic is actually a family of three intrinsics due to an
+implementation limitation. Other than the type of the return value,
+the semantics are the same.</p>
+</div>
+<div class="section" id="id3">
+<h4>Operands:<a class="headerlink" href="#id3" title="Permalink to this headline">¶</a></h4>
+<p>The first and only argument is the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> which starts
+the safepoint sequence of which this <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> is a part.
+Despite the typing of this as a generic token, <em>only</em> the value defined
+by a <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> is legal here.</p>
+</div>
+<div class="section" id="id4">
+<h4>Semantics:<a class="headerlink" href="#id4" title="Permalink to this headline">¶</a></h4>
+<p>The <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> represents the return value of the call target of
+the <code class="docutils literal notranslate"><span class="pre">statepoint</span></code>. The type of the <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> must exactly match
+the type of the target. If the call target returns void, there will
+be no <code class="docutils literal notranslate"><span class="pre">gc.result</span></code>.</p>
+<p>A <code class="docutils literal notranslate"><span class="pre">gc.result</span></code> is modeled as a âreadnoneâ pure function. It has no
+side effects since it is just a projection of the return value of the
+previous call represented by the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>.</p>
+</div>
+</div>
+<div class="section" id="llvm-experimental-gc-relocate-intrinsic">
+<h3><a class="toc-backref" href="#id22">âllvm.experimental.gc.relocateâ Intrinsic</a><a class="headerlink" href="#llvm-experimental-gc-relocate-intrinsic" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id5">
+<h4>Syntax:<a class="headerlink" href="#id5" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">declare</span> <span class="o"><</span><span class="n">pointer</span> <span class="nb">type</span><span class="o">></span>
+ <span class="nd">@llvm</span><span class="o">.</span><span class="n">experimental</span><span class="o">.</span><span class="n">gc</span><span class="o">.</span><span class="n">relocate</span><span class="p">(</span><span class="n">token</span> <span class="o">%</span><span class="n">statepoint_token</span><span class="p">,</span>
+ <span class="n">i32</span> <span class="o">%</span><span class="n">base_offset</span><span class="p">,</span>
+ <span class="n">i32</span> <span class="o">%</span><span class="n">pointer_offset</span><span class="p">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="id6">
+<h4>Overview:<a class="headerlink" href="#id6" title="Permalink to this headline">¶</a></h4>
+<p>A <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> returns the potentially relocated value of a pointer
+at the safepoint.</p>
+</div>
+<div class="section" id="id7">
+<h4>Operands:<a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h4>
+<p>The first argument is the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> which starts the
+safepoint sequence of which this <code class="docutils literal notranslate"><span class="pre">gc.relocation</span></code> is a part.
+Despite the typing of this as a generic token, <em>only</em> the value defined
+by a <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> is legal here.</p>
+<p>The second argument is an index into the statepoints list of arguments
+which specifies the allocation for the pointer being relocated.
+This index must land within the âgc parameterâ section of the
+statepointâs argument list. The associated value must be within the
+object with which the pointer being relocated is associated. The optimizer
+is free to change <em>which</em> interior derived pointer is reported, provided that
+it does not replace an actual base pointer with another interior derived
+pointer. Collectors are allowed to rely on the base pointer operand
+remaining an actual base pointer if so constructed.</p>
+<p>The third argument is an index into the statepointâs list of arguments
+which specify the (potentially) derived pointer being relocated. It
+is legal for this index to be the same as the second argument
+if-and-only-if a base pointer is being relocated. This index must land
+within the âgc parameterâ section of the statepointâs argument list.</p>
+</div>
+<div class="section" id="id8">
+<h4>Semantics:<a class="headerlink" href="#id8" title="Permalink to this headline">¶</a></h4>
+<p>The return value of <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> is the potentially relocated value
+of the pointer specified by its arguments. It is unspecified how the
+value of the returned pointer relates to the argument to the
+<code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> other than that a) it points to the same source
+language object with the same offset, and b) the âbased-onâ
+relationship of the newly relocated pointers is a projection of the
+unrelocated pointers. In particular, the integer value of the pointer
+returned is unspecified.</p>
+<p>A <code class="docutils literal notranslate"><span class="pre">gc.relocate</span></code> is modeled as a <code class="docutils literal notranslate"><span class="pre">readnone</span></code> pure function. It has no
+side effects since it is just a way to extract information about work
+done during the actual call modeled by the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="stack-map-format">
+<span id="statepoint-stackmap-format"></span><h2><a class="toc-backref" href="#id23">Stack Map Format</a><a class="headerlink" href="#stack-map-format" title="Permalink to this headline">¶</a></h2>
+<p>Locations for each pointer value which may need read and/or updated by
+the runtime or collector are provided in a separate section of the
+generated object file as specified in the PatchPoint documentation.
+This special section is encoded per the
+<a class="reference internal" href="StackMaps.html#stackmap-format"><span class="std std-ref">Stack Map format</span></a>.</p>
+<p>The general expectation is that a JIT compiler will parse and discard this
+format; it is not particularly memory efficient. If you need an alternate
+format (e.g. for an ahead of time compiler), see discussion under
+:ref: <cite>open work items <OpenWork></cite> below.</p>
+<p>Each statepoint generates the following Locations:</p>
+<ul class="simple">
+<li>Constant which describes the calling convention of the call target. This
+constant is a valid <a class="reference internal" href="LangRef.html#callingconv"><span class="std std-ref">calling convention identifier</span></a> for
+the version of LLVM used to generate the stackmap. No additional compatibility
+guarantees are made for this constant over what LLVM provides elsewhere w.r.t.
+these identifiers.</li>
+<li>Constant which describes the flags passed to the statepoint intrinsic</li>
+<li>Constant which describes number of following deopt <em>Locations</em> (not
+operands)</li>
+<li>Variable number of Locations, one for each deopt parameter listed in
+the IR statepoint (same number as described by previous Constant). At
+the moment, only deopt parameters with a bitwidth of 64 bits or less
+are supported. Values of a type larger than 64 bits can be specified
+and reported only if a) the value is constant at the call site, and b)
+the constant can be represented with less than 64 bits (assuming zero
+extension to the original bitwidth).</li>
+<li>Variable number of relocation records, each of which consists of
+exactly two Locations. Relocation records are described in detail
+below.</li>
+</ul>
+<p>Each relocation record provides sufficient information for a collector to
+relocate one or more derived pointers. Each record consists of a pair of
+Locations. The second element in the record represents the pointer (or
+pointers) which need updated. The first element in the record provides a
+pointer to the base of the object with which the pointer(s) being relocated is
+associated. This information is required for handling generalized derived
+pointers since a pointer may be outside the bounds of the original allocation,
+but still needs to be relocated with the allocation. Additionally:</p>
+<ul class="simple">
+<li>It is guaranteed that the base pointer must also appear explicitly as a
+relocation pair if used after the statepoint.</li>
+<li>There may be fewer relocation records then gc parameters in the IR
+statepoint. Each <em>unique</em> pair will occur at least once; duplicates
+are possible.</li>
+<li>The Locations within each record may either be of pointer size or a
+multiple of pointer size. In the later case, the record must be
+interpreted as describing a sequence of pointers and their corresponding
+base pointers. If the Location is of size N x sizeof(pointer), then
+there will be N records of one pointer each contained within the Location.
+Both Locations in a pair can be assumed to be of the same size.</li>
+</ul>
+<p>Note that the Locations used in each section may describe the same
+physical location. e.g. A stack slot may appear as a deopt location,
+a gc base pointer, and a gc derived pointer.</p>
+<p>The LiveOut section of the StkMapRecord will be empty for a statepoint
+record.</p>
+</div>
+<div class="section" id="safepoint-semantics-verification">
+<h2><a class="toc-backref" href="#id24">Safepoint Semantics & Verification</a><a class="headerlink" href="#safepoint-semantics-verification" title="Permalink to this headline">¶</a></h2>
+<p>The fundamental correctness property for the compiled codeâs
+correctness w.r.t. the garbage collector is a dynamic one. It must be
+the case that there is no dynamic trace such that a operation
+involving a potentially relocated pointer is observably-after a
+safepoint which could relocate it. âobservably-afterâ is this usage
+means that an outside observer could observe this sequence of events
+in a way which precludes the operation being performed before the
+safepoint.</p>
+<p>To understand why this âobservable-afterâ property is required,
+consider a null comparison performed on the original copy of a
+relocated pointer. Assuming that control flow follows the safepoint,
+there is no way to observe externally whether the null comparison is
+performed before or after the safepoint. (Remember, the original
+Value is unmodified by the safepoint.) The compiler is free to make
+either scheduling choice.</p>
+<p>The actual correctness property implemented is slightly stronger than
+this. We require that there be no <em>static path</em> on which a
+potentially relocated pointer is âobservably-afterâ it may have been
+relocated. This is slightly stronger than is strictly necessary (and
+thus may disallow some otherwise valid programs), but greatly
+simplifies reasoning about correctness of the compiled code.</p>
+<p>By construction, this property will be upheld by the optimizer if
+correctly established in the source IR. This is a key invariant of
+the design.</p>
+<p>The existing IR Verifier pass has been extended to check most of the
+local restrictions on the intrinsics mentioned in their respective
+documentation. The current implementation in LLVM does not check the
+key relocation invariant, but this is ongoing work on developing such
+a verifier. Please ask on llvm-dev if youâre interested in
+experimenting with the current version.</p>
+</div>
+<div class="section" id="utility-passes-for-safepoint-insertion">
+<span id="statepoint-utilities"></span><h2><a class="toc-backref" href="#id25">Utility Passes for Safepoint Insertion</a><a class="headerlink" href="#utility-passes-for-safepoint-insertion" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="rewritestatepointsforgc">
+<span id="id9"></span><h3><a class="toc-backref" href="#id26">RewriteStatepointsForGC</a><a class="headerlink" href="#rewritestatepointsforgc" title="Permalink to this headline">¶</a></h3>
+<p>The pass RewriteStatepointsForGC transforms a functionâs IR to lower from the
+abstract machine model described above to the explicit statepoint model of
+relocations. To do this, it replaces all calls or invokes of functions which
+might contain a safepoint poll with a <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> and associated full
+relocation sequence, including all required <code class="docutils literal notranslate"><span class="pre">gc.relocates</span></code>.</p>
+<p>Note that by default, this pass only runs for the âstatepoint-exampleâ or
+âcore-clrâ gc strategies. You will need to add your custom strategy to this
+whitelist or use one of the predefined ones.</p>
+<p>As an example, given this code:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="vg">@foo</span><span class="p">()</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The pass would produce this IR:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@test1</span><span class="p">(</span><span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="nv nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">call</span> <span class="kt">token</span> <span class="p">(</span><span class="k">i64</span><span class="p">,</span> <span class="k">i32</span><span class="p">,</span> <span class="kt">void</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="p">...)*</span> <span class="vg">@llvm.experimental.gc.statepoint.p0f_isVoidf</span><span class="p">(</span><span class="k">i64</span> <span class="m">2882400000</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="kt">void</span> <span class="p">()*</span> <span class="vg">@foo</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">0</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">5</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">-1</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">0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj</span><span class="p">)</span>
+ <span class="nv">%obj.relocated</span> <span class="p">=</span> <span class="k">call</span> <span class="k">coldcc</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="vg">@llvm.experimental.gc.relocate.p1i8</span><span class="p">(</span><span class="kt">token</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i32</span> <span class="m">12</span><span class="p">,</span> <span class="k">i32</span> <span class="m">12</span><span class="p">)</span>
+ <span class="k">ret</span> <span class="k">i8</span> <span class="k">addrspace</span><span class="p">(</span><span class="m">1</span><span class="p">)*</span> <span class="nv">%obj.relocated</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In the above examples, the addrspace(1) marker on the pointers is the mechanism
+that the <code class="docutils literal notranslate"><span class="pre">statepoint-example</span></code> GC strategy uses to distinguish references from
+non references. The pass assumes that all addrspace(1) pointers are non-integral
+pointer types. Address space 1 is not globally reserved for this purpose.</p>
+<p>This pass can be used an utility function by a language frontend that doesnât
+want to manually reason about liveness, base pointers, or relocation when
+constructing IR. As currently implemented, RewriteStatepointsForGC must be
+run after SSA construction (i.e. mem2ref).</p>
+<p>RewriteStatepointsForGC will ensure that appropriate base pointers are listed
+for every relocation created. It will do so by duplicating code as needed to
+propagate the base pointer associated with each pointer being relocated to
+the appropriate safepoints. The implementation assumes that the following
+IR constructs produce base pointers: loads from the heap, addresses of global
+variables, function arguments, function return values. Constant pointers (such
+as null) are also assumed to be base pointers. In practice, this constraint
+can be relaxed to producing interior derived pointers provided the target
+collector can find the associated allocation from an arbitrary interior
+derived pointer.</p>
+<p>By default RewriteStatepointsForGC passes in <code class="docutils literal notranslate"><span class="pre">0xABCDEF00</span></code> as the statepoint
+ID and <code class="docutils literal notranslate"><span class="pre">0</span></code> as the number of patchable bytes to the newly constructed
+<code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>. These values can be configured on a per-callsite
+basis using the attributes <code class="docutils literal notranslate"><span class="pre">"statepoint-id"</span></code> and
+<code class="docutils literal notranslate"><span class="pre">"statepoint-num-patch-bytes"</span></code>. If a call site is marked with a
+<code class="docutils literal notranslate"><span class="pre">"statepoint-id"</span></code> function attribute and its value is a positive
+integer (represented as a string), then that value is used as the ID
+of the newly constructed <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>. If a call site is marked
+with a <code class="docutils literal notranslate"><span class="pre">"statepoint-num-patch-bytes"</span></code> function attribute and its
+value is a positive integer, then that value is used as the ânum patch
+bytesâ parameter of the newly constructed <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code>. The
+<code class="docutils literal notranslate"><span class="pre">"statepoint-id"</span></code> and <code class="docutils literal notranslate"><span class="pre">"statepoint-num-patch-bytes"</span></code> attributes
+are not propagated to the <code class="docutils literal notranslate"><span class="pre">gc.statepoint</span></code> call or invoke if they
+could be successfully parsed.</p>
+<p>In practice, RewriteStatepointsForGC should be run much later in the pass
+pipeline, after most optimization is already done. This helps to improve
+the quality of the generated code when compiled with garbage collection support.</p>
+</div>
+<div class="section" id="placesafepoints">
+<span id="id10"></span><h3><a class="toc-backref" href="#id27">PlaceSafepoints</a><a class="headerlink" href="#placesafepoints" title="Permalink to this headline">¶</a></h3>
+<p>The pass PlaceSafepoints inserts safepoint polls sufficient to ensure running
+code checks for a safepoint request on a timely manner. This pass is expected
+to be run before RewriteStatepointsForGC and thus does not produce full
+relocation sequences.</p>
+<p>As an example, given input IR of the following:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="kt">void</span> <span class="vg">@test</span><span class="p">()</span> <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="vg">@foo</span><span class="p">()</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+
+<span class="k">declare</span> <span class="kt">void</span> <span class="vg">@do_safepoint</span><span class="p">()</span>
+<span class="k">define</span> <span class="kt">void</span> <span class="vg">@gc.safepoint_poll</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="vg">@do_safepoint</span><span class="p">()</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This pass would produce the following IR:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="kt">void</span> <span class="vg">@test</span><span class="p">()</span> <span class="k">gc</span> <span class="s">"statepoint-example"</span> <span class="p">{</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="vg">@do_safepoint</span><span class="p">()</span>
+ <span class="k">call</span> <span class="kt">void</span> <span class="vg">@foo</span><span class="p">()</span>
+ <span class="k">ret</span> <span class="kt">void</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, weâve added an (unconditional) entry safepoint poll. Note that
+despite appearances, the entry poll is not necessarily redundant. Weâd have to
+know that <code class="docutils literal notranslate"><span class="pre">foo</span></code> and <code class="docutils literal notranslate"><span class="pre">test</span></code> were not mutually recursive for the poll to be
+redundant. In practice, youâd probably want to your poll definition to contain
+a conditional branch of some form.</p>
+<p>At the moment, PlaceSafepoints can insert safepoint polls at method entry and
+loop backedges locations. Extending this to work with return polls would be
+straight forward if desired.</p>
+<p>PlaceSafepoints includes a number of optimizations to avoid placing safepoint
+polls at particular sites unless needed to ensure timely execution of a poll
+under normal conditions. PlaceSafepoints does not attempt to ensure timely
+execution of a poll under worst case conditions such as heavy system paging.</p>
+<p>The implementation of a safepoint poll action is specified by looking up a
+function of the name <code class="docutils literal notranslate"><span class="pre">gc.safepoint_poll</span></code> in the containing Module. The body
+of this function is inserted at each poll site desired. While calls or invokes
+inside this method are transformed to a <code class="docutils literal notranslate"><span class="pre">gc.statepoints</span></code>, recursive poll
+insertion is not performed.</p>
+<p>This pass is useful for any language frontend which only has to support
+garbage collection semantics at safepoints. If you need other abstract
+frame information at safepoints (e.g. for deoptimization or introspection),
+you can insert safepoint polls in the frontend. If you have the later case,
+please ask on llvm-dev for suggestions. Thereâs been a good amount of work
+done on making such a scheme work well in practice which is not yet documented
+here.</p>
+</div>
+</div>
+<div class="section" id="supported-architectures">
+<h2><a class="toc-backref" href="#id28">Supported Architectures</a><a class="headerlink" href="#supported-architectures" title="Permalink to this headline">¶</a></h2>
+<p>Support for statepoint generation requires some code for each backend.
+Today, only X86_64 is supported.</p>
+</div>
+<div class="section" id="limitations-and-half-baked-ideas">
+<span id="openwork"></span><h2><a class="toc-backref" href="#id29">Limitations and Half Baked Ideas</a><a class="headerlink" href="#limitations-and-half-baked-ideas" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="mixing-references-and-raw-pointers">
+<h3><a class="toc-backref" href="#id30">Mixing References and Raw Pointers</a><a class="headerlink" href="#mixing-references-and-raw-pointers" title="Permalink to this headline">¶</a></h3>
+<p>Support for languages which allow unmanaged pointers to garbage collected
+objects (i.e. pass a pointer to an object to a C routine) in the abstract
+machine model. At the moment, the best idea on how to approach this
+involves an intrinsic or opaque function which hides the connection between
+the reference value and the raw pointer. The problem is that having a
+ptrtoint or inttoptr cast (which is common for such use cases) breaks the
+rules used for inferring base pointers for arbitrary references when
+lowering out of the abstract model to the explicit physical model. Note
+that a frontend which lowers directly to the physical model doesnât have
+any problems here.</p>
+</div>
+<div class="section" id="objects-on-the-stack">
+<h3><a class="toc-backref" href="#id31">Objects on the Stack</a><a class="headerlink" href="#objects-on-the-stack" title="Permalink to this headline">¶</a></h3>
+<p>As noted above, the explicit lowering supports objects allocated on the
+stack provided the collector can find a heap map given the stack address.</p>
+<p>The missing pieces are a) integration with rewriting (RS4GC) from the
+abstract machine model and b) support for optionally decomposing on stack
+objects so as not to require heap maps for them. The later is required
+for ease of integration with some collectors.</p>
+</div>
+<div class="section" id="lowering-quality-and-representation-overhead">
+<h3><a class="toc-backref" href="#id32">Lowering Quality and Representation Overhead</a><a class="headerlink" href="#lowering-quality-and-representation-overhead" title="Permalink to this headline">¶</a></h3>
+<p>The current statepoint lowering is known to be somewhat poor. In the very
+long term, weâd like to integrate statepoints with the register allocator;
+in the near term this is unlikely to happen. Weâve found the quality of
+lowering to be relatively unimportant as hot-statepoints are almost always
+inliner bugs.</p>
+<p>Concerns have been raised that the statepoint representation results in a
+large amount of IR being produced for some examples and that this
+contributes to higher than expected memory usage and compile times. Thereâs
+no immediate plans to make changes due to this, but alternate models may be
+explored in the future.</p>
+</div>
+<div class="section" id="relocations-along-exceptional-edges">
+<h3><a class="toc-backref" href="#id33">Relocations Along Exceptional Edges</a><a class="headerlink" href="#relocations-along-exceptional-edges" title="Permalink to this headline">¶</a></h3>
+<p>Relocations along exceptional paths are currently broken in ToT. In
+particular, there is current no way to represent a rethrow on a path which
+also has relocations. See <a class="reference external" href="https://groups.google.com/forum/#!topic/llvm-dev/AE417XjgxvI">this llvm-dev discussion</a> for more
+detail.</p>
+</div>
+<div class="section" id="support-for-alternate-stackmap-formats">
+<h3><a class="toc-backref" href="#id34">Support for alternate stackmap formats</a><a class="headerlink" href="#support-for-alternate-stackmap-formats" title="Permalink to this headline">¶</a></h3>
+<p>For some use cases, it is
+desirable to directly encode a final memory efficient stackmap format for
+use by the runtime. This is particularly relevant for ahead of time
+compilers which wish to directly link object files without the need for
+post processing of each individual object file. While not implemented
+today for statepoints, there is precedent for a GCStrategy to be able to
+select a customer GCMetataPrinter for this purpose. Patches to enable
+this functionality upstream are welcome.</p>
+</div>
+</div>
+<div class="section" id="bugs-and-enhancements">
+<h2><a class="toc-backref" href="#id35">Bugs and Enhancements</a><a class="headerlink" href="#bugs-and-enhancements" title="Permalink to this headline">¶</a></h2>
+<p>Currently known bugs and enhancements under consideration can be
+tracked by performing a <a class="reference external" href="https://bugs.llvm.org/buglist.cgi?cmdtype=runnamed&namedcmd=Statepoint%20Bugs&list_id=64342">bugzilla search</a>
+for [Statepoint] in the summary field. When filing new bugs, please
+use this tag so that interested parties see the newly filed bug. As
+with most LLVM features, design discussions take place on <a class="reference external" href="http://lists.llvm.org/mailman/listinfo/llvm-dev">llvm-dev</a>, and patches
+should be sent to <a class="reference external" href="http://lists.llvm.org/mailman/listinfo/llvm-commits">llvm-commits</a> for review.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="MergeFunctions.html" title="MergeFunctions pass, how it works"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="CoverageMappingFormat.html" title="LLVM Code Coverage Mapping 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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/SupportLibrary.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/SupportLibrary.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/SupportLibrary.html (added)
+++ www-releases/trunk/9.0.0/docs/SupportLibrary.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,302 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Support Library — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Source Level Debugging with LLVM" href="SourceLevelDebugging.html" />
+ <link rel="prev" title="System Library" href="SystemLibrary.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" role="navigation" aria-label="related navigation">
+ <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="SourceLevelDebugging.html" title="Source Level Debugging with LLVM"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="SystemLibrary.html" title="System Library"
+ 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" role="main">
+
+ <div class="section" id="support-library">
+<h1>Support Library<a class="headerlink" href="#support-library" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="abstract">
+<h2>Abstract<a class="headerlink" href="#abstract" title="Permalink to this headline">¶</a></h2>
+<p>This document provides some details on LLVMâs Support Library, located in the
+source at <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> and <code class="docutils literal notranslate"><span class="pre">include/llvm/Support</span></code>. The libraryâs purpose
+is to shield LLVM from the differences between operating systems for the few
+services LLVM needs from the operating system. Much of LLVM is written using
+portability features of standard C++. However, in a few areas, system dependent
+facilities are needed and the Support Library is the wrapper around those
+system calls.</p>
+<p>By centralizing LLVMâs use of operating system interfaces, we make it possible
+for the LLVM tool chain and runtime libraries to be more easily ported to new
+platforms since (theoretically) only <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> needs to be ported. This
+library also unclutters the rest of LLVM from #ifdef use and special cases for
+specific operating systems. Such uses are replaced with simple calls to the
+interfaces provided in <code class="docutils literal notranslate"><span class="pre">include/llvm/Support</span></code>.</p>
+<p>Note that the Support Library is not intended to be a complete operating system
+wrapper (such as the Adaptive Communications Environment (ACE) or Apache
+Portable Runtime (APR)), but only provides the functionality necessary to
+support LLVM.</p>
+<p>The Support Library was originally referred to as the System Library, written
+by Reid Spencer who formulated the design based on similar work originating
+from the eXtensible Programming System (XPS). Several people helped with the
+effort; especially, Jeff Cohen and Henrik Bach on the Win32 port.</p>
+</div>
+<div class="section" id="keeping-llvm-portable">
+<h2>Keeping LLVM Portable<a class="headerlink" href="#keeping-llvm-portable" title="Permalink to this headline">¶</a></h2>
+<p>In order to keep LLVM portable, LLVM developers should adhere to a set of
+portability rules associated with the Support Library. Adherence to these rules
+should help the Support Library achieve its goal of shielding LLVM from the
+variations in operating system interfaces and doing so efficiently. The
+following sections define the rules needed to fulfill this objective.</p>
+<div class="section" id="don-t-include-system-headers">
+<h3>Donât Include System Headers<a class="headerlink" href="#don-t-include-system-headers" title="Permalink to this headline">¶</a></h3>
+<p>Except in <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>, no LLVM source code should directly <code class="docutils literal notranslate"><span class="pre">#include</span></code> a
+system header. Care has been taken to remove all such <code class="docutils literal notranslate"><span class="pre">#includes</span></code> from LLVM
+while <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> was being developed. Specifically this means that header
+files like â<code class="docutils literal notranslate"><span class="pre">unistd.h</span></code>â, â<code class="docutils literal notranslate"><span class="pre">windows.h</span></code>â, â<code class="docutils literal notranslate"><span class="pre">stdio.h</span></code>â, and â<code class="docutils literal notranslate"><span class="pre">string.h</span></code>â
+are forbidden to be included by LLVM source code outside the implementation of
+<code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>.</p>
+<p>To obtain system-dependent functionality, existing interfaces to the system
+found in <code class="docutils literal notranslate"><span class="pre">include/llvm/Support</span></code> should be used. If an appropriate interface is
+not available, it should be added to <code class="docutils literal notranslate"><span class="pre">include/llvm/Support</span></code> and implemented in
+<code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> for all supported platforms.</p>
+</div>
+<div class="section" id="don-t-expose-system-headers">
+<h3>Donât Expose System Headers<a class="headerlink" href="#don-t-expose-system-headers" title="Permalink to this headline">¶</a></h3>
+<p>The Support Library must shield LLVM from <strong>all</strong> system headers. To obtain
+system level functionality, LLVM source must
+<code class="docutils literal notranslate"><span class="pre">#include</span> <span class="pre">"llvm/Support/Thing.h"</span></code> and nothing else. This means that
+<code class="docutils literal notranslate"><span class="pre">Thing.h</span></code> cannot expose any system header files. This protects LLVM from
+accidentally using system specific functionality and only allows it via
+the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface.</p>
+</div>
+<div class="section" id="use-standard-c-headers">
+<h3>Use Standard C Headers<a class="headerlink" href="#use-standard-c-headers" title="Permalink to this headline">¶</a></h3>
+<p>The <strong>standard</strong> C headers (the ones beginning with âcâ) are allowed to be
+exposed through the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface. These headers and the things they
+declare are considered to be platform agnostic. LLVM source files may include
+them directly or obtain their inclusion through <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interfaces.</p>
+</div>
+<div class="section" id="id1">
+<h3>Use Standard C++ Headers<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<p>The <strong>standard</strong> C++ headers from the standard C++ library and standard
+template library may be exposed through the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface. These
+headers and the things they declare are considered to be platform agnostic.
+LLVM source files may include them or obtain their inclusion through
+<code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interfaces.</p>
+</div>
+<div class="section" id="high-level-interface">
+<h3>High Level Interface<a class="headerlink" href="#high-level-interface" title="Permalink to this headline">¶</a></h3>
+<p>The entry points specified in the interface of <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> must be aimed at
+completing some reasonably high level task needed by LLVM. We do not want to
+simply wrap each operating system call. It would be preferable to wrap several
+operating system calls that are always used in conjunction with one another by
+LLVM.</p>
+<p>For example, consider what is needed to execute a program, wait for it to
+complete, and return its result code. On Unix, this involves the following
+operating system calls: <code class="docutils literal notranslate"><span class="pre">getenv</span></code>, <code class="docutils literal notranslate"><span class="pre">fork</span></code>, <code class="docutils literal notranslate"><span class="pre">execve</span></code>, and <code class="docutils literal notranslate"><span class="pre">wait</span></code>. The
+correct thing for <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> to provide is a function, say
+<code class="docutils literal notranslate"><span class="pre">ExecuteProgramAndWait</span></code>, that implements the functionality completely. what
+we donât want is wrappers for the operating system calls involved.</p>
+<p>There must <strong>not</strong> be a one-to-one relationship between operating system
+calls and the Support libraryâs interface. Any such interface function will be
+suspicious.</p>
+</div>
+<div class="section" id="no-unused-functionality">
+<h3>No Unused Functionality<a class="headerlink" href="#no-unused-functionality" title="Permalink to this headline">¶</a></h3>
+<p>There must be no functionality specified in the interface of <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>
+that isnât actually used by LLVM. Weâre not writing a general purpose operating
+system wrapper here, just enough to satisfy LLVMâs needs. And, LLVM doesnât
+need much. This design goal aims to keep the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface small and
+understandable which should foster its actual use and adoption.</p>
+</div>
+<div class="section" id="no-duplicate-implementations">
+<h3>No Duplicate Implementations<a class="headerlink" href="#no-duplicate-implementations" title="Permalink to this headline">¶</a></h3>
+<p>The implementation of a function for a given platform must be written exactly
+once. This implies that it must be possible to apply a functionâs
+implementation to multiple operating systems if those operating systems can
+share the same implementation. This rule applies to the set of operating
+systems supported for a given class of operating system (e.g. Unix, Win32).</p>
+</div>
+<div class="section" id="no-virtual-methods">
+<h3>No Virtual Methods<a class="headerlink" href="#no-virtual-methods" title="Permalink to this headline">¶</a></h3>
+<p>The Support Library interfaces can be called quite frequently by LLVM. In order
+to make those calls as efficient as possible, we discourage the use of virtual
+methods. There is no need to use inheritance for implementation differences, it
+just adds complexity. The <code class="docutils literal notranslate"><span class="pre">#include</span></code> mechanism works just fine.</p>
+</div>
+<div class="section" id="no-exposed-functions">
+<h3>No Exposed Functions<a class="headerlink" href="#no-exposed-functions" title="Permalink to this headline">¶</a></h3>
+<p>Any functions defined by system libraries (i.e. not defined by <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>)
+must not be exposed through the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface, even if the header
+file for that function is not exposed. This prevents inadvertent use of system
+specific functionality.</p>
+<p>For example, the <code class="docutils literal notranslate"><span class="pre">stat</span></code> system call is notorious for having variations in the
+data it provides. <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> must not declare <code class="docutils literal notranslate"><span class="pre">stat</span></code> nor allow it to be
+declared. Instead it should provide its own interface to discovering
+information about files and directories. Those interfaces may be implemented in
+terms of <code class="docutils literal notranslate"><span class="pre">stat</span></code> but that is strictly an implementation detail. The interface
+provided by the Support Library must be implemented on all platforms (even
+those without <code class="docutils literal notranslate"><span class="pre">stat</span></code>).</p>
+</div>
+<div class="section" id="no-exposed-data">
+<h3>No Exposed Data<a class="headerlink" href="#no-exposed-data" title="Permalink to this headline">¶</a></h3>
+<p>Any data defined by system libraries (i.e. not defined by <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>) must
+not be exposed through the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface, even if the header file
+for that function is not exposed. As with functions, this prevents inadvertent
+use of data that might not exist on all platforms.</p>
+</div>
+<div class="section" id="minimize-soft-errors">
+<h3>Minimize Soft Errors<a class="headerlink" href="#minimize-soft-errors" title="Permalink to this headline">¶</a></h3>
+<p>Operating system interfaces will generally provide error results for every
+little thing that could go wrong. In almost all cases, you can divide these
+error results into two groups: normal/good/soft and abnormal/bad/hard. That is,
+some of the errors are simply information like âfile not foundâ, âinsufficient
+privilegesâ, etc. while other errors are much harder like âout of spaceâ, âbad
+disk sectorâ, or âsystem call interruptedâ. Weâll call the first group â<em>soft</em>â
+errors and the second group â<em>hard</em>â errors.</p>
+<p><code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> must always attempt to minimize soft errors. This is a design
+requirement because the minimization of soft errors can affect the granularity
+and the nature of the interface. In general, if you find that youâre wanting to
+throw soft errors, you must review the granularity of the interface because it
+is likely youâre trying to implement something that is too low level. The rule
+of thumb is to provide interface functions that <strong>canât</strong> fail, except when
+faced with hard errors.</p>
+<p>For a trivial example, suppose we wanted to add an â<code class="docutils literal notranslate"><span class="pre">OpenFileForWriting</span></code>â
+function. For many operating systems, if the file doesnât exist, attempting to
+open the file will produce an error. However, <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> should not simply
+throw that error if it occurs because its a soft error. The problem is that the
+interface function, <code class="docutils literal notranslate"><span class="pre">OpenFileForWriting</span></code> is too low level. It should be
+<code class="docutils literal notranslate"><span class="pre">OpenOrCreateFileForWriting</span></code>. In the case of the soft âdoesnât existâ error,
+this function would just create it and then open it for writing.</p>
+<p>This design principle needs to be maintained in <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> because it
+avoids the propagation of soft error handling throughout the rest of LLVM.
+Hard errors will generally just cause a termination for an LLVM tool so donât
+be bashful about throwing them.</p>
+<p>Rules of thumb:</p>
+<ol class="arabic simple">
+<li>Donât throw soft errors, only hard errors.</li>
+<li>If youâre tempted to throw a soft error, re-think the interface.</li>
+<li>Handle internally the most common normal/good/soft error conditions
+so the rest of LLVM doesnât have to.</li>
+</ol>
+</div>
+<div class="section" id="no-throw-specifications">
+<h3>No throw Specifications<a class="headerlink" href="#no-throw-specifications" title="Permalink to this headline">¶</a></h3>
+<p>None of the <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface functions may be declared with C++
+<code class="docutils literal notranslate"><span class="pre">throw()</span></code> specifications on them. This requirement makes sure that the
+compiler does not insert additional exception handling code into the interface
+functions. This is a performance consideration: <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> functions are
+at the bottom of many call chains and as such can be frequently called. We
+need them to be as efficient as possible. However, no routines in the system
+library should actually throw exceptions.</p>
+</div>
+<div class="section" id="code-organization">
+<h3>Code Organization<a class="headerlink" href="#code-organization" title="Permalink to this headline">¶</a></h3>
+<p>Implementations of the Support Library interface are separated by their general
+class of operating system. Currently only Unix and Win32 classes are defined
+but more could be added for other operating system classifications. To
+distinguish which implementation to compile, the code in <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> uses
+the <code class="docutils literal notranslate"><span class="pre">LLVM_ON_UNIX</span></code> and <code class="docutils literal notranslate"><span class="pre">_WIN32</span></code> <code class="docutils literal notranslate"><span class="pre">#defines</span></code>. Each source file in
+<code class="docutils literal notranslate"><span class="pre">lib/Support</span></code>, after implementing the generic (operating system independent)
+functionality needs to include the correct implementation using a set of
+<code class="docutils literal notranslate"><span class="pre">#if</span> <span class="pre">defined(LLVM_ON_XYZ)</span></code> directives. For example, if we had
+<code class="docutils literal notranslate"><span class="pre">lib/Support/Path.cpp</span></code>, weâd expect to see in that file:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#if defined(LLVM_ON_UNIX)</span>
+<span class="cp">#include</span> <span class="cpf">"Unix/Path.inc"</span><span class="cp"></span>
+<span class="cp">#endif</span>
+<span class="cp">#if defined(_WIN32)</span>
+<span class="cp">#include</span> <span class="cpf">"Windows/Path.inc"</span><span class="cp"></span>
+<span class="cp">#endif</span>
+</pre></div>
+</div>
+<p>The implementation in <code class="docutils literal notranslate"><span class="pre">lib/Support/Unix/Path.inc</span></code> should handle all Unix
+variants. The implementation in <code class="docutils literal notranslate"><span class="pre">lib/Support/Windows/Path.inc</span></code> should handle
+all Windows variants. What this does is quickly inc the basic class
+of operating system that will provide the implementation. The specific details
+for a given platform must still be determined through the use of <code class="docutils literal notranslate"><span class="pre">#ifdef</span></code>.</p>
+</div>
+<div class="section" id="consistent-semantics">
+<h3>Consistent Semantics<a class="headerlink" href="#consistent-semantics" title="Permalink to this headline">¶</a></h3>
+<p>The implementation of a <code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> interface can vary drastically between
+platforms. Thatâs okay as long as the end result of the interface function is
+the same. For example, a function to create a directory is pretty straight
+forward on all operating system. System V IPC on the other hand isnât even
+supported on all platforms. Instead of âsupportingâ System V IPC,
+<code class="docutils literal notranslate"><span class="pre">lib/Support</span></code> should provide an interface to the basic concept of
+inter-process communications. The implementations might use System V IPC if
+that was available or named pipes, or whatever gets the job done effectively
+for a given operating system. In all cases, the interface and the
+implementation must be semantically consistent.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="SourceLevelDebugging.html" title="Source Level Debugging with LLVM"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="SystemLibrary.html" title="System Library"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/SystemLibrary.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/SystemLibrary.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/SystemLibrary.html (added)
+++ www-releases/trunk/9.0.0/docs/SystemLibrary.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,94 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>System Library — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Support Library" href="SupportLibrary.html" />
+ <link rel="prev" title="LLVMâs Optional Rich Disassembly Output" href="MarkedUpDisassembly.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" role="navigation" aria-label="related navigation">
+ <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="SupportLibrary.html" title="Support Library"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="MarkedUpDisassembly.html" title="LLVMâs Optional Rich Disassembly Output"
+ 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" role="main">
+
+ <div class="section" id="system-library">
+<h1>System Library<a class="headerlink" href="#system-library" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="moved">
+<h2>Moved<a class="headerlink" href="#moved" title="Permalink to this headline">¶</a></h2>
+<p>The System Library has been renamed to Support Library with documentation
+available at <a class="reference internal" href="SupportLibrary.html"><span class="doc">Support Library</span></a>. Please, change your links to that page.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="SupportLibrary.html" title="Support Library"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="MarkedUpDisassembly.html" title="LLVMâs Optional Rich Disassembly Output"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGen/BackEnds.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGen/BackEnds.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGen/BackEnds.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGen/BackEnds.html Thu Sep 19 07:32:46 2019
@@ -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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen BackEnds — LLVM 9 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" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></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>
+ <script type="text/javascript" src="../_static/language_data.js"></script>
+ <link rel="index" title="Index" href="../genindex.html" />
+ <link rel="search" title="Search" href="../search.html" />
+ <link rel="next" title="TableGen Language Reference" href="LangRef.html" />
+ <link rel="prev" title="TableGen" 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" role="navigation" aria-label="related navigation">
+ <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="LangRef.html" title="TableGen Language Reference"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="index.html" title="TableGen"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="tablegen-backends">
+<h1>TableGen BackEnds<a class="headerlink" href="#tablegen-backends" 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="#llvm-backends" id="id2">LLVM BackEnds</a><ul>
+<li><a class="reference internal" href="#codeemitter" id="id3">CodeEmitter</a></li>
+<li><a class="reference internal" href="#registerinfo" id="id4">RegisterInfo</a></li>
+<li><a class="reference internal" href="#instrinfo" id="id5">InstrInfo</a></li>
+<li><a class="reference internal" href="#asmwriter" id="id6">AsmWriter</a></li>
+<li><a class="reference internal" href="#asmmatcher" id="id7">AsmMatcher</a></li>
+<li><a class="reference internal" href="#disassembler" id="id8">Disassembler</a></li>
+<li><a class="reference internal" href="#pseudolowering" id="id9">PseudoLowering</a></li>
+<li><a class="reference internal" href="#callingconv" id="id10">CallingConv</a></li>
+<li><a class="reference internal" href="#dagisel" id="id11">DAGISel</a></li>
+<li><a class="reference internal" href="#dfapacketizer" id="id12">DFAPacketizer</a></li>
+<li><a class="reference internal" href="#fastisel" id="id13">FastISel</a></li>
+<li><a class="reference internal" href="#subtarget" id="id14">Subtarget</a></li>
+<li><a class="reference internal" href="#intrinsic" id="id15">Intrinsic</a></li>
+<li><a class="reference internal" href="#optparserdefs" id="id16">OptParserDefs</a></li>
+<li><a class="reference internal" href="#searchabletables" id="id17">SearchableTables</a></li>
+<li><a class="reference internal" href="#ctags" id="id18">CTags</a></li>
+<li><a class="reference internal" href="#x86evex2vex" id="id19">X86EVEX2VEX</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#clang-backends" id="id20">Clang BackEnds</a><ul>
+<li><a class="reference internal" href="#clangattrclasses" id="id21">ClangAttrClasses</a></li>
+<li><a class="reference internal" href="#clangattrparserstringswitches" id="id22">ClangAttrParserStringSwitches</a></li>
+<li><a class="reference internal" href="#clangattrimpl" id="id23">ClangAttrImpl</a></li>
+<li><a class="reference internal" href="#clangattrlist" id="id24">ClangAttrList</a></li>
+<li><a class="reference internal" href="#clangattrpchread" id="id25">ClangAttrPCHRead</a></li>
+<li><a class="reference internal" href="#clangattrpchwrite" id="id26">ClangAttrPCHWrite</a></li>
+<li><a class="reference internal" href="#clangattrspellings" id="id27">ClangAttrSpellings</a></li>
+<li><a class="reference internal" href="#clangattrspellinglistindex" id="id28">ClangAttrSpellingListIndex</a></li>
+<li><a class="reference internal" href="#clangattrvisitor" id="id29">ClangAttrVisitor</a></li>
+<li><a class="reference internal" href="#clangattrtemplateinstantiate" id="id30">ClangAttrTemplateInstantiate</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrlist" id="id31">ClangAttrParsedAttrList</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrimpl" id="id32">ClangAttrParsedAttrImpl</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrkinds" id="id33">ClangAttrParsedAttrKinds</a></li>
+<li><a class="reference internal" href="#clangattrdump" id="id34">ClangAttrDump</a></li>
+<li><a class="reference internal" href="#clangdiagsdefs" id="id35">ClangDiagsDefs</a></li>
+<li><a class="reference internal" href="#clangdiaggroups" id="id36">ClangDiagGroups</a></li>
+<li><a class="reference internal" href="#clangdiagsindexname" id="id37">ClangDiagsIndexName</a></li>
+<li><a class="reference internal" href="#clangcommentnodes" id="id38">ClangCommentNodes</a></li>
+<li><a class="reference internal" href="#clangdeclnodes" id="id39">ClangDeclNodes</a></li>
+<li><a class="reference internal" href="#clangstmtnodes" id="id40">ClangStmtNodes</a></li>
+<li><a class="reference internal" href="#clangsacheckers" id="id41">ClangSACheckers</a></li>
+<li><a class="reference internal" href="#clangcommenthtmltags" id="id42">ClangCommentHTMLTags</a></li>
+<li><a class="reference internal" href="#clangcommenthtmltagsproperties" id="id43">ClangCommentHTMLTagsProperties</a></li>
+<li><a class="reference internal" href="#clangcommenthtmlnamedcharacterreferences" id="id44">ClangCommentHTMLNamedCharacterReferences</a></li>
+<li><a class="reference internal" href="#clangcommentcommandinfo" id="id45">ClangCommentCommandInfo</a></li>
+<li><a class="reference internal" href="#clangcommentcommandlist" id="id46">ClangCommentCommandList</a></li>
+<li><a class="reference internal" href="#armneon" id="id47">ArmNeon</a></li>
+<li><a class="reference internal" href="#armneonsema" id="id48">ArmNeonSema</a></li>
+<li><a class="reference internal" href="#armneontest" id="id49">ArmNeonTest</a></li>
+<li><a class="reference internal" href="#attrdocs" id="id50">AttrDocs</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#general-backends" id="id51">General BackEnds</a><ul>
+<li><a class="reference internal" href="#json" id="id52">JSON</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#how-to-write-a-back-end" id="id53">How to write a back-end</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>TableGen backends are at the core of TableGenâs functionality. The source files
+provide the semantics to a generated (in memory) structure, but itâs up to the
+backend to print this out in a way that is meaningful to the user (normally a
+C program including a file or a textual list of warnings, options and error
+messages).</p>
+<p>TableGen is used by both LLVM and Clang with very different goals. LLVM uses it
+as a way to automate the generation of massive amounts of information regarding
+instructions, schedules, cores and architecture features. Some backends generate
+output that is consumed by more than one source file, so they need to be created
+in a way that is easy to use pre-processor tricks. Some backends can also print
+C code structures, so that they can be directly included as-is.</p>
+<p>Clang, on the other hand, uses it mainly for diagnostic messages (errors,
+warnings, tips) and attributes, so more on the textual end of the scale.</p>
+</div>
+<div class="section" id="llvm-backends">
+<h2><a class="toc-backref" href="#id2">LLVM BackEnds</a><a class="headerlink" href="#llvm-backends" title="Permalink to this headline">¶</a></h2>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">This document is raw. Each section below needs three sub-sections: description
+of its purpose with a list of users, output generated from generic input, and
+finally why it needed a new backend (in case thereâs something similar).</p>
+</div>
+<p>Overall, each backend will take the same TableGen file type and transform into
+similar output for different targets/uses. There is an implicit contract between
+the TableGen files, the back-ends and their users.</p>
+<p>For instance, a global contract is that each back-end produces macro-guarded
+sections. Based on whether the file is included by a header or a source file,
+or even in which context of each file the include is being used, you have
+todefine a macro just before including it, to get the right output:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#define GET_REGINFO_TARGET_DESC</span>
+<span class="cp">#include</span> <span class="cpf">"ARMGenRegisterInfo.inc"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>And just part of the generated file would be included. This is useful if
+you need the same information in multiple formats (instantiation, initialization,
+getter/setter functions, etc) from the same source TableGen file without having
+to re-compile the TableGen file multiple times.</p>
+<p>Sometimes, multiple macros might be defined before the same include file to
+output multiple blocks:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#define GET_REGISTER_MATCHER</span>
+<span class="cp">#define GET_SUBTARGET_FEATURE_NAME</span>
+<span class="cp">#define GET_MATCHER_IMPLEMENTATION</span>
+<span class="cp">#include</span> <span class="cpf">"ARMGenAsmMatcher.inc"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>The macros will be undefâd automatically as theyâre used, in the include file.</p>
+<p>On all LLVM back-ends, the <code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span></code> binary will be executed on the root
+TableGen file <code class="docutils literal notranslate"><span class="pre"><Target>.td</span></code>, which should include all others. This guarantees
+that all information needed is accessible, and that no duplication is needed
+in the TableGen files.</p>
+<div class="section" id="codeemitter">
+<h3><a class="toc-backref" href="#id3">CodeEmitter</a><a class="headerlink" href="#codeemitter" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: CodeEmitterGen uses the descriptions of instructions and their fields to
+construct an automated code emitter: a function that, given a MachineInstr,
+returns the (currently, 32-bit unsigned) value of the instruction.</p>
+<p><strong>Output</strong>: C++ code, implementing the targetâs CodeEmitter
+class by overriding the virtual functions as <code class="docutils literal notranslate"><span class="pre"><Target>CodeEmitter::function()</span></code>.</p>
+<p><strong>Usage</strong>: Used to include directly at the end of <code class="docutils literal notranslate"><span class="pre"><Target>MCCodeEmitter.cpp</span></code>.</p>
+</div>
+<div class="section" id="registerinfo">
+<h3><a class="toc-backref" href="#id4">RegisterInfo</a><a class="headerlink" href="#registerinfo" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This tablegen backend is responsible for emitting a description of a target
+register file for a code generator. It uses instances of the Register,
+RegisterAliases, and RegisterClass classes to gather this information.</p>
+<p><strong>Output</strong>: C++ code with enums and structures representing the register mappings,
+properties, masks, etc.</p>
+<p><strong>Usage</strong>: Both on <code class="docutils literal notranslate"><span class="pre"><Target>BaseRegisterInfo</span></code> and <code class="docutils literal notranslate"><span class="pre"><Target>MCTargetDesc</span></code> (headers
+and source files) with macros defining in which they are for declaration vs.
+initialization issues.</p>
+</div>
+<div class="section" id="instrinfo">
+<h3><a class="toc-backref" href="#id5">InstrInfo</a><a class="headerlink" href="#instrinfo" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This tablegen backend is responsible for emitting a description of the target
+instruction set for the code generator. (what are the differences from CodeEmitter?)</p>
+<p><strong>Output</strong>: C++ code with enums and structures representing the instruction mappings,
+properties, masks, etc.</p>
+<p><strong>Usage</strong>: Both on <code class="docutils literal notranslate"><span class="pre"><Target>BaseInstrInfo</span></code> and <code class="docutils literal notranslate"><span class="pre"><Target>MCTargetDesc</span></code> (headers
+and source files) with macros defining in which they are for declaration vs.
+initialization issues.</p>
+</div>
+<div class="section" id="asmwriter">
+<h3><a class="toc-backref" href="#id6">AsmWriter</a><a class="headerlink" href="#asmwriter" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Emits an assembly printer for the current target.</p>
+<p><strong>Output</strong>: Implementation of <code class="docutils literal notranslate"><span class="pre"><Target>InstPrinter::printInstruction()</span></code>, among
+other things.</p>
+<p><strong>Usage</strong>: Included directly into <code class="docutils literal notranslate"><span class="pre">InstPrinter/<Target>InstPrinter.cpp</span></code>.</p>
+</div>
+<div class="section" id="asmmatcher">
+<h3><a class="toc-backref" href="#id7">AsmMatcher</a><a class="headerlink" href="#asmmatcher" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Emits a target specifier matcher for
+converting parsed assembly operands in the MCInst structures. It also
+emits a matcher for custom operand parsing. Extensive documentation is
+written on the <code class="docutils literal notranslate"><span class="pre">AsmMatcherEmitter.cpp</span></code> file.</p>
+<p><strong>Output</strong>: Assembler parsersâ matcher functions, declarations, etc.</p>
+<p><strong>Usage</strong>: Used in back-endsâ <code class="docutils literal notranslate"><span class="pre">AsmParser/<Target>AsmParser.cpp</span></code> for
+building the AsmParser class.</p>
+</div>
+<div class="section" id="disassembler">
+<h3><a class="toc-backref" href="#id8">Disassembler</a><a class="headerlink" href="#disassembler" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Contains disassembler table emitters for various
+architectures. Extensive documentation is written on the
+<code class="docutils literal notranslate"><span class="pre">DisassemblerEmitter.cpp</span></code> file.</p>
+<p><strong>Output</strong>: Decoding tables, static decoding functions, etc.</p>
+<p><strong>Usage</strong>: Directly included in <code class="docutils literal notranslate"><span class="pre">Disassembler/<Target>Disassembler.cpp</span></code>
+to cater for all default decodings, after all hand-made ones.</p>
+</div>
+<div class="section" id="pseudolowering">
+<h3><a class="toc-backref" href="#id9">PseudoLowering</a><a class="headerlink" href="#pseudolowering" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Generate pseudo instruction lowering.</p>
+<p><strong>Output</strong>: Implements <code class="docutils literal notranslate"><span class="pre"><Target>AsmPrinter::emitPseudoExpansionLowering()</span></code>.</p>
+<p><strong>Usage</strong>: Included directly into <code class="docutils literal notranslate"><span class="pre"><Target>AsmPrinter.cpp</span></code>.</p>
+</div>
+<div class="section" id="callingconv">
+<h3><a class="toc-backref" href="#id10">CallingConv</a><a class="headerlink" href="#callingconv" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Responsible for emitting descriptions of the calling
+conventions supported by this target.</p>
+<p><strong>Output</strong>: Implement static functions to deal with calling conventions
+chained by matching styles, returning false on no match.</p>
+<p><strong>Usage</strong>: Used in ISelLowering and FastIsel as function pointers to
+implementation returned by a CC selection function.</p>
+</div>
+<div class="section" id="dagisel">
+<h3><a class="toc-backref" href="#id11">DAGISel</a><a class="headerlink" href="#dagisel" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Generate a DAG instruction selector.</p>
+<p><strong>Output</strong>: Creates huge functions for automating DAG selection.</p>
+<p><strong>Usage</strong>: Included in <code class="docutils literal notranslate"><span class="pre"><Target>ISelDAGToDAG.cpp</span></code> inside the targetâs
+implementation of <code class="docutils literal notranslate"><span class="pre">SelectionDAGISel</span></code>.</p>
+</div>
+<div class="section" id="dfapacketizer">
+<h3><a class="toc-backref" href="#id12">DFAPacketizer</a><a class="headerlink" href="#dfapacketizer" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This class parses the Schedule.td file and produces an API that
+can be used to reason about whether an instruction can be added to a packet
+on a VLIW architecture. The class internally generates a deterministic finite
+automaton (DFA) that models all possible mappings of machine instructions
+to functional units as instructions are added to a packet.</p>
+<p><strong>Output</strong>: Scheduling tables for GPU back-ends (Hexagon, AMD).</p>
+<p><strong>Usage</strong>: Included directly on <code class="docutils literal notranslate"><span class="pre"><Target>InstrInfo.cpp</span></code>.</p>
+</div>
+<div class="section" id="fastisel">
+<h3><a class="toc-backref" href="#id13">FastISel</a><a class="headerlink" href="#fastisel" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This tablegen backend emits code for use by the âfastâ
+instruction selection algorithm. See the comments at the top of
+lib/CodeGen/SelectionDAG/FastISel.cpp for background. This file
+scans through the targetâs tablegen instruction-info files
+and extracts instructions with obvious-looking patterns, and it emits
+code to look up these instructions by type and operator.</p>
+<p><strong>Output</strong>: Generates <code class="docutils literal notranslate"><span class="pre">Predicate</span></code> and <code class="docutils literal notranslate"><span class="pre">FastEmit</span></code> methods.</p>
+<p><strong>Usage</strong>: Implements private methods of the targetsâ implementation
+of <code class="docutils literal notranslate"><span class="pre">FastISel</span></code> class.</p>
+</div>
+<div class="section" id="subtarget">
+<h3><a class="toc-backref" href="#id14">Subtarget</a><a class="headerlink" href="#subtarget" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Generate subtarget enumerations.</p>
+<p><strong>Output</strong>: Enums, globals, local tables for sub-target information.</p>
+<p><strong>Usage</strong>: Populates <code class="docutils literal notranslate"><span class="pre"><Target>Subtarget</span></code> and
+<code class="docutils literal notranslate"><span class="pre">MCTargetDesc/<Target>MCTargetDesc</span></code> files (both headers and source).</p>
+</div>
+<div class="section" id="intrinsic">
+<h3><a class="toc-backref" href="#id15">Intrinsic</a><a class="headerlink" href="#intrinsic" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Generate (target) intrinsic information.</p>
+</div>
+<div class="section" id="optparserdefs">
+<h3><a class="toc-backref" href="#id16">OptParserDefs</a><a class="headerlink" href="#optparserdefs" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Print enum values for a class.</p>
+</div>
+<div class="section" id="searchabletables">
+<h3><a class="toc-backref" href="#id17">SearchableTables</a><a class="headerlink" href="#searchabletables" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Generate custom searchable tables.</p>
+<p><strong>Output</strong>: Enums, global tables and lookup helper functions.</p>
+<p><strong>Usage</strong>: This backend allows generating free-form, target-specific tables
+from TableGen records. The ARM and AArch64 targets use this backend to generate
+tables of system registers; the AMDGPU target uses it to generate meta-data
+about complex image and memory buffer instructions.</p>
+<p>More documentation is available in <code class="docutils literal notranslate"><span class="pre">include/llvm/TableGen/SearchableTable.td</span></code>,
+which also contains the definitions of TableGen classes which must be
+instantiated in order to define the enums and tables emitted by this backend.</p>
+</div>
+<div class="section" id="ctags">
+<h3><a class="toc-backref" href="#id18">CTags</a><a class="headerlink" href="#ctags" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This tablegen backend emits an index of definitions in ctags(1)
+format. A helper script, utils/TableGen/tdtags, provides an easier-to-use
+interface; run âtdtags -Hâ for documentation.</p>
+</div>
+<div class="section" id="x86evex2vex">
+<h3><a class="toc-backref" href="#id19">X86EVEX2VEX</a><a class="headerlink" href="#x86evex2vex" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: This X86 specific tablegen backend emits tables that map EVEX
+encoded instructions to their VEX encoded identical instruction.</p>
+</div>
+</div>
+<div class="section" id="clang-backends">
+<h2><a class="toc-backref" href="#id20">Clang BackEnds</a><a class="headerlink" href="#clang-backends" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="clangattrclasses">
+<h3><a class="toc-backref" href="#id21">ClangAttrClasses</a><a class="headerlink" href="#clangattrclasses" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates Attrs.inc, which contains semantic attribute class
+declarations for any attribute in <code class="docutils literal notranslate"><span class="pre">Attr.td</span></code> that has not set <code class="docutils literal notranslate"><span class="pre">ASTNode</span> <span class="pre">=</span> <span class="pre">0</span></code>.
+This file is included as part of <code class="docutils literal notranslate"><span class="pre">Attr.h</span></code>.</p>
+</div>
+<div class="section" id="clangattrparserstringswitches">
+<h3><a class="toc-backref" href="#id22">ClangAttrParserStringSwitches</a><a class="headerlink" href="#clangattrparserstringswitches" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrParserStringSwitches.inc, which contains
+StringSwitch::Case statements for parser-related string switches. Each switch
+is given its own macro (such as <code class="docutils literal notranslate"><span class="pre">CLANG_ATTR_ARG_CONTEXT_LIST</span></code>, or
+<code class="docutils literal notranslate"><span class="pre">CLANG_ATTR_IDENTIFIER_ARG_LIST</span></code>), which is expected to be defined before
+including AttrParserStringSwitches.inc, and undefined after.</p>
+</div>
+<div class="section" id="clangattrimpl">
+<h3><a class="toc-backref" href="#id23">ClangAttrImpl</a><a class="headerlink" href="#clangattrimpl" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrImpl.inc, which contains semantic attribute class
+definitions for any attribute in <code class="docutils literal notranslate"><span class="pre">Attr.td</span></code> that has not set <code class="docutils literal notranslate"><span class="pre">ASTNode</span> <span class="pre">=</span> <span class="pre">0</span></code>.
+This file is included as part of <code class="docutils literal notranslate"><span class="pre">AttrImpl.cpp</span></code>.</p>
+</div>
+<div class="section" id="clangattrlist">
+<h3><a class="toc-backref" href="#id24">ClangAttrList</a><a class="headerlink" href="#clangattrlist" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrList.inc, which is used when a list of semantic
+attribute identifiers is required. For instance, <code class="docutils literal notranslate"><span class="pre">AttrKinds.h</span></code> includes this
+file to generate the list of <code class="docutils literal notranslate"><span class="pre">attr::Kind</span></code> enumeration values. This list is
+separated out into multiple categories: attributes, inheritable attributes, and
+inheritable parameter attributes. This categorization happens automatically
+based on information in <code class="docutils literal notranslate"><span class="pre">Attr.td</span></code> and is used to implement the <code class="docutils literal notranslate"><span class="pre">classof</span></code>
+functionality required for <code class="docutils literal notranslate"><span class="pre">dyn_cast</span></code> and similar APIs.</p>
+</div>
+<div class="section" id="clangattrpchread">
+<h3><a class="toc-backref" href="#id25">ClangAttrPCHRead</a><a class="headerlink" href="#clangattrpchread" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrPCHRead.inc, which is used to deserialize attributes
+in the <code class="docutils literal notranslate"><span class="pre">ASTReader::ReadAttributes</span></code> function.</p>
+</div>
+<div class="section" id="clangattrpchwrite">
+<h3><a class="toc-backref" href="#id26">ClangAttrPCHWrite</a><a class="headerlink" href="#clangattrpchwrite" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrPCHWrite.inc, which is used to serialize attributes in
+the <code class="docutils literal notranslate"><span class="pre">ASTWriter::WriteAttributes</span></code> function.</p>
+</div>
+<div class="section" id="clangattrspellings">
+<h3><a class="toc-backref" href="#id27">ClangAttrSpellings</a><a class="headerlink" href="#clangattrspellings" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrSpellings.inc, which is used to implement the
+<code class="docutils literal notranslate"><span class="pre">__has_attribute</span></code> feature test macro.</p>
+</div>
+<div class="section" id="clangattrspellinglistindex">
+<h3><a class="toc-backref" href="#id28">ClangAttrSpellingListIndex</a><a class="headerlink" href="#clangattrspellinglistindex" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrSpellingListIndex.inc, which is used to map parsed
+attribute spellings (including which syntax or scope was used) to an attribute
+spelling list index. These spelling list index values are internal
+implementation details exposed via
+<code class="docutils literal notranslate"><span class="pre">AttributeList::getAttributeSpellingListIndex</span></code>.</p>
+</div>
+<div class="section" id="clangattrvisitor">
+<h3><a class="toc-backref" href="#id29">ClangAttrVisitor</a><a class="headerlink" href="#clangattrvisitor" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrVisitor.inc, which is used when implementing
+recursive AST visitors.</p>
+</div>
+<div class="section" id="clangattrtemplateinstantiate">
+<h3><a class="toc-backref" href="#id30">ClangAttrTemplateInstantiate</a><a class="headerlink" href="#clangattrtemplateinstantiate" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrTemplateInstantiate.inc, which implements the
+<code class="docutils literal notranslate"><span class="pre">instantiateTemplateAttribute</span></code> function, used when instantiating a template
+that requires an attribute to be cloned.</p>
+</div>
+<div class="section" id="clangattrparsedattrlist">
+<h3><a class="toc-backref" href="#id31">ClangAttrParsedAttrList</a><a class="headerlink" href="#clangattrparsedattrlist" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrParsedAttrList.inc, which is used to generate the
+<code class="docutils literal notranslate"><span class="pre">AttributeList::Kind</span></code> parsed attribute enumeration.</p>
+</div>
+<div class="section" id="clangattrparsedattrimpl">
+<h3><a class="toc-backref" href="#id32">ClangAttrParsedAttrImpl</a><a class="headerlink" href="#clangattrparsedattrimpl" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrParsedAttrImpl.inc, which is used by
+<code class="docutils literal notranslate"><span class="pre">AttributeList.cpp</span></code> to implement several functions on the <code class="docutils literal notranslate"><span class="pre">AttributeList</span></code>
+class. This functionality is implemented via the <code class="docutils literal notranslate"><span class="pre">AttrInfoMap</span> <span class="pre">ParsedAttrInfo</span></code>
+array, which contains one element per parsed attribute object.</p>
+</div>
+<div class="section" id="clangattrparsedattrkinds">
+<h3><a class="toc-backref" href="#id33">ClangAttrParsedAttrKinds</a><a class="headerlink" href="#clangattrparsedattrkinds" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrParsedAttrKinds.inc, which is used to implement the
+<code class="docutils literal notranslate"><span class="pre">AttributeList::getKind</span></code> function, mapping a string (and syntax) to a parsed
+attribute <code class="docutils literal notranslate"><span class="pre">AttributeList::Kind</span></code> enumeration.</p>
+</div>
+<div class="section" id="clangattrdump">
+<h3><a class="toc-backref" href="#id34">ClangAttrDump</a><a class="headerlink" href="#clangattrdump" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrDump.inc, which dumps information about an attribute.
+It is used to implement <code class="docutils literal notranslate"><span class="pre">ASTDumper::dumpAttr</span></code>.</p>
+</div>
+<div class="section" id="clangdiagsdefs">
+<h3><a class="toc-backref" href="#id35">ClangDiagsDefs</a><a class="headerlink" href="#clangdiagsdefs" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang diagnostics definitions.</p>
+</div>
+<div class="section" id="clangdiaggroups">
+<h3><a class="toc-backref" href="#id36">ClangDiagGroups</a><a class="headerlink" href="#clangdiaggroups" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang diagnostic groups.</p>
+</div>
+<div class="section" id="clangdiagsindexname">
+<h3><a class="toc-backref" href="#id37">ClangDiagsIndexName</a><a class="headerlink" href="#clangdiagsindexname" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang diagnostic name index.</p>
+</div>
+<div class="section" id="clangcommentnodes">
+<h3><a class="toc-backref" href="#id38">ClangCommentNodes</a><a class="headerlink" href="#clangcommentnodes" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang AST comment nodes.</p>
+</div>
+<div class="section" id="clangdeclnodes">
+<h3><a class="toc-backref" href="#id39">ClangDeclNodes</a><a class="headerlink" href="#clangdeclnodes" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang AST declaration nodes.</p>
+</div>
+<div class="section" id="clangstmtnodes">
+<h3><a class="toc-backref" href="#id40">ClangStmtNodes</a><a class="headerlink" href="#clangstmtnodes" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang AST statement nodes.</p>
+</div>
+<div class="section" id="clangsacheckers">
+<h3><a class="toc-backref" href="#id41">ClangSACheckers</a><a class="headerlink" href="#clangsacheckers" title="Permalink to this headline">¶</a></h3>
+<p>Generate Clang Static Analyzer checkers.</p>
+</div>
+<div class="section" id="clangcommenthtmltags">
+<h3><a class="toc-backref" href="#id42">ClangCommentHTMLTags</a><a class="headerlink" href="#clangcommenthtmltags" title="Permalink to this headline">¶</a></h3>
+<p>Generate efficient matchers for HTML tag names that are used in documentation comments.</p>
+</div>
+<div class="section" id="clangcommenthtmltagsproperties">
+<h3><a class="toc-backref" href="#id43">ClangCommentHTMLTagsProperties</a><a class="headerlink" href="#clangcommenthtmltagsproperties" title="Permalink to this headline">¶</a></h3>
+<p>Generate efficient matchers for HTML tag properties.</p>
+</div>
+<div class="section" id="clangcommenthtmlnamedcharacterreferences">
+<h3><a class="toc-backref" href="#id44">ClangCommentHTMLNamedCharacterReferences</a><a class="headerlink" href="#clangcommenthtmlnamedcharacterreferences" title="Permalink to this headline">¶</a></h3>
+<p>Generate function to translate named character references to UTF-8 sequences.</p>
+</div>
+<div class="section" id="clangcommentcommandinfo">
+<h3><a class="toc-backref" href="#id45">ClangCommentCommandInfo</a><a class="headerlink" href="#clangcommentcommandinfo" title="Permalink to this headline">¶</a></h3>
+<p>Generate command properties for commands that are used in documentation comments.</p>
+</div>
+<div class="section" id="clangcommentcommandlist">
+<h3><a class="toc-backref" href="#id46">ClangCommentCommandList</a><a class="headerlink" href="#clangcommentcommandlist" title="Permalink to this headline">¶</a></h3>
+<p>Generate list of commands that are used in documentation comments.</p>
+</div>
+<div class="section" id="armneon">
+<h3><a class="toc-backref" href="#id47">ArmNeon</a><a class="headerlink" href="#armneon" title="Permalink to this headline">¶</a></h3>
+<p>Generate arm_neon.h for clang.</p>
+</div>
+<div class="section" id="armneonsema">
+<h3><a class="toc-backref" href="#id48">ArmNeonSema</a><a class="headerlink" href="#armneonsema" title="Permalink to this headline">¶</a></h3>
+<p>Generate ARM NEON sema support for clang.</p>
+</div>
+<div class="section" id="armneontest">
+<h3><a class="toc-backref" href="#id49">ArmNeonTest</a><a class="headerlink" href="#armneontest" title="Permalink to this headline">¶</a></h3>
+<p>Generate ARM NEON tests for clang.</p>
+</div>
+<div class="section" id="attrdocs">
+<h3><a class="toc-backref" href="#id50">AttrDocs</a><a class="headerlink" href="#attrdocs" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates <code class="docutils literal notranslate"><span class="pre">AttributeReference.rst</span></code> from <code class="docutils literal notranslate"><span class="pre">AttrDocs.td</span></code>, and is
+used for documenting user-facing attributes.</p>
+</div>
+</div>
+<div class="section" id="general-backends">
+<h2><a class="toc-backref" href="#id51">General BackEnds</a><a class="headerlink" href="#general-backends" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="json">
+<h3><a class="toc-backref" href="#id52">JSON</a><a class="headerlink" href="#json" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Output all the values in every <code class="docutils literal notranslate"><span class="pre">def</span></code>, as a JSON data
+structure that can be easily parsed by a variety of languages. Useful
+for writing custom backends without having to modify TableGen itself,
+or for performing auxiliary analysis on the same TableGen data passed
+to a built-in backend.</p>
+<p><strong>Output</strong>:</p>
+<p>The root of the output file is a JSON object (i.e. dictionary),
+containing the following fixed keys:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">!tablegen_json_version</span></code>: a numeric version field that will
+increase if an incompatible change is ever made to the structure of
+this data. The format described here corresponds to version 1.</li>
+<li><code class="docutils literal notranslate"><span class="pre">!instanceof</span></code>: a dictionary whose keys are the class names defined
+in the TableGen input. For each key, the corresponding value is an
+array of strings giving the names of <code class="docutils literal notranslate"><span class="pre">def</span></code> records that derive
+from that class. So <code class="docutils literal notranslate"><span class="pre">root["!instanceof"]["Instruction"]</span></code>, for
+example, would list the names of all the records deriving from the
+class <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>.</li>
+</ul>
+<p>For each <code class="docutils literal notranslate"><span class="pre">def</span></code> record, the root object also has a key for the record
+name. The corresponding value is a subsidiary object containing the
+following fixed keys:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">!superclasses</span></code>: an array of strings giving the names of all the
+classes that this record derives from.</li>
+<li><code class="docutils literal notranslate"><span class="pre">!fields</span></code>: an array of strings giving the names of all the variables
+in this record that were defined with the <code class="docutils literal notranslate"><span class="pre">field</span></code> keyword.</li>
+<li><code class="docutils literal notranslate"><span class="pre">!name</span></code>: a string giving the name of the record. This is always
+identical to the key in the JSON root object corresponding to this
+recordâs dictionary. (If the record is anonymous, the name is
+arbitrary.)</li>
+<li><code class="docutils literal notranslate"><span class="pre">!anonymous</span></code>: a boolean indicating whether the recordâs name was
+specified by the TableGen input (if it is <code class="docutils literal notranslate"><span class="pre">false</span></code>), or invented by
+TableGen itself (if <code class="docutils literal notranslate"><span class="pre">true</span></code>).</li>
+</ul>
+<p>For each variable defined in a record, the <code class="docutils literal notranslate"><span class="pre">def</span></code> object for that
+record also has a key for the variable name. The corresponding value
+is a translation into JSON of the variableâs value, using the
+conventions described below.</p>
+<p>Some TableGen data types are translated directly into the
+corresponding JSON type:</p>
+<ul class="simple">
+<li>A completely undefined value (e.g. for a variable declared without
+initializer in some superclass of this record, and never initialized
+by the record itself or any other superclass) is emitted as the JSON
+<code class="docutils literal notranslate"><span class="pre">null</span></code> value.</li>
+<li><code class="docutils literal notranslate"><span class="pre">int</span></code> and <code class="docutils literal notranslate"><span class="pre">bit</span></code> values are emitted as numbers. Note that
+TableGen <code class="docutils literal notranslate"><span class="pre">int</span></code> values are capable of holding integers too large to
+be exactly representable in IEEE double precision. The integer
+literal in the JSON output will show the full exact integer value.
+So if you need to retrieve large integers with full precision, you
+should use a JSON reader capable of translating such literals back
+into 64-bit integers without losing precision, such as Pythonâs
+standard <code class="docutils literal notranslate"><span class="pre">json</span></code> module.</li>
+<li><code class="docutils literal notranslate"><span class="pre">string</span></code> and <code class="docutils literal notranslate"><span class="pre">code</span></code> values are emitted as JSON strings.</li>
+<li><code class="docutils literal notranslate"><span class="pre">list<T></span></code> values, for any element type <code class="docutils literal notranslate"><span class="pre">T</span></code>, are emitted as JSON
+arrays. Each element of the array is represented in turn using these
+same conventions.</li>
+<li><code class="docutils literal notranslate"><span class="pre">bits</span></code> values are also emitted as arrays. A <code class="docutils literal notranslate"><span class="pre">bits</span></code> array is
+ordered from least-significant bit to most-significant. So the
+element with index <code class="docutils literal notranslate"><span class="pre">i</span></code> corresponds to the bit described as
+<code class="docutils literal notranslate"><span class="pre">x{i}</span></code> in TableGen source. However, note that this means that
+scripting languages are likely to <em>display</em> the array in the
+opposite order from the way it appears in the TableGen source or in
+the diagnostic <code class="docutils literal notranslate"><span class="pre">-print-records</span></code> output.</li>
+</ul>
+<p>All other TableGen value types are emitted as a JSON object,
+containing two standard fields: <code class="docutils literal notranslate"><span class="pre">kind</span></code> is a discriminator describing
+which kind of value the object represents, and <code class="docutils literal notranslate"><span class="pre">printable</span></code> is a
+string giving the same representation of the value that would appear
+in <code class="docutils literal notranslate"><span class="pre">-print-records</span></code>.</p>
+<ul class="simple">
+<li>A reference to a <code class="docutils literal notranslate"><span class="pre">def</span></code> object has <code class="docutils literal notranslate"><span class="pre">kind=="def"</span></code>, and has an
+extra field <code class="docutils literal notranslate"><span class="pre">def</span></code> giving the name of the object referred to.</li>
+<li>A reference to another variable in the same record has
+<code class="docutils literal notranslate"><span class="pre">kind=="var"</span></code>, and has an extra field <code class="docutils literal notranslate"><span class="pre">var</span></code> giving the name of
+the variable referred to.</li>
+<li>A reference to a specific bit of a <code class="docutils literal notranslate"><span class="pre">bits</span></code>-typed variable in the
+same record has <code class="docutils literal notranslate"><span class="pre">kind=="varbit"</span></code>, and has two extra fields:
+<code class="docutils literal notranslate"><span class="pre">var</span></code> gives the name of the variable referred to, and <code class="docutils literal notranslate"><span class="pre">index</span></code>
+gives the index of the bit.</li>
+<li>A value of type <code class="docutils literal notranslate"><span class="pre">dag</span></code> has <code class="docutils literal notranslate"><span class="pre">kind=="dag"</span></code>, and has two extra
+fields. <code class="docutils literal notranslate"><span class="pre">operator</span></code> gives the initial value after the opening
+parenthesis of the dag initializer; <code class="docutils literal notranslate"><span class="pre">args</span></code> is an array giving the
+following arguments. The elements of <code class="docutils literal notranslate"><span class="pre">args</span></code> are arrays of length
+2, giving the value of each argument followed by its colon-suffixed
+name (if any). For example, in the JSON representation of the dag
+value <code class="docutils literal notranslate"><span class="pre">(Op</span> <span class="pre">22,</span> <span class="pre">"hello":$foo)</span></code> (assuming that <code class="docutils literal notranslate"><span class="pre">Op</span></code> is the name of
+a record defined elsewhere with a <code class="docutils literal notranslate"><span class="pre">def</span></code> statement):<ul>
+<li><code class="docutils literal notranslate"><span class="pre">operator</span></code> will be an object in which <code class="docutils literal notranslate"><span class="pre">kind=="def"</span></code> and
+<code class="docutils literal notranslate"><span class="pre">def=="Op"</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">args</span></code> will be the array <code class="docutils literal notranslate"><span class="pre">[[22,</span> <span class="pre">null],</span> <span class="pre">["hello",</span> <span class="pre">"foo"]]</span></code>.</li>
+</ul>
+</li>
+<li>If any other kind of value or complicated expression appears in the
+output, it will have <code class="docutils literal notranslate"><span class="pre">kind=="complex"</span></code>, and no additional fields.
+These values are not expected to be needed by backends. The standard
+<code class="docutils literal notranslate"><span class="pre">printable</span></code> field can be used to extract a representation of them
+in TableGen source syntax if necessary.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="how-to-write-a-back-end">
+<h2><a class="toc-backref" href="#id53">How to write a back-end</a><a class="headerlink" href="#how-to-write-a-back-end" title="Permalink to this headline">¶</a></h2>
+<p>TODO.</p>
+<p>Until we get a step-by-step HowTo for writing TableGen backends, you can at
+least grab the boilerplate (build system, new files, etc.) from Clangâs
+r173931.</p>
+<p>TODO: How they work, how to write one. This section should not contain details
+about any particular backend, except maybe <code class="docutils literal notranslate"><span class="pre">-print-enums</span></code> as an example. This
+should highlight the APIs in <code class="docutils literal notranslate"><span class="pre">TableGen/Record.h</span></code>.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="LangRef.html" title="TableGen Language Reference"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="index.html" title="TableGen"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGen/Deficiencies.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGen/Deficiencies.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGen/Deficiencies.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGen/Deficiencies.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,118 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen Deficiencies — LLVM 9 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" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></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>
+ <script type="text/javascript" src="../_static/language_data.js"></script>
+ <link rel="index" title="Index" href="../genindex.html" />
+ <link rel="search" title="Search" href="../search.html" />
+ <link rel="next" title="Debugging JIT-ed Code With GDB" href="../DebuggingJITedCode.html" />
+ <link rel="prev" title="TableGen Language Introduction" href="LangIntro.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" role="navigation" aria-label="related navigation">
+ <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="../DebuggingJITedCode.html" title="Debugging JIT-ed Code With GDB"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="LangIntro.html" title="TableGen Language Introduction"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="tablegen-deficiencies">
+<h1>TableGen Deficiencies<a class="headerlink" href="#tablegen-deficiencies" 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="#known-problems" id="id2">Known Problems</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>Despite being very generic, TableGen has some deficiencies that have been
+pointed out numerous times. The common theme is that, while TableGen allows
+you to build Domain-Specific-Languages, the final languages that you create
+lack the power of other DSLs, which in turn increase considerably the size
+and complexity of TableGen files.</p>
+<p>At the same time, TableGen allows you to create virtually any meaning of
+the basic concepts via custom-made back-ends, which can pervert the original
+design and make it very hard for newcomers to understand it.</p>
+<p>There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others suggesting we should move to more
+powerful DSLs designed with specific purposes, or even re-using existing
+DSLs.</p>
+</div>
+<div class="section" id="known-problems">
+<h2><a class="toc-backref" href="#id2">Known Problems</a><a class="headerlink" href="#known-problems" title="Permalink to this headline">¶</a></h2>
+<p>TODO: Add here frequently asked questions about why TableGen doesnât do
+what you want, how it might, and how we could extend/restrict it to
+be more use friendly.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="../DebuggingJITedCode.html" title="Debugging JIT-ed Code With GDB"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="LangIntro.html" title="TableGen Language Introduction"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGen/LangIntro.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGen/LangIntro.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGen/LangIntro.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGen/LangIntro.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,717 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen Language Introduction — LLVM 9 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" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></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>
+ <script type="text/javascript" src="../_static/language_data.js"></script>
+ <link rel="index" title="Index" href="../genindex.html" />
+ <link rel="search" title="Search" href="../search.html" />
+ <link rel="next" title="TableGen Deficiencies" href="Deficiencies.html" />
+ <link rel="prev" title="TableGen Language Reference" 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" role="navigation" aria-label="related navigation">
+ <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="Deficiencies.html" title="TableGen Deficiencies"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="LangRef.html" title="TableGen Language Reference"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="tablegen-language-introduction">
+<h1>TableGen Language Introduction<a class="headerlink" href="#tablegen-language-introduction" 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="id4">Introduction</a></li>
+<li><a class="reference internal" href="#tablegen-syntax" id="id5">TableGen syntax</a><ul>
+<li><a class="reference internal" href="#tablegen-primitives" id="id6">TableGen primitives</a><ul>
+<li><a class="reference internal" href="#tablegen-comments" id="id7">TableGen comments</a></li>
+<li><a class="reference internal" href="#the-tablegen-type-system" id="id8">The TableGen type system</a></li>
+<li><a class="reference internal" href="#tablegen-values-and-expressions" id="id9">TableGen values and expressions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#classes-and-definitions" id="id10">Classes and definitions</a><ul>
+<li><a class="reference internal" href="#value-definitions" id="id11">Value definitions</a></li>
+<li><a class="reference internal" href="#let-expressions-within-a-record" id="id12">âletâ expressions</a></li>
+<li><a class="reference internal" href="#class-template-arguments" id="id13">Class template arguments</a></li>
+<li><a class="reference internal" href="#multiclass-definitions-and-instances" id="id14">Multiclass definitions and instances</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#file-scope-entities" id="id15">File scope entities</a><ul>
+<li><a class="reference internal" href="#file-inclusion" id="id16">File inclusion</a></li>
+<li><a class="reference internal" href="#id3" id="id17">âletâ expressions</a></li>
+<li><a class="reference internal" href="#looping" id="id18">Looping</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#code-generator-backend-info" id="id19">Code Generator backend info</a></li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">This document is extremely rough. If you find something lacking, please
+fix it, file a documentation bug, or ask about it on llvm-dev.</p>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id4">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document is not meant to be a normative spec about the TableGen language
+in and of itself (i.e. how to understand a given construct in terms of how
+it affects the final set of records represented by the TableGen file). For
+the formal language specification, see <a class="reference internal" href="LangRef.html"><span class="doc">TableGen Language Reference</span></a>.</p>
+</div>
+<div class="section" id="tablegen-syntax">
+<h2><a class="toc-backref" href="#id5">TableGen syntax</a><a class="headerlink" href="#tablegen-syntax" title="Permalink to this headline">¶</a></h2>
+<p>TableGen doesnât care about the meaning of data (that is up to the backend to
+define), but it does care about syntax, and it enforces a simple type system.
+This section describes the syntax and the constructs allowed in a TableGen file.</p>
+<div class="section" id="tablegen-primitives">
+<h3><a class="toc-backref" href="#id6">TableGen primitives</a><a class="headerlink" href="#tablegen-primitives" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="tablegen-comments">
+<h4><a class="toc-backref" href="#id7">TableGen comments</a><a class="headerlink" href="#tablegen-comments" title="Permalink to this headline">¶</a></h4>
+<p>TableGen supports C++ style â<code class="docutils literal notranslate"><span class="pre">//</span></code>â comments, which run to the end of the
+line, and it also supports <strong>nestable</strong> â<code class="docutils literal notranslate"><span class="pre">/*</span> <span class="pre">*/</span></code>â comments.</p>
+</div>
+<div class="section" id="the-tablegen-type-system">
+<span id="tablegen-type"></span><h4><a class="toc-backref" href="#id8">The TableGen type system</a><a class="headerlink" href="#the-tablegen-type-system" title="Permalink to this headline">¶</a></h4>
+<p>TableGen files are strongly typed, in a simple (but complete) type-system.
+These types are used to perform automatic conversions, check for errors, and to
+help interface designers constrain the input that they allow. Every <a class="reference internal" href="#value-definition">value
+definition</a> is required to have an associated type.</p>
+<p>TableGen supports a mixture of very low-level types (such as <code class="docutils literal notranslate"><span class="pre">bit</span></code>) and very
+high-level types (such as <code class="docutils literal notranslate"><span class="pre">dag</span></code>). This flexibility is what allows it to
+describe a wide range of information conveniently and compactly. The TableGen
+types are:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">bit</span></code></dt>
+<dd>A âbitâ is a boolean value that can hold either 0 or 1.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">int</span></code></dt>
+<dd>The âintâ type represents a simple 32-bit integer value, such as 5.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">string</span></code></dt>
+<dd>The âstringâ type represents an ordered sequence of characters of arbitrary
+length.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">code</span></code></dt>
+<dd>The <cite>code</cite> type represents a code fragment, which can be single/multi-line
+string literal.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">bits<n></span></code></dt>
+<dd>A âbitsâ type is an arbitrary, but fixed, size integer that is broken up
+into individual bits. This type is useful because it can handle some bits
+being defined while others are undefined.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">list<ty></span></code></dt>
+<dd>This type represents a list whose elements are some other type. The
+contained type is arbitrary: it can even be another list type.</dd>
+<dt>Class type</dt>
+<dd>Specifying a class name in a type context means that the defined value must
+be a subclass of the specified class. This is useful in conjunction with
+the <code class="docutils literal notranslate"><span class="pre">list</span></code> type, for example, to constrain the elements of the list to a
+common base class (e.g., a <code class="docutils literal notranslate"><span class="pre">list<Register></span></code> can only contain definitions
+derived from the â<code class="docutils literal notranslate"><span class="pre">Register</span></code>â class).</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">dag</span></code></dt>
+<dd>This type represents a nestable directed graph of elements.</dd>
+</dl>
+<p>To date, these types have been sufficient for describing things that TableGen
+has been used for, but it is straight-forward to extend this list if needed.</p>
+</div>
+<div class="section" id="tablegen-values-and-expressions">
+<span id="tablegen-expressions"></span><h4><a class="toc-backref" href="#id9">TableGen values and expressions</a><a class="headerlink" href="#tablegen-values-and-expressions" title="Permalink to this headline">¶</a></h4>
+<p>TableGen allows for a pretty reasonable number of different expression forms
+when building up values. These forms allow the TableGen file to be written in a
+natural syntax and flavor for the application. The current expression forms
+supported include:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">?</span></code></dt>
+<dd>uninitialized field</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">0b1001011</span></code></dt>
+<dd>binary integer value.
+Note that this is sized by the number of bits given and will not be
+silently extended/truncated.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">7</span></code></dt>
+<dd>decimal integer value</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">0x7F</span></code></dt>
+<dd>hexadecimal integer value</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">"foo"</span></code></dt>
+<dd>a single-line string value, can be assigned to <code class="docutils literal notranslate"><span class="pre">string</span></code> or <code class="docutils literal notranslate"><span class="pre">code</span></code> variable.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">[{</span> <span class="pre">...</span> <span class="pre">}]</span></code></dt>
+<dd>usually called a âcode fragmentâ, but is just a multiline string literal</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">[</span> <span class="pre">X,</span> <span class="pre">Y,</span> <span class="pre">Z</span> <span class="pre">]<type></span></code></dt>
+<dd>list value. <type> is the type of the list element and is usually optional.
+In rare cases, TableGen is unable to deduce the element type in which case
+the user must specify it explicitly.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">{</span> <span class="pre">a,</span> <span class="pre">b,</span> <span class="pre">0b10</span> <span class="pre">}</span></code></dt>
+<dd>initializer for a âbits<4>â value.
+1-bit from âaâ, 1-bit from âbâ, 2-bits from 0b10.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">value</span></code></dt>
+<dd>value reference</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">value{17}</span></code></dt>
+<dd>access to one bit of a value</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">value{15-17}</span></code></dt>
+<dd>access to an ordered sequence of bits of a value, in particular <code class="docutils literal notranslate"><span class="pre">value{15-17}</span></code>
+produces an order that is the reverse of <code class="docutils literal notranslate"><span class="pre">value{17-15}</span></code>.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">DEF</span></code></dt>
+<dd>reference to a record definition</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">CLASS<val</span> <span class="pre">list></span></code></dt>
+<dd>reference to a new anonymous definition of CLASS with the specified template
+arguments.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">X.Y</span></code></dt>
+<dd>reference to the subfield of a value</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">list[4-7,17,2-3]</span></code></dt>
+<dd>A slice of the âlistâ list, including elements 4,5,6,7,17,2, and 3 from it.
+Elements may be included multiple times.</dd>
+</dl>
+<p><code class="docutils literal notranslate"><span class="pre">foreach</span> <span class="pre"><var></span> <span class="pre">=</span> <span class="pre">[</span> <span class="pre"><list></span> <span class="pre">]</span> <span class="pre">in</span> <span class="pre">{</span> <span class="pre"><body></span> <span class="pre">}</span></code></p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">foreach</span> <span class="pre"><var></span> <span class="pre">=</span> <span class="pre">[</span> <span class="pre"><list></span> <span class="pre">]</span> <span class="pre">in</span> <span class="pre"><def></span></code></dt>
+<dd>Replicate <body> or <def>, replacing instances of <var> with each value
+in <list>. <var> is scoped at the level of the <code class="docutils literal notranslate"><span class="pre">foreach</span></code> loop and must
+not conflict with any other object introduced in <body> or <def>. Only
+<code class="docutils literal notranslate"><span class="pre">def</span></code>s and <code class="docutils literal notranslate"><span class="pre">defm</span></code>s are expanded within <body>.</dd>
+</dl>
+<p><code class="docutils literal notranslate"><span class="pre">foreach</span> <span class="pre"><var></span> <span class="pre">=</span> <span class="pre">0-15</span> <span class="pre">in</span> <span class="pre">...</span></code></p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">foreach</span> <span class="pre"><var></span> <span class="pre">=</span> <span class="pre">{0-15,32-47}</span> <span class="pre">in</span> <span class="pre">...</span></code></dt>
+<dd>Loop over ranges of integers. The braces are required for multiple ranges.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">(DEF</span> <span class="pre">a,</span> <span class="pre">b)</span></code></dt>
+<dd>a dag value. The first element is required to be a record definition, the
+remaining elements in the list may be arbitrary other values, including
+nested <code class="docutils literal notranslate"><span class="pre">`dag</span></code>â values.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!con(a,</span> <span class="pre">b,</span> <span class="pre">...)</span></code></dt>
+<dd><p class="first">Concatenate two or more DAG nodes. Their operations must equal.</p>
+<p class="last">Example: !con((op a1:$name1, a2:$name2), (op b1:$name3)) results in
+the DAG node (op a1:$name1, a2:$name2, b1:$name3).</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!dag(op,</span> <span class="pre">children,</span> <span class="pre">names)</span></code></dt>
+<dd><p class="first">Generate a DAG node programmatically. âchildrenâ and ânamesâ must be lists
+of equal length or unset (â?â). ânamesâ must be a âlist<string>â.</p>
+<p>Due to limitations of the type system, âchildrenâ must be a list of items
+of a common type. In practice, this means that they should either have the
+same type or be records with a common superclass. Mixing dag and non-dag
+items is not possible. However, â?â can be used.</p>
+<p class="last">Example: !dag(op, [a1, a2, ?], [âname1â, âname2â, âname3â]) results in
+(op a1:$name1, a2:$name2, ?:$name3).</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!listconcat(a,</span> <span class="pre">b,</span> <span class="pre">...)</span></code></dt>
+<dd>A list value that is the result of concatenating the âaâ and âbâ lists.
+The lists must have the same element type.
+More than two arguments are accepted with the result being the concatenation
+of all the lists given.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!listsplat(a,</span> <span class="pre">size)</span></code></dt>
+<dd>A list value that contains the value <code class="docutils literal notranslate"><span class="pre">a</span></code> <code class="docutils literal notranslate"><span class="pre">size</span></code> times.
+Example: <code class="docutils literal notranslate"><span class="pre">!listsplat(0,</span> <span class="pre">2)</span></code> results in <code class="docutils literal notranslate"><span class="pre">[0,</span> <span class="pre">0]</span></code>.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!strconcat(a,</span> <span class="pre">b,</span> <span class="pre">...)</span></code></dt>
+<dd>A string value that is the result of concatenating the âaâ and âbâ strings.
+More than two arguments are accepted with the result being the concatenation
+of all the strings given.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">str1#str2</span></code></dt>
+<dd>â#â (paste) is a shorthand for !strconcat. It may concatenate things that
+are not quoted strings, in which case an implicit !cast<string> is done on
+the operand of the paste.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!cast<type>(a)</span></code></dt>
+<dd><p class="first">If âaâ is a string, a record of type <em>type</em> obtained by looking up the
+string âaâ in the list of all records defined by the time that all template
+arguments in âaâ are fully resolved.</p>
+<p>For example, if !cast<type>(a) appears in a multiclass definition, or in a
+class instantiated inside of a multiclass definition, and âaâ does not
+reference any template arguments of the multiclass, then a record of name
+âaâ must be instantiated earlier in the source file. If âaâ does reference
+a template argument, then the lookup is delayed until defm statements
+instantiating the multiclass (or later, if the defm occurs in another
+multiclass and template arguments of the inner multiclass that are
+referenced by âaâ are substituted by values that themselves contain
+references to template arguments of the outer multiclass).</p>
+<p>If the type of âaâ does not match <em>type</em>, TableGen aborts with an error.</p>
+<p class="last">Otherwise, perform a normal type cast e.g. between an int and a bit, or
+between record types. This allows casting a record to a subclass, though if
+the types do not match, constant folding will be inhibited. !cast<string>
+is a special case in that the argument can be an int or a record. In the
+latter case, the recordâs name is returned.</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!isa<type>(a)</span></code></dt>
+<dd>Returns an integer: 1 if âaâ is dynamically of the given type, 0 otherwise.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!subst(a,</span> <span class="pre">b,</span> <span class="pre">c)</span></code></dt>
+<dd>If âaâ and âbâ are of string type or are symbol references, substitute âbâ
+for âaâ in âc.â This operation is analogous to $(subst) in GNU make.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!foreach(a,</span> <span class="pre">b,</span> <span class="pre">c)</span></code></dt>
+<dd>For each member of dag or list âbâ apply operator âcâ. âaâ is the name
+of a variable that will be substituted by members of âbâ in âcâ.
+This operation is analogous to $(foreach) in GNU make.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!foldl(start,</span> <span class="pre">lst,</span> <span class="pre">a,</span> <span class="pre">b,</span> <span class="pre">expr)</span></code></dt>
+<dd>Perform a left-fold over âlstâ with the given starting value. âaâ and âbâ
+are variable names which will be substituted in âexprâ. If you think of
+expr as a function f(a,b), the fold will compute
+âf(â¦f(f(start, lst[0]), lst[1]), â¦), lst[n-1])â for a list of length n.
+As usual, âaâ will be of the type of âstartâ, and âbâ will be of the type
+of elements of âlstâ. These types need not be the same, but âexprâ must be
+of the same type as âstartâ.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!head(a)</span></code></dt>
+<dd>The first element of list âa.â</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!tail(a)</span></code></dt>
+<dd>The 2nd-N elements of list âa.â</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!empty(a)</span></code></dt>
+<dd>An integer {0,1} indicating whether list âaâ is empty.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!size(a)</span></code></dt>
+<dd>An integer indicating the number of elements in list âaâ.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!if(a,b,c)</span></code></dt>
+<dd>âbâ if the result of âintâ or âbitâ operator âaâ is nonzero, âcâ otherwise.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!cond(condition_1</span> <span class="pre">:</span> <span class="pre">val1,</span> <span class="pre">condition_2</span> <span class="pre">:</span> <span class="pre">val2,</span> <span class="pre">...,</span> <span class="pre">condition_n</span> <span class="pre">:</span> <span class="pre">valn)</span></code></dt>
+<dd><p class="first">Instead of embedding !if inside !if which can get cumbersome,
+one can use !cond. !cond returns âval1â if the result of âintâ or âbitâ
+operator âcondition1â is nonzero. Otherwise, it checks âcondition2â.
+If âcondition2â is nonzero, returns âval2â, and so on.
+If all conditions are zero, it reports an error.</p>
+<dl class="last docutils">
+<dt>For example, to convert an integer âxâ into a string:</dt>
+<dd>!cond(!lt(x,0) : ânegativeâ, !eq(x,0) : âzeroâ, 1 : âpositiveâ)</dd>
+</dl>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!eq(a,b)</span></code></dt>
+<dd>âbit 1â if string a is equal to string b, 0 otherwise. This only operates
+on string, int and bit objects. Use !cast<string> to compare other types of
+objects.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!ne(a,b)</span></code></dt>
+<dd>The negation of <code class="docutils literal notranslate"><span class="pre">!eq(a,b)</span></code>.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!le(a,b),</span> <span class="pre">!lt(a,b),</span> <span class="pre">!ge(a,b),</span> <span class="pre">!gt(a,b)</span></code></dt>
+<dd>(Signed) comparison of integer values that returns bit 1 or 0 depending on
+the result of the comparison.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!shl(a,b)</span></code> <code class="docutils literal notranslate"><span class="pre">!srl(a,b)</span></code> <code class="docutils literal notranslate"><span class="pre">!sra(a,b)</span></code></dt>
+<dd>The usual shift operators. Operations are on 64-bit integers, the result
+is undefined for shift counts outside [0, 63].</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">!add(a,b,...)</span></code> <code class="docutils literal notranslate"><span class="pre">!mul(a,b,...)</span></code> <code class="docutils literal notranslate"><span class="pre">!and(a,b,...)</span></code> <code class="docutils literal notranslate"><span class="pre">!or(a,b,...)</span></code></dt>
+<dd>The usual arithmetic and binary operators.</dd>
+</dl>
+<p>Note that all of the values have rules specifying how they convert to values
+for different types. These rules allow you to assign a value like â<code class="docutils literal notranslate"><span class="pre">7</span></code>â
+to a â<code class="docutils literal notranslate"><span class="pre">bits<4></span></code>â value, for example.</p>
+</div>
+</div>
+<div class="section" id="classes-and-definitions">
+<h3><a class="toc-backref" href="#id10">Classes and definitions</a><a class="headerlink" href="#classes-and-definitions" title="Permalink to this headline">¶</a></h3>
+<p>As mentioned in the <a class="reference internal" href="index.html"><span class="doc">introduction</span></a>, classes and definitions (collectively known as
+ârecordsâ) in TableGen are the main high-level unit of information that TableGen
+collects. Records are defined with a <code class="docutils literal notranslate"><span class="pre">def</span></code> or <code class="docutils literal notranslate"><span class="pre">class</span></code> keyword, the record
+name, and an optional list of â<a class="reference internal" href="#template-arguments">template arguments</a>â. If the record has
+superclasses, they are specified as a comma separated list that starts with a
+colon character (â<code class="docutils literal notranslate"><span class="pre">:</span></code>â). If <a class="reference internal" href="#value-definitions">value definitions</a> or <a class="reference internal" href="#let-expressions">let expressions</a> are
+needed for the class, they are enclosed in curly braces (â<code class="docutils literal notranslate"><span class="pre">{}</span></code>â); otherwise,
+the record ends with a semicolon.</p>
+<p>Here is a simple TableGen file:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class C { bit V = 1; }
+def X : C;
+def Y : C {
+ string Greeting = "hello";
+}
+</pre></div>
+</div>
+<p>This example defines two definitions, <code class="docutils literal notranslate"><span class="pre">X</span></code> and <code class="docutils literal notranslate"><span class="pre">Y</span></code>, both of which derive from
+the <code class="docutils literal notranslate"><span class="pre">C</span></code> class. Because of this, they both get the <code class="docutils literal notranslate"><span class="pre">V</span></code> bit value. The <code class="docutils literal notranslate"><span class="pre">Y</span></code>
+definition also gets the Greeting member as well.</p>
+<p>In general, classes are useful for collecting together the commonality between a
+group of records and isolating it in a single place. Also, classes permit the
+specification of default values for their subclasses, allowing the subclasses to
+override them as they wish.</p>
+<div class="section" id="value-definitions">
+<span id="value-definition"></span><span id="id1"></span><h4><a class="toc-backref" href="#id11">Value definitions</a><a class="headerlink" href="#value-definitions" title="Permalink to this headline">¶</a></h4>
+<p>Value definitions define named entries in records. A value must be defined
+before it can be referred to as the operand for another value definition or
+before the value is reset with a <a class="reference internal" href="#let-expression">let expression</a>. A value is defined by
+specifying a <a class="reference internal" href="#tablegen-type">TableGen type</a> and a name. If an initial value is available, it
+may be specified after the type with an equal sign. Value definitions require
+terminating semicolons.</p>
+</div>
+<div class="section" id="let-expressions-within-a-record">
+<span id="let-expressions"></span><span id="let-expression"></span><span id="id2"></span><h4><a class="toc-backref" href="#id12">âletâ expressions</a><a class="headerlink" href="#let-expressions-within-a-record" title="Permalink to this headline">¶</a></h4>
+<p>A record-level let expression is used to change the value of a value definition
+in a record. This is primarily useful when a superclass defines a value that a
+derived class or definition wants to override. Let expressions consist of the
+â<code class="docutils literal notranslate"><span class="pre">let</span></code>â keyword followed by a value name, an equal sign (â<code class="docutils literal notranslate"><span class="pre">=</span></code>â), and a new
+value. For example, a new class could be added to the example above, redefining
+the <code class="docutils literal notranslate"><span class="pre">V</span></code> field for all of its subclasses:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class D : C { let V = 0; }
+def Z : D;
+</pre></div>
+</div>
+<p>In this case, the <code class="docutils literal notranslate"><span class="pre">Z</span></code> definition will have a zero value for its <code class="docutils literal notranslate"><span class="pre">V</span></code> value,
+despite the fact that it derives (indirectly) from the <code class="docutils literal notranslate"><span class="pre">C</span></code> class, because the
+<code class="docutils literal notranslate"><span class="pre">D</span></code> class overrode its value.</p>
+<p>References between variables in a record are substituted late, which gives
+<code class="docutils literal notranslate"><span class="pre">let</span></code> expressions unusual power. Consider this admittedly silly example:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class A<int x> {
+ int Y = x;
+ int Yplus1 = !add(Y, 1);
+ int xplus1 = !add(x, 1);
+}
+def Z : A<5> {
+ let Y = 10;
+}
+</pre></div>
+</div>
+<p>The value of <code class="docutils literal notranslate"><span class="pre">Z.xplus1</span></code> will be 6, but the value of <code class="docutils literal notranslate"><span class="pre">Z.Yplus1</span></code> is 11. Use
+this power wisely.</p>
+</div>
+<div class="section" id="class-template-arguments">
+<span id="template-arguments"></span><h4><a class="toc-backref" href="#id13">Class template arguments</a><a class="headerlink" href="#class-template-arguments" title="Permalink to this headline">¶</a></h4>
+<p>TableGen permits the definition of parameterized classes as well as normal
+concrete classes. Parameterized TableGen classes specify a list of variable
+bindings (which may optionally have defaults) that are bound when used. Here is
+a simple example:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class FPFormat<bits<3> val> {
+ bits<3> Value = val;
+}
+def NotFP : FPFormat<0>;
+def ZeroArgFP : FPFormat<1>;
+def OneArgFP : FPFormat<2>;
+def OneArgFPRW : FPFormat<3>;
+def TwoArgFP : FPFormat<4>;
+def CompareFP : FPFormat<5>;
+def CondMovFP : FPFormat<6>;
+def SpecialFP : FPFormat<7>;
+</pre></div>
+</div>
+<p>In this case, template arguments are used as a space efficient way to specify a
+list of âenumeration valuesâ, each with a â<code class="docutils literal notranslate"><span class="pre">Value</span></code>â field set to the specified
+integer.</p>
+<p>The more esoteric forms of <a class="reference internal" href="#tablegen-expressions">TableGen expressions</a> are useful in conjunction
+with template arguments. As an example:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class ModRefVal<bits<2> val> {
+ bits<2> Value = val;
+}
+
+def None : ModRefVal<0>;
+def Mod : ModRefVal<1>;
+def Ref : ModRefVal<2>;
+def ModRef : ModRefVal<3>;
+
+class Value<ModRefVal MR> {
+ // Decode some information into a more convenient format, while providing
+ // a nice interface to the user of the "Value" class.
+ bit isMod = MR.Value{0};
+ bit isRef = MR.Value{1};
+
+ // other stuff...
+}
+
+// Example uses
+def bork : Value<Mod>;
+def zork : Value<Ref>;
+def hork : Value<ModRef>;
+</pre></div>
+</div>
+<p>This is obviously a contrived example, but it shows how template arguments can
+be used to decouple the interface provided to the user of the class from the
+actual internal data representation expected by the class. In this case,
+running <code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span></code> on the example prints the following definitions:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def bork { // Value
+ bit isMod = 1;
+ bit isRef = 0;
+}
+def hork { // Value
+ bit isMod = 1;
+ bit isRef = 1;
+}
+def zork { // Value
+ bit isMod = 0;
+ bit isRef = 1;
+}
+</pre></div>
+</div>
+<p>This shows that TableGen was able to dig into the argument and extract a piece
+of information that was requested by the designer of the âValueâ class. For
+more realistic examples, please see existing users of TableGen, such as the X86
+backend.</p>
+</div>
+<div class="section" id="multiclass-definitions-and-instances">
+<h4><a class="toc-backref" href="#id14">Multiclass definitions and instances</a><a class="headerlink" href="#multiclass-definitions-and-instances" title="Permalink to this headline">¶</a></h4>
+<p>While classes with template arguments are a good way to factor commonality
+between two instances of a definition, multiclasses allow a convenient notation
+for defining multiple definitions at once (instances of implicitly constructed
+classes). For example, consider an 3-address instruction set whose instructions
+come in two forms: â<code class="docutils literal notranslate"><span class="pre">reg</span> <span class="pre">=</span> <span class="pre">reg</span> <span class="pre">op</span> <span class="pre">reg</span></code>â and â<code class="docutils literal notranslate"><span class="pre">reg</span> <span class="pre">=</span> <span class="pre">reg</span> <span class="pre">op</span> <span class="pre">imm</span></code>â
+(e.g. SPARC). In this case, youâd like to specify in one place that this
+commonality exists, then in a separate place indicate what all the ops are.</p>
+<p>Here is an example TableGen fragment that shows this idea:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def ops;
+def GPR;
+def Imm;
+class inst<int opc, string asmstr, dag operandlist>;
+
+multiclass ri_inst<int opc, string asmstr> {
+ def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+ def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+}
+
+// Instantiations of the ri_inst multiclass.
+defm ADD : ri_inst<0b111, "add">;
+defm SUB : ri_inst<0b101, "sub">;
+defm MUL : ri_inst<0b100, "mul">;
+...
+</pre></div>
+</div>
+<p>The name of the resultant definitions has the multidef fragment names appended
+to them, so this defines <code class="docutils literal notranslate"><span class="pre">ADD_rr</span></code>, <code class="docutils literal notranslate"><span class="pre">ADD_ri</span></code>, <code class="docutils literal notranslate"><span class="pre">SUB_rr</span></code>, etc. A defm may
+inherit from multiple multiclasses, instantiating definitions from each
+multiclass. Using a multiclass this way is exactly equivalent to instantiating
+the classes multiple times yourself, e.g. by writing:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def ops;
+def GPR;
+def Imm;
+class inst<int opc, string asmstr, dag operandlist>;
+
+class rrinst<int opc, string asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+
+class riinst<int opc, string asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+
+// Instantiations of the ri_inst multiclass.
+def ADD_rr : rrinst<0b111, "add">;
+def ADD_ri : riinst<0b111, "add">;
+def SUB_rr : rrinst<0b101, "sub">;
+def SUB_ri : riinst<0b101, "sub">;
+def MUL_rr : rrinst<0b100, "mul">;
+def MUL_ri : riinst<0b100, "mul">;
+...
+</pre></div>
+</div>
+<p>A <code class="docutils literal notranslate"><span class="pre">defm</span></code> can also be used inside a multiclass providing several levels of
+multiclass instantiations.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class Instruction<bits<4> opc, string Name> {
+ bits<4> opcode = opc;
+ string name = Name;
+}
+
+multiclass basic_r<bits<4> opc> {
+ def rr : Instruction<opc, "rr">;
+ def rm : Instruction<opc, "rm">;
+}
+
+multiclass basic_s<bits<4> opc> {
+ defm SS : basic_r<opc>;
+ defm SD : basic_r<opc>;
+ def X : Instruction<opc, "x">;
+}
+
+multiclass basic_p<bits<4> opc> {
+ defm PS : basic_r<opc>;
+ defm PD : basic_r<opc>;
+ def Y : Instruction<opc, "y">;
+}
+
+defm ADD : basic_s<0xf>, basic_p<0xf>;
+...
+
+// Results
+def ADDPDrm { ...
+def ADDPDrr { ...
+def ADDPSrm { ...
+def ADDPSrr { ...
+def ADDSDrm { ...
+def ADDSDrr { ...
+def ADDY { ...
+def ADDX { ...
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">defm</span></code> declarations can inherit from classes too, the rule to follow is that
+the class list must start after the last multiclass, and there must be at least
+one multiclass before them.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class XD { bits<4> Prefix = 11; }
+class XS { bits<4> Prefix = 12; }
+
+class I<bits<4> op> {
+ bits<4> opcode = op;
+}
+
+multiclass R {
+ def rr : I<4>;
+ def rm : I<2>;
+}
+
+multiclass Y {
+ defm SS : R, XD;
+ defm SD : R, XS;
+}
+
+defm Instr : Y;
+
+// Results
+def InstrSDrm {
+ bits<4> opcode = { 0, 0, 1, 0 };
+ bits<4> Prefix = { 1, 1, 0, 0 };
+}
+...
+def InstrSSrr {
+ bits<4> opcode = { 0, 1, 0, 0 };
+ bits<4> Prefix = { 1, 0, 1, 1 };
+}
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="file-scope-entities">
+<h3><a class="toc-backref" href="#id15">File scope entities</a><a class="headerlink" href="#file-scope-entities" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="file-inclusion">
+<h4><a class="toc-backref" href="#id16">File inclusion</a><a class="headerlink" href="#file-inclusion" title="Permalink to this headline">¶</a></h4>
+<p>TableGen supports the â<code class="docutils literal notranslate"><span class="pre">include</span></code>â token, which textually substitutes the
+specified file in place of the include directive. The filename should be
+specified as a double quoted string immediately after the â<code class="docutils literal notranslate"><span class="pre">include</span></code>â keyword.
+Example:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>include "foo.td"
+</pre></div>
+</div>
+</div>
+<div class="section" id="id3">
+<h4><a class="toc-backref" href="#id17">âletâ expressions</a><a class="headerlink" href="#id3" title="Permalink to this headline">¶</a></h4>
+<p>âLetâ expressions at file scope are similar to <a class="reference internal" href="#let-expressions-within-a-record">âletâ expressions within a
+record</a>, except they can specify a value binding for multiple records at a
+time, and may be useful in certain other cases. File-scope let expressions are
+really just another way that TableGen allows the end-user to factor out
+commonality from the records.</p>
+<p>File-scope âletâ expressions take a comma-separated list of bindings to apply,
+and one or more records to bind the values in. Here are some examples:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
+ def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
+
+let isCall = 1 in
+ // All calls clobber the non-callee saved registers...
+ let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
+ MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
+ XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
+ def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
+ "call\t${dst:call}", []>;
+ def CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
+ "call\t{*}$dst", [(X86call GR32:$dst)]>;
+ def CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
+ "call\t{*}$dst", []>;
+ }
+</pre></div>
+</div>
+<p>File-scope âletâ expressions are often useful when a couple of definitions need
+to be added to several records, and the records do not otherwise need to be
+opened, as in the case with the <code class="docutils literal notranslate"><span class="pre">CALL*</span></code> instructions above.</p>
+<p>Itâs also possible to use âletâ expressions inside multiclasses, providing more
+ways to factor out commonality from the records, specially if using several
+levels of multiclass instantiations. This also avoids the need of using âletâ
+expressions within subsequent records inside a multiclass.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>multiclass basic_r<bits<4> opc> {
+ let Predicates = [HasSSE2] in {
+ def rr : Instruction<opc, "rr">;
+ def rm : Instruction<opc, "rm">;
+ }
+ let Predicates = [HasSSE3] in
+ def rx : Instruction<opc, "rx">;
+}
+
+multiclass basic_ss<bits<4> opc> {
+ let IsDouble = 0 in
+ defm SS : basic_r<opc>;
+
+ let IsDouble = 1 in
+ defm SD : basic_r<opc>;
+}
+
+defm ADD : basic_ss<0xf>;
+</pre></div>
+</div>
+</div>
+<div class="section" id="looping">
+<h4><a class="toc-backref" href="#id18">Looping</a><a class="headerlink" href="#looping" title="Permalink to this headline">¶</a></h4>
+<p>TableGen supports the â<code class="docutils literal notranslate"><span class="pre">foreach</span></code>â block, which textually replicates the loop
+body, substituting iterator values for iterator references in the body.
+Example:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>foreach i = [0, 1, 2, 3] in {
+ def R#i : Register<...>;
+ def F#i : Register<...>;
+}
+</pre></div>
+</div>
+<p>This will create objects <code class="docutils literal notranslate"><span class="pre">R0</span></code>, <code class="docutils literal notranslate"><span class="pre">R1</span></code>, <code class="docutils literal notranslate"><span class="pre">R2</span></code> and <code class="docutils literal notranslate"><span class="pre">R3</span></code>. <code class="docutils literal notranslate"><span class="pre">foreach</span></code> blocks
+may be nested. If there is only one item in the body the braces may be
+elided:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>foreach i = [0, 1, 2, 3] in
+ def R#i : Register<...>;
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+<div class="section" id="code-generator-backend-info">
+<h2><a class="toc-backref" href="#id19">Code Generator backend info</a><a class="headerlink" href="#code-generator-backend-info" title="Permalink to this headline">¶</a></h2>
+<p>Expressions used by code generator to describe instructions and isel patterns:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">(implicit</span> <span class="pre">a)</span></code></dt>
+<dd>an implicitly defined physical register. This tells the dag instruction
+selection emitter the input patternâs extra definitions matches implicit
+physical register definitions.</dd>
+</dl>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="Deficiencies.html" title="TableGen Deficiencies"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="LangRef.html" title="TableGen Language Reference"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGen/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGen/LangRef.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGen/LangRef.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGen/LangRef.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,550 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen Language Reference — LLVM 9 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" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></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>
+ <script type="text/javascript" src="../_static/language_data.js"></script>
+ <link rel="index" title="Index" href="../genindex.html" />
+ <link rel="search" title="Search" href="../search.html" />
+ <link rel="next" title="TableGen Language Introduction" href="LangIntro.html" />
+ <link rel="prev" title="TableGen BackEnds" href="BackEnds.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" role="navigation" aria-label="related navigation">
+ <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="LangIntro.html" title="TableGen Language Introduction"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="BackEnds.html" title="TableGen BackEnds"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="tablegen-language-reference">
+<h1>TableGen Language Reference<a class="headerlink" href="#tablegen-language-reference" 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="id10">Introduction</a></li>
+<li><a class="reference internal" href="#notation" id="id11">Notation</a></li>
+<li><a class="reference internal" href="#lexical-analysis" id="id12">Lexical Analysis</a></li>
+<li><a class="reference internal" href="#syntax" id="id13">Syntax</a><ul>
+<li><a class="reference internal" href="#classes" id="id14"><code class="docutils literal notranslate"><span class="pre">class</span></code>es</a></li>
+<li><a class="reference internal" href="#declarations" id="id15">Declarations</a></li>
+<li><a class="reference internal" href="#types" id="id16">Types</a></li>
+<li><a class="reference internal" href="#values" id="id17">Values</a></li>
+<li><a class="reference internal" href="#bodies" id="id18">Bodies</a></li>
+<li><a class="reference internal" href="#def" id="id19"><code class="docutils literal notranslate"><span class="pre">def</span></code></a></li>
+<li><a class="reference internal" href="#defm" id="id20"><code class="docutils literal notranslate"><span class="pre">defm</span></code></a></li>
+<li><a class="reference internal" href="#defset" id="id21"><code class="docutils literal notranslate"><span class="pre">defset</span></code></a></li>
+<li><a class="reference internal" href="#foreach" id="id22"><code class="docutils literal notranslate"><span class="pre">foreach</span></code></a></li>
+<li><a class="reference internal" href="#top-level-let" id="id23">Top-Level <code class="docutils literal notranslate"><span class="pre">let</span></code></a></li>
+<li><a class="reference internal" href="#multiclass" id="id24"><code class="docutils literal notranslate"><span class="pre">multiclass</span></code></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#preprocessing-support" id="id25">Preprocessing Support</a></li>
+</ul>
+</div>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">This document is extremely rough. If you find something lacking, please
+fix it, file a documentation bug, or ask about it on llvm-dev.</p>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id10">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document is meant to be a normative spec about the TableGen language
+in and of itself (i.e. how to understand a given construct in terms of how
+it affects the final set of records represented by the TableGen file). If
+you are unsure if this document is really what you are looking for, please
+read the <a class="reference internal" href="index.html"><span class="doc">introduction to TableGen</span></a> first.</p>
+</div>
+<div class="section" id="notation">
+<h2><a class="toc-backref" href="#id11">Notation</a><a class="headerlink" href="#notation" title="Permalink to this headline">¶</a></h2>
+<p>The lexical and syntax notation used here is intended to imitate
+<a class="reference external" href="http://docs.python.org/py3k/reference/introduction.html#notation">Pythonâs</a>. In particular, for lexical definitions, the productions
+operate at the character level and there is no implied whitespace between
+elements. The syntax definitions operate at the token level, so there is
+implied whitespace between tokens.</p>
+</div>
+<div class="section" id="lexical-analysis">
+<h2><a class="toc-backref" href="#id12">Lexical Analysis</a><a class="headerlink" href="#lexical-analysis" title="Permalink to this headline">¶</a></h2>
+<p>TableGen supports BCPL (<code class="docutils literal notranslate"><span class="pre">//</span> <span class="pre">...</span></code>) and nestable C-style (<code class="docutils literal notranslate"><span class="pre">/*</span> <span class="pre">...</span> <span class="pre">*/</span></code>)
+comments. TableGen also provides simple <a class="reference internal" href="#preprocessing-support">Preprocessing Support</a>.</p>
+<p>The following is a listing of the basic punctuation tokens:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>- + [ ] { } ( ) < > : ; . = ? #
+</pre></div>
+</div>
+<p>Numeric literals take one of the following forms:</p>
+<pre>
+<strong id="grammar-token-tokinteger">TokInteger </strong> ::= <a class="reference internal" href="#grammar-token-decimalinteger"><code class="xref docutils literal notranslate"><span class="pre">DecimalInteger</span></code></a> | <a class="reference internal" href="#grammar-token-hexinteger"><code class="xref docutils literal notranslate"><span class="pre">HexInteger</span></code></a> | <a class="reference internal" href="#grammar-token-bininteger"><code class="xref docutils literal notranslate"><span class="pre">BinInteger</span></code></a>
+<strong id="grammar-token-decimalinteger">DecimalInteger</strong> ::= ["+" | "-"] ("0"..."9")+
+<strong id="grammar-token-hexinteger">HexInteger </strong> ::= "0x" ("0"..."9" | "a"..."f" | "A"..."F")+
+<strong id="grammar-token-bininteger">BinInteger </strong> ::= "0b" ("0" | "1")+
+</pre>
+<p>One aspect to note is that the <a class="reference internal" href="#grammar-token-decimalinteger"><code class="xref std std-token docutils literal notranslate"><span class="pre">DecimalInteger</span></code></a> token <em>includes</em> the
+<code class="docutils literal notranslate"><span class="pre">+</span></code> or <code class="docutils literal notranslate"><span class="pre">-</span></code>, as opposed to having <code class="docutils literal notranslate"><span class="pre">+</span></code> and <code class="docutils literal notranslate"><span class="pre">-</span></code> be unary operators as
+most languages do.</p>
+<p>Also note that <a class="reference internal" href="#grammar-token-bininteger"><code class="xref std std-token docutils literal notranslate"><span class="pre">BinInteger</span></code></a> creates a value of type <code class="docutils literal notranslate"><span class="pre">bits<n></span></code>
+(where <code class="docutils literal notranslate"><span class="pre">n</span></code> is the number of bits). This will implicitly convert to
+integers when needed.</p>
+<p>TableGen has identifier-like tokens:</p>
+<pre>
+<strong id="grammar-token-ualpha">ualpha </strong> ::= "a"..."z" | "A"..."Z" | "_"
+<strong id="grammar-token-tokidentifier">TokIdentifier</strong> ::= ("0"..."9")* <a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> (<a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> | "0"..."9")*
+<strong id="grammar-token-tokvarname">TokVarName </strong> ::= "$" <a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> (<a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> | "0"..."9")*
+</pre>
+<p>Note that unlike most languages, TableGen allows <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref std std-token docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> to
+begin with a number. In case of ambiguity, a token will be interpreted as a
+numeric literal rather than an identifier.</p>
+<p>TableGen also has two string-like literals:</p>
+<pre>
+<strong id="grammar-token-tokstring">TokString </strong> ::= '"' <non-'"' characters and C-like escapes> '"'
+<strong id="grammar-token-tokcodefragment">TokCodeFragment</strong> ::= "[{" <shortest text not containing "}]"> "}]"
+</pre>
+<p><a class="reference internal" href="#grammar-token-tokcodefragment"><code class="xref std std-token docutils literal notranslate"><span class="pre">TokCodeFragment</span></code></a> is essentially a multiline string literal
+delimited by <code class="docutils literal notranslate"><span class="pre">[{</span></code> and <code class="docutils literal notranslate"><span class="pre">}]</span></code>.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p>The current implementation accepts the following C-like escapes:</p>
+<div class="last highlight-default notranslate"><div class="highlight"><pre><span></span>\\ \<span class="s1">' </span><span class="se">\"</span><span class="s1"> </span><span class="se">\t</span><span class="s1"> </span><span class="se">\n</span>
+</pre></div>
+</div>
+</div>
+<p>TableGen also has the following keywords:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bit</span> <span class="n">bits</span> <span class="k">class</span> <span class="nc">code</span> <span class="n">dag</span>
+<span class="k">def</span> <span class="nf">foreach</span> <span class="n">defm</span> <span class="n">field</span> <span class="ow">in</span>
+<span class="nb">int</span> <span class="n">let</span> <span class="nb">list</span> <span class="n">multiclass</span> <span class="n">string</span>
+</pre></div>
+</div>
+<p>TableGen also has âbang operatorsâ which have a
+wide variety of meanings:</p>
+<pre>
+<strong id="grammar-token-bangoperator">BangOperator</strong> ::= one of
+ !eq !if !head !tail !con
+ !add !shl !sra !srl !and
+ !or !empty !subst !foreach !strconcat
+ !cast !listconcat !size !foldl
+ !isa !dag !le !lt !ge
+ !gt !ne !mul !listsplat
+</pre>
+<p>TableGen also has !cond operator that needs a slightly different
+syntax compared to other âbang operatorsâ:</p>
+<pre>
+<strong id="grammar-token-condoperator">CondOperator</strong> ::= !cond
+</pre>
+</div>
+<div class="section" id="syntax">
+<h2><a class="toc-backref" href="#id13">Syntax</a><a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
+<p>TableGen has an <code class="docutils literal notranslate"><span class="pre">include</span></code> mechanism. It does not play a role in the
+syntax per se, since it is lexically replaced with the contents of the
+included file.</p>
+<pre>
+<strong id="grammar-token-includedirective">IncludeDirective</strong> ::= "include" <a class="reference internal" href="#grammar-token-tokstring"><code class="xref docutils literal notranslate"><span class="pre">TokString</span></code></a>
+</pre>
+<p>TableGenâs top-level production consists of âobjectsâ.</p>
+<pre>
+<strong id="grammar-token-tablegenfile">TableGenFile</strong> ::= <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>*
+<strong id="grammar-token-object">Object </strong> ::= <a class="reference internal" href="#grammar-token-class"><code class="xref docutils literal notranslate"><span class="pre">Class</span></code></a> | <a class="reference internal" href="#grammar-token-def"><code class="xref docutils literal notranslate"><span class="pre">Def</span></code></a> | <a class="reference internal" href="#grammar-token-defm"><code class="xref docutils literal notranslate"><span class="pre">Defm</span></code></a> | <a class="reference internal" href="#grammar-token-defset"><code class="xref docutils literal notranslate"><span class="pre">Defset</span></code></a> | <a class="reference internal" href="#grammar-token-let"><code class="xref docutils literal notranslate"><span class="pre">Let</span></code></a> | <a class="reference internal" href="#grammar-token-multiclass"><code class="xref docutils literal notranslate"><span class="pre">MultiClass</span></code></a> |
+</pre>
+<div class="section" id="classes">
+<h3><a class="toc-backref" href="#id14"><code class="docutils literal notranslate"><span class="pre">class</span></code>es</a><a class="headerlink" href="#classes" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-class">Class </strong> ::= "class" <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> [<a class="reference internal" href="#grammar-token-templatearglist"><code class="xref docutils literal notranslate"><span class="pre">TemplateArgList</span></code></a>] <a class="reference internal" href="#grammar-token-objectbody"><code class="xref docutils literal notranslate"><span class="pre">ObjectBody</span></code></a>
+<strong id="grammar-token-templatearglist">TemplateArgList</strong> ::= "<" <a class="reference internal" href="#grammar-token-declaration"><code class="xref docutils literal notranslate"><span class="pre">Declaration</span></code></a> ("," <a class="reference internal" href="#grammar-token-declaration"><code class="xref docutils literal notranslate"><span class="pre">Declaration</span></code></a>)* ">"
+</pre>
+<p>A <code class="docutils literal notranslate"><span class="pre">class</span></code> declaration creates a record which other records can inherit
+from. A class can be parametrized by a list of âtemplate argumentsâ, whose
+values can be used in the class body.</p>
+<p>A given class can only be defined once. A <code class="docutils literal notranslate"><span class="pre">class</span></code> declaration is
+considered to define the class if any of the following is true:</p>
+<ol class="arabic simple">
+<li>The <a class="reference internal" href="#grammar-token-templatearglist"><code class="xref std std-token docutils literal notranslate"><span class="pre">TemplateArgList</span></code></a> is present.</li>
+<li>The <a class="reference internal" href="#grammar-token-body"><code class="xref std std-token docutils literal notranslate"><span class="pre">Body</span></code></a> in the <a class="reference internal" href="#grammar-token-objectbody"><code class="xref std std-token docutils literal notranslate"><span class="pre">ObjectBody</span></code></a> is present and is not empty.</li>
+<li>The <a class="reference internal" href="#grammar-token-baseclasslist"><code class="xref std std-token docutils literal notranslate"><span class="pre">BaseClassList</span></code></a> in the <a class="reference internal" href="#grammar-token-objectbody"><code class="xref std std-token docutils literal notranslate"><span class="pre">ObjectBody</span></code></a> is present.</li>
+</ol>
+<p>You can declare an empty class by giving an empty <a class="reference internal" href="#grammar-token-templatearglist"><code class="xref std std-token docutils literal notranslate"><span class="pre">TemplateArgList</span></code></a>
+and an empty <a class="reference internal" href="#grammar-token-objectbody"><code class="xref std std-token docutils literal notranslate"><span class="pre">ObjectBody</span></code></a>. This can serve as a restricted form of
+forward declaration: note that records deriving from the forward-declared
+class will inherit no fields from it since the record expansion is done
+when the record is parsed.</p>
+<p>Every class has an implicit template argument called <code class="docutils literal notranslate"><span class="pre">NAME</span></code>, which is set
+to the name of the instantiating <code class="docutils literal notranslate"><span class="pre">def</span></code> or <code class="docutils literal notranslate"><span class="pre">defm</span></code>. The result is undefined
+if the class is instantiated by an anonymous record.</p>
+</div>
+<div class="section" id="declarations">
+<h3><a class="toc-backref" href="#id15">Declarations</a><a class="headerlink" href="#declarations" title="Permalink to this headline">¶</a></h3>
+<p>The declaration syntax is pretty much what you would expect as a C++
+programmer.</p>
+<pre>
+<strong id="grammar-token-declaration">Declaration</strong> ::= <a class="reference internal" href="#grammar-token-type"><code class="xref docutils literal notranslate"><span class="pre">Type</span></code></a> <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> ["=" <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>]
+</pre>
+<p>It assigns the value to the identifier.</p>
+</div>
+<div class="section" id="types">
+<h3><a class="toc-backref" href="#id16">Types</a><a class="headerlink" href="#types" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-type">Type </strong> ::= "string" | "code" | "bit" | "int" | "dag"
+ | "bits" "<" <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a> ">"
+ | "list" "<" <a class="reference internal" href="#grammar-token-type"><code class="xref docutils literal notranslate"><span class="pre">Type</span></code></a> ">"
+ | <a class="reference internal" href="#grammar-token-classid"><code class="xref docutils literal notranslate"><span class="pre">ClassID</span></code></a>
+<strong id="grammar-token-classid">ClassID</strong> ::= <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a>
+</pre>
+<p>Both <code class="docutils literal notranslate"><span class="pre">string</span></code> and <code class="docutils literal notranslate"><span class="pre">code</span></code> correspond to the string type; the difference
+is purely to indicate programmer intention.</p>
+<p>The <a class="reference internal" href="#grammar-token-classid"><code class="xref std std-token docutils literal notranslate"><span class="pre">ClassID</span></code></a> must identify a class that has been previously
+declared or defined.</p>
+</div>
+<div class="section" id="values">
+<h3><a class="toc-backref" href="#id17">Values</a><a class="headerlink" href="#values" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-value">Value </strong> ::= <a class="reference internal" href="#grammar-token-simplevalue"><code class="xref docutils literal notranslate"><span class="pre">SimpleValue</span></code></a> <a class="reference internal" href="#grammar-token-valuesuffix"><code class="xref docutils literal notranslate"><span class="pre">ValueSuffix</span></code></a>*
+<strong id="grammar-token-valuesuffix">ValueSuffix</strong> ::= "{" <a class="reference internal" href="#grammar-token-rangelist"><code class="xref docutils literal notranslate"><span class="pre">RangeList</span></code></a> "}"
+ | "[" <a class="reference internal" href="#grammar-token-rangelist"><code class="xref docutils literal notranslate"><span class="pre">RangeList</span></code></a> "]"
+ | "." <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a>
+<strong id="grammar-token-rangelist">RangeList </strong> ::= <a class="reference internal" href="#grammar-token-rangepiece"><code class="xref docutils literal notranslate"><span class="pre">RangePiece</span></code></a> ("," <a class="reference internal" href="#grammar-token-rangepiece"><code class="xref docutils literal notranslate"><span class="pre">RangePiece</span></code></a>)*
+<strong id="grammar-token-rangepiece">RangePiece </strong> ::= <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a>
+ | <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a> "-" <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a>
+ | <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a> <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a>
+</pre>
+<p>The peculiar last form of <a class="reference internal" href="#grammar-token-rangepiece"><code class="xref std std-token docutils literal notranslate"><span class="pre">RangePiece</span></code></a> is due to the fact that the
+â<code class="docutils literal notranslate"><span class="pre">-</span></code>â is included in the <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref std std-token docutils literal notranslate"><span class="pre">TokInteger</span></code></a>, hence <code class="docutils literal notranslate"><span class="pre">1-5</span></code> gets lexed as
+two consecutive <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref std std-token docutils literal notranslate"><span class="pre">TokInteger</span></code></a>âs, with values <code class="docutils literal notranslate"><span class="pre">1</span></code> and <code class="docutils literal notranslate"><span class="pre">-5</span></code>,
+instead of â1â, â-â, and â5â.
+The <a class="reference internal" href="#grammar-token-rangelist"><code class="xref std std-token docutils literal notranslate"><span class="pre">RangeList</span></code></a> can be thought of as specifying âlist sliceâ in some
+contexts.</p>
+<p><a class="reference internal" href="#grammar-token-simplevalue"><code class="xref std std-token docutils literal notranslate"><span class="pre">SimpleValue</span></code></a> has a number of forms:</p>
+<pre>
+<strong id="grammar-token-simplevalue">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a>
+</pre>
+<p>The value will be the variable referenced by the identifier. It can be one
+of:</p>
+<ul>
+<li><p class="first">name of a <code class="docutils literal notranslate"><span class="pre">def</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">Bar</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">Bar</span> <span class="p">:</span> <span class="n">SomeClass</span> <span class="p">{</span>
+ <span class="nb">int</span> <span class="n">X</span> <span class="o">=</span> <span class="mi">5</span><span class="p">;</span>
+<span class="p">}</span>
+
+<span class="k">def</span> <span class="nf">Foo</span> <span class="p">{</span>
+ <span class="n">SomeClass</span> <span class="n">Baz</span> <span class="o">=</span> <span class="n">Bar</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">value local to a <code class="docutils literal notranslate"><span class="pre">def</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">Bar</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">Foo</span> <span class="p">{</span>
+ <span class="nb">int</span> <span class="n">Bar</span> <span class="o">=</span> <span class="mi">5</span><span class="p">;</span>
+ <span class="nb">int</span> <span class="n">Baz</span> <span class="o">=</span> <span class="n">Bar</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Values defined in superclasses can be accessed the same way.</p>
+</li>
+<li><p class="first">a template arg of a <code class="docutils literal notranslate"><span class="pre">class</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">Bar</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">Foo</span><span class="o"><</span><span class="nb">int</span> <span class="n">Bar</span><span class="o">></span> <span class="p">{</span>
+ <span class="nb">int</span> <span class="n">Baz</span> <span class="o">=</span> <span class="n">Bar</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">value local to a <code class="docutils literal notranslate"><span class="pre">class</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">Bar</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+ <span class="nb">int</span> <span class="n">Bar</span> <span class="o">=</span> <span class="mi">5</span><span class="p">;</span>
+ <span class="nb">int</span> <span class="n">Baz</span> <span class="o">=</span> <span class="n">Bar</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">a template arg to a <code class="docutils literal notranslate"><span class="pre">multiclass</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">Bar</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>multiclass Foo<int Bar> {
+ def : SomeClass<Bar>;
+}
+</pre></div>
+</div>
+</li>
+<li><p class="first">the iteration variable of a <code class="docutils literal notranslate"><span class="pre">foreach</span></code>, such as the use of <code class="docutils literal notranslate"><span class="pre">i</span></code> in:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">foreach</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="o">-</span><span class="mi">5</span> <span class="ow">in</span>
+<span class="k">def</span> <span class="nf">Foo</span><span class="c1">#i;</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">a variable defined by <code class="docutils literal notranslate"><span class="pre">defset</span></code></p>
+</li>
+<li><p class="first">the implicit template argument <code class="docutils literal notranslate"><span class="pre">NAME</span></code> in a <code class="docutils literal notranslate"><span class="pre">class</span></code> or <code class="docutils literal notranslate"><span class="pre">multiclass</span></code></p>
+</li>
+</ul>
+<pre>
+<strong id="id1">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-tokinteger"><code class="xref docutils literal notranslate"><span class="pre">TokInteger</span></code></a>
+</pre>
+<p>This represents the numeric value of the integer.</p>
+<pre>
+<strong id="id2">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-tokstring"><code class="xref docutils literal notranslate"><span class="pre">TokString</span></code></a>+
+</pre>
+<p>Multiple adjacent string literals are concatenated like in C/C++. The value
+is the concatenation of the strings.</p>
+<pre>
+<strong id="id3">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-tokcodefragment"><code class="xref docutils literal notranslate"><span class="pre">TokCodeFragment</span></code></a>
+</pre>
+<p>The value is the string value of the code fragment.</p>
+<pre>
+<strong id="id4">SimpleValue</strong> ::= "?"
+</pre>
+<p><code class="docutils literal notranslate"><span class="pre">?</span></code> represents an âunsetâ initializer.</p>
+<pre>
+<strong id="id5">SimpleValue</strong> ::= "{" <a class="reference internal" href="#grammar-token-valuelist"><code class="xref docutils literal notranslate"><span class="pre">ValueList</span></code></a> "}"
+<strong id="grammar-token-valuelist">ValueList </strong> ::= [<a class="reference internal" href="#grammar-token-valuelistne"><code class="xref docutils literal notranslate"><span class="pre">ValueListNE</span></code></a>]
+<strong id="grammar-token-valuelistne">ValueListNE</strong> ::= <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a> ("," <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>)*
+</pre>
+<p>This represents a sequence of bits, as would be used to initialize a
+<code class="docutils literal notranslate"><span class="pre">bits<n></span></code> field (where <code class="docutils literal notranslate"><span class="pre">n</span></code> is the number of bits).</p>
+<pre>
+<strong id="id6">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-classid"><code class="xref docutils literal notranslate"><span class="pre">ClassID</span></code></a> "<" <a class="reference internal" href="#grammar-token-valuelistne"><code class="xref docutils literal notranslate"><span class="pre">ValueListNE</span></code></a> ">"
+</pre>
+<p>This generates a new anonymous record definition (as would be created by an
+unnamed <code class="docutils literal notranslate"><span class="pre">def</span></code> inheriting from the given class with the given template
+arguments) and the value is the value of that record definition.</p>
+<pre>
+<strong id="id7">SimpleValue</strong> ::= "[" <a class="reference internal" href="#grammar-token-valuelist"><code class="xref docutils literal notranslate"><span class="pre">ValueList</span></code></a> "]" ["<" <a class="reference internal" href="#grammar-token-type"><code class="xref docutils literal notranslate"><span class="pre">Type</span></code></a> ">"]
+</pre>
+<p>A list initializer. The optional <a class="reference internal" href="#grammar-token-type"><code class="xref std std-token docutils literal notranslate"><span class="pre">Type</span></code></a> can be used to indicate a
+specific element type, otherwise the element type will be deduced from the
+given values.</p>
+<pre>
+<strong id="id8">SimpleValue</strong> ::= "(" <a class="reference internal" href="#grammar-token-dagarg"><code class="xref docutils literal notranslate"><span class="pre">DagArg</span></code></a> [<a class="reference internal" href="#grammar-token-dagarglist"><code class="xref docutils literal notranslate"><span class="pre">DagArgList</span></code></a>] ")"
+<strong id="grammar-token-dagarglist">DagArgList </strong> ::= <a class="reference internal" href="#grammar-token-dagarg"><code class="xref docutils literal notranslate"><span class="pre">DagArg</span></code></a> ("," <a class="reference internal" href="#grammar-token-dagarg"><code class="xref docutils literal notranslate"><span class="pre">DagArg</span></code></a>)*
+<strong id="grammar-token-dagarg">DagArg </strong> ::= <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a> [":" <a class="reference internal" href="#grammar-token-tokvarname"><code class="xref docutils literal notranslate"><span class="pre">TokVarName</span></code></a>] | <a class="reference internal" href="#grammar-token-tokvarname"><code class="xref docutils literal notranslate"><span class="pre">TokVarName</span></code></a>
+</pre>
+<p>The initial <a class="reference internal" href="#grammar-token-dagarg"><code class="xref std std-token docutils literal notranslate"><span class="pre">DagArg</span></code></a> is called the âoperatorâ of the dag.</p>
+<pre>
+<strong id="id9">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-bangoperator"><code class="xref docutils literal notranslate"><span class="pre">BangOperator</span></code></a> ["<" <a class="reference internal" href="#grammar-token-type"><code class="xref docutils literal notranslate"><span class="pre">Type</span></code></a> ">"] "(" <a class="reference internal" href="#grammar-token-valuelistne"><code class="xref docutils literal notranslate"><span class="pre">ValueListNE</span></code></a> ")"
+ | <a class="reference internal" href="#grammar-token-condoperator"><code class="xref docutils literal notranslate"><span class="pre">CondOperator</span></code></a> "(" <a class="reference internal" href="#grammar-token-condval"><code class="xref docutils literal notranslate"><span class="pre">CondVal</span></code></a> ("," <a class="reference internal" href="#grammar-token-condval"><code class="xref docutils literal notranslate"><span class="pre">CondVal</span></code></a>)* ")"
+<strong id="grammar-token-condval">CondVal </strong> ::= <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a> ":" <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>
+</pre>
+</div>
+<div class="section" id="bodies">
+<h3><a class="toc-backref" href="#id18">Bodies</a><a class="headerlink" href="#bodies" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-objectbody">ObjectBody </strong> ::= <a class="reference internal" href="#grammar-token-baseclasslist"><code class="xref docutils literal notranslate"><span class="pre">BaseClassList</span></code></a> <a class="reference internal" href="#grammar-token-body"><code class="xref docutils literal notranslate"><span class="pre">Body</span></code></a>
+<strong id="grammar-token-baseclasslist">BaseClassList </strong> ::= [":" <a class="reference internal" href="#grammar-token-baseclasslistne"><code class="xref docutils literal notranslate"><span class="pre">BaseClassListNE</span></code></a>]
+<strong id="grammar-token-baseclasslistne">BaseClassListNE</strong> ::= <a class="reference internal" href="#grammar-token-subclassref"><code class="xref docutils literal notranslate"><span class="pre">SubClassRef</span></code></a> ("," <a class="reference internal" href="#grammar-token-subclassref"><code class="xref docutils literal notranslate"><span class="pre">SubClassRef</span></code></a>)*
+<strong id="grammar-token-subclassref">SubClassRef </strong> ::= (<a class="reference internal" href="#grammar-token-classid"><code class="xref docutils literal notranslate"><span class="pre">ClassID</span></code></a> | <a class="reference internal" href="#grammar-token-multiclassid"><code class="xref docutils literal notranslate"><span class="pre">MultiClassID</span></code></a>) ["<" <a class="reference internal" href="#grammar-token-valuelist"><code class="xref docutils literal notranslate"><span class="pre">ValueList</span></code></a> ">"]
+<strong id="grammar-token-defmid">DefmID </strong> ::= <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a>
+</pre>
+<p>The version with the <a class="reference internal" href="#grammar-token-multiclassid"><code class="xref std std-token docutils literal notranslate"><span class="pre">MultiClassID</span></code></a> is only valid in the
+<a class="reference internal" href="#grammar-token-baseclasslist"><code class="xref std std-token docutils literal notranslate"><span class="pre">BaseClassList</span></code></a> of a <code class="docutils literal notranslate"><span class="pre">defm</span></code>.
+The <a class="reference internal" href="#grammar-token-multiclassid"><code class="xref std std-token docutils literal notranslate"><span class="pre">MultiClassID</span></code></a> should be the name of a <code class="docutils literal notranslate"><span class="pre">multiclass</span></code>.</p>
+<p>It is after parsing the base class list that the âlet stackâ is applied.</p>
+<pre>
+<strong id="grammar-token-body">Body </strong> ::= ";" | "{" BodyList "}"
+<strong id="grammar-token-bodylist">BodyList</strong> ::= BodyItem*
+<strong id="grammar-token-bodyitem">BodyItem</strong> ::= <a class="reference internal" href="#grammar-token-declaration"><code class="xref docutils literal notranslate"><span class="pre">Declaration</span></code></a> ";"
+ | "let" <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> [ "{" <a class="reference internal" href="#grammar-token-rangelist"><code class="xref docutils literal notranslate"><span class="pre">RangeList</span></code></a> "}" ] "=" <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a> ";"
+</pre>
+<p>The <code class="docutils literal notranslate"><span class="pre">let</span></code> form allows overriding the value of an inherited field.</p>
+</div>
+<div class="section" id="def">
+<h3><a class="toc-backref" href="#id19"><code class="docutils literal notranslate"><span class="pre">def</span></code></a><a class="headerlink" href="#def" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-def">Def</strong> ::= "def" [<a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>] <a class="reference internal" href="#grammar-token-objectbody"><code class="xref docutils literal notranslate"><span class="pre">ObjectBody</span></code></a>
+</pre>
+<p>Defines a record whose name is given by the optional <a class="reference internal" href="#grammar-token-value"><code class="xref std std-token docutils literal notranslate"><span class="pre">Value</span></code></a>. The value
+is parsed in a special mode where global identifiers (records and variables
+defined by <code class="docutils literal notranslate"><span class="pre">defset</span></code>) are not recognized, and all unrecognized identifiers
+are interpreted as strings.</p>
+<p>If no name is given, the record is anonymous. The final name of anonymous
+records is undefined, but globally unique.</p>
+<p>Special handling occurs if this <code class="docutils literal notranslate"><span class="pre">def</span></code> appears inside a <code class="docutils literal notranslate"><span class="pre">multiclass</span></code> or
+a <code class="docutils literal notranslate"><span class="pre">foreach</span></code>.</p>
+<p>When a non-anonymous record is defined in a multiclass and the given name
+does not contain a reference to the implicit template argument <code class="docutils literal notranslate"><span class="pre">NAME</span></code>, such
+a reference will automatically be prepended. That is, the following are
+equivalent inside a multiclass:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">Foo</span><span class="p">;</span>
+<span class="k">def</span> <span class="nf">NAME</span><span class="c1">#Foo;</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="defm">
+<h3><a class="toc-backref" href="#id20"><code class="docutils literal notranslate"><span class="pre">defm</span></code></a><a class="headerlink" href="#defm" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-defm">Defm</strong> ::= "defm" [<a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>] ":" <a class="reference internal" href="#grammar-token-baseclasslistne"><code class="xref docutils literal notranslate"><span class="pre">BaseClassListNE</span></code></a> ";"
+</pre>
+<p>The <a class="reference internal" href="#grammar-token-baseclasslist"><code class="xref std std-token docutils literal notranslate"><span class="pre">BaseClassList</span></code></a> is a list of at least one <code class="docutils literal notranslate"><span class="pre">multiclass</span></code> and any
+number of <code class="docutils literal notranslate"><span class="pre">class</span></code>âs. The <code class="docutils literal notranslate"><span class="pre">multiclass</span></code>âs must occur before any <code class="docutils literal notranslate"><span class="pre">class</span></code>âs.</p>
+<p>Instantiates all records defined in all given <code class="docutils literal notranslate"><span class="pre">multiclass</span></code>âs and adds the
+given <code class="docutils literal notranslate"><span class="pre">class</span></code>âs as superclasses.</p>
+<p>The name is parsed in the same special mode used by <code class="docutils literal notranslate"><span class="pre">def</span></code>. If the name is
+missing, a globally unique string is used instead (but instantiated records
+are not considered to be anonymous, unless they were originally defined by an
+anonymous <code class="docutils literal notranslate"><span class="pre">def</span></code>) That is, the following have different semantics:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">defm</span> <span class="p">:</span> <span class="n">SomeMultiClass</span><span class="o"><...></span><span class="p">;</span> <span class="o">//</span> <span class="n">some</span> <span class="n">globally</span> <span class="n">unique</span> <span class="n">name</span>
+<span class="n">defm</span> <span class="s2">""</span> <span class="p">:</span> <span class="n">SomeMultiClass</span><span class="o"><...></span><span class="p">;</span> <span class="o">//</span> <span class="n">empty</span> <span class="n">name</span> <span class="n">string</span>
+</pre></div>
+</div>
+<p>When it occurs inside a multiclass, the second variant is equivalent to
+<code class="docutils literal notranslate"><span class="pre">defm</span> <span class="pre">NAME</span> <span class="pre">:</span> <span class="pre">...</span></code>. More generally, when <code class="docutils literal notranslate"><span class="pre">defm</span></code> occurs in a multiclass and
+its name does not contain a reference to the implicit template argument
+<code class="docutils literal notranslate"><span class="pre">NAME</span></code>, such a reference will automatically be prepended. That is, the
+following are equivalent inside a multiclass:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">defm</span> <span class="n">Foo</span> <span class="p">:</span> <span class="n">SomeMultiClass</span><span class="o"><...></span><span class="p">;</span>
+<span class="n">defm</span> <span class="n">NAME</span><span class="c1">#Foo : SomeMultiClass<...>;</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="defset">
+<h3><a class="toc-backref" href="#id21"><code class="docutils literal notranslate"><span class="pre">defset</span></code></a><a class="headerlink" href="#defset" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-defset">Defset</strong> ::= "defset" <a class="reference internal" href="#grammar-token-type"><code class="xref docutils literal notranslate"><span class="pre">Type</span></code></a> <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> "=" "{" <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>* "}"
+</pre>
+<p>All records defined inside the braces via <code class="docutils literal notranslate"><span class="pre">def</span></code> and <code class="docutils literal notranslate"><span class="pre">defm</span></code> are collected
+in a globally accessible list of the given name (in addition to being added
+to the global collection of records as usual). Anonymous records created inside
+initializier expressions using the <code class="docutils literal notranslate"><span class="pre">Class<args...></span></code> syntax are never collected
+in a defset.</p>
+<p>The given type must be <code class="docutils literal notranslate"><span class="pre">list<A></span></code>, where <code class="docutils literal notranslate"><span class="pre">A</span></code> is some class. It is an error
+to define a record (via <code class="docutils literal notranslate"><span class="pre">def</span></code> or <code class="docutils literal notranslate"><span class="pre">defm</span></code>) inside the braces which doesnât
+derive from <code class="docutils literal notranslate"><span class="pre">A</span></code>.</p>
+</div>
+<div class="section" id="foreach">
+<h3><a class="toc-backref" href="#id22"><code class="docutils literal notranslate"><span class="pre">foreach</span></code></a><a class="headerlink" href="#foreach" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-foreach">Foreach </strong> ::= "foreach" <a class="reference internal" href="#grammar-token-foreachdeclaration"><code class="xref docutils literal notranslate"><span class="pre">ForeachDeclaration</span></code></a> "in" "{" <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>* "}"
+ | "foreach" <a class="reference internal" href="#grammar-token-foreachdeclaration"><code class="xref docutils literal notranslate"><span class="pre">ForeachDeclaration</span></code></a> "in" <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>
+<strong id="grammar-token-foreachdeclaration">ForeachDeclaration</strong> ::= ID "=" ( "{" <a class="reference internal" href="#grammar-token-rangelist"><code class="xref docutils literal notranslate"><span class="pre">RangeList</span></code></a> "}" | <a class="reference internal" href="#grammar-token-rangepiece"><code class="xref docutils literal notranslate"><span class="pre">RangePiece</span></code></a> | <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a> )
+</pre>
+<p>The value assigned to the variable in the declaration is iterated over and
+the object or object list is reevaluated with the variable set at each
+iterated value.</p>
+<p>Note that the productions involving RangeList and RangePiece have precedence
+over the more generic value parsing based on the first token.</p>
+</div>
+<div class="section" id="top-level-let">
+<h3><a class="toc-backref" href="#id23">Top-Level <code class="docutils literal notranslate"><span class="pre">let</span></code></a><a class="headerlink" href="#top-level-let" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-let">Let </strong> ::= "let" <a class="reference internal" href="#grammar-token-letlist"><code class="xref docutils literal notranslate"><span class="pre">LetList</span></code></a> "in" "{" <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>* "}"
+ | "let" <a class="reference internal" href="#grammar-token-letlist"><code class="xref docutils literal notranslate"><span class="pre">LetList</span></code></a> "in" <a class="reference internal" href="#grammar-token-object"><code class="xref docutils literal notranslate"><span class="pre">Object</span></code></a>
+<strong id="grammar-token-letlist">LetList</strong> ::= <a class="reference internal" href="#grammar-token-letitem"><code class="xref docutils literal notranslate"><span class="pre">LetItem</span></code></a> ("," <a class="reference internal" href="#grammar-token-letitem"><code class="xref docutils literal notranslate"><span class="pre">LetItem</span></code></a>)*
+<strong id="grammar-token-letitem">LetItem</strong> ::= <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> [<a class="reference internal" href="#grammar-token-rangelist"><code class="xref docutils literal notranslate"><span class="pre">RangeList</span></code></a>] "=" <a class="reference internal" href="#grammar-token-value"><code class="xref docutils literal notranslate"><span class="pre">Value</span></code></a>
+</pre>
+<p>This is effectively equivalent to <code class="docutils literal notranslate"><span class="pre">let</span></code> inside the body of a record
+except that it applies to multiple records at a time. The bindings are
+applied at the end of parsing the base classes of a record.</p>
+</div>
+<div class="section" id="multiclass">
+<h3><a class="toc-backref" href="#id24"><code class="docutils literal notranslate"><span class="pre">multiclass</span></code></a><a class="headerlink" href="#multiclass" title="Permalink to this headline">¶</a></h3>
+<pre>
+<strong id="grammar-token-multiclass">MultiClass </strong> ::= "multiclass" <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a> [<a class="reference internal" href="#grammar-token-templatearglist"><code class="xref docutils literal notranslate"><span class="pre">TemplateArgList</span></code></a>]
+ [":" <a class="reference internal" href="#grammar-token-basemulticlasslist"><code class="xref docutils literal notranslate"><span class="pre">BaseMultiClassList</span></code></a>] "{" <a class="reference internal" href="#grammar-token-multiclassobject"><code class="xref docutils literal notranslate"><span class="pre">MultiClassObject</span></code></a>+ "}"
+<strong id="grammar-token-basemulticlasslist">BaseMultiClassList</strong> ::= <a class="reference internal" href="#grammar-token-multiclassid"><code class="xref docutils literal notranslate"><span class="pre">MultiClassID</span></code></a> ("," <a class="reference internal" href="#grammar-token-multiclassid"><code class="xref docutils literal notranslate"><span class="pre">MultiClassID</span></code></a>)*
+<strong id="grammar-token-multiclassid">MultiClassID </strong> ::= <a class="reference internal" href="#grammar-token-tokidentifier"><code class="xref docutils literal notranslate"><span class="pre">TokIdentifier</span></code></a>
+<strong id="grammar-token-multiclassobject">MultiClassObject </strong> ::= <a class="reference internal" href="#grammar-token-def"><code class="xref docutils literal notranslate"><span class="pre">Def</span></code></a> | <a class="reference internal" href="#grammar-token-defm"><code class="xref docutils literal notranslate"><span class="pre">Defm</span></code></a> | <a class="reference internal" href="#grammar-token-let"><code class="xref docutils literal notranslate"><span class="pre">Let</span></code></a> | <a class="reference internal" href="#grammar-token-foreach"><code class="xref docutils literal notranslate"><span class="pre">Foreach</span></code></a>
+</pre>
+</div>
+</div>
+<div class="section" id="preprocessing-support">
+<h2><a class="toc-backref" href="#id25">Preprocessing Support</a><a class="headerlink" href="#preprocessing-support" title="Permalink to this headline">¶</a></h2>
+<p>TableGenâs embedded preprocessor is only intended for conditional compilation.
+It supports the following directives:</p>
+<pre>
+<strong id="grammar-token-linebegin">LineBegin </strong> ::= ^
+<strong id="grammar-token-lineend">LineEnd </strong> ::= "\n" | "\r" | EOF
+<strong id="grammar-token-whitespace">WhiteSpace </strong> ::= " " | "\t"
+<strong id="grammar-token-cstylecomment">CStyleComment </strong> ::= "/*" (.* - "*/") "*/"
+<strong id="grammar-token-bcplcomment">BCPLComment </strong> ::= "//" (.* - <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>) <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>
+<strong id="grammar-token-whitespaceorcstylecomment">WhiteSpaceOrCStyleComment</strong> ::= <a class="reference internal" href="#grammar-token-whitespace"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpace</span></code></a> | <a class="reference internal" href="#grammar-token-cstylecomment"><code class="xref docutils literal notranslate"><span class="pre">CStyleComment</span></code></a>
+<strong id="grammar-token-whitespaceoranycomment">WhiteSpaceOrAnyComment </strong> ::= <a class="reference internal" href="#grammar-token-whitespace"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpace</span></code></a> | <a class="reference internal" href="#grammar-token-cstylecomment"><code class="xref docutils literal notranslate"><span class="pre">CStyleComment</span></code></a> | <a class="reference internal" href="#grammar-token-bcplcomment"><code class="xref docutils literal notranslate"><span class="pre">BCPLComment</span></code></a>
+<strong id="grammar-token-macroname">MacroName </strong> ::= <a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> (<a class="reference internal" href="#grammar-token-ualpha"><code class="xref docutils literal notranslate"><span class="pre">ualpha</span></code></a> | "0"..."9")*
+<strong id="grammar-token-prepdefine">PrepDefine </strong> ::= <a class="reference internal" href="#grammar-token-linebegin"><code class="xref docutils literal notranslate"><span class="pre">LineBegin</span></code></a> (<a class="reference internal" href="#grammar-token-whitespaceorcstylecomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrCStyleComment</span></code></a>)*
+ "#define" (<a class="reference internal" href="#grammar-token-whitespace"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpace</span></code></a>)+ <a class="reference internal" href="#grammar-token-macroname"><code class="xref docutils literal notranslate"><span class="pre">MacroName</span></code></a>
+ (<a class="reference internal" href="#grammar-token-whitespaceoranycomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrAnyComment</span></code></a>)* <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>
+<strong id="grammar-token-prepifdef">PrepIfdef </strong> ::= <a class="reference internal" href="#grammar-token-linebegin"><code class="xref docutils literal notranslate"><span class="pre">LineBegin</span></code></a> (<a class="reference internal" href="#grammar-token-whitespaceorcstylecomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrCStyleComment</span></code></a>)*
+ "#ifdef" (<a class="reference internal" href="#grammar-token-whitespace"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpace</span></code></a>)+ <a class="reference internal" href="#grammar-token-macroname"><code class="xref docutils literal notranslate"><span class="pre">MacroName</span></code></a>
+ (<a class="reference internal" href="#grammar-token-whitespaceoranycomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrAnyComment</span></code></a>)* <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>
+<strong id="grammar-token-prepelse">PrepElse </strong> ::= <a class="reference internal" href="#grammar-token-linebegin"><code class="xref docutils literal notranslate"><span class="pre">LineBegin</span></code></a> (<a class="reference internal" href="#grammar-token-whitespaceorcstylecomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrCStyleComment</span></code></a>)*
+ "#else" (<a class="reference internal" href="#grammar-token-whitespaceoranycomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrAnyComment</span></code></a>)* <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>
+<strong id="grammar-token-prependif">PrepEndif </strong> ::= <a class="reference internal" href="#grammar-token-linebegin"><code class="xref docutils literal notranslate"><span class="pre">LineBegin</span></code></a> (<a class="reference internal" href="#grammar-token-whitespaceorcstylecomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrCStyleComment</span></code></a>)*
+ "#endif" (<a class="reference internal" href="#grammar-token-whitespaceoranycomment"><code class="xref docutils literal notranslate"><span class="pre">WhiteSpaceOrAnyComment</span></code></a>)* <a class="reference internal" href="#grammar-token-lineend"><code class="xref docutils literal notranslate"><span class="pre">LineEnd</span></code></a>
+<strong id="grammar-token-prepregcontentexception">PrepRegContentException </strong> ::= <a class="reference internal" href="#grammar-token-prepifdef"><code class="xref docutils literal notranslate"><span class="pre">PrepIfdef</span></code></a> | <a class="reference internal" href="#grammar-token-prepelse"><code class="xref docutils literal notranslate"><span class="pre">PrepElse</span></code></a> | <a class="reference internal" href="#grammar-token-prependif"><code class="xref docutils literal notranslate"><span class="pre">PrepEndif</span></code></a> | EOF
+<strong id="grammar-token-prepregion">PrepRegion </strong> ::= .* - <a class="reference internal" href="#grammar-token-prepregcontentexception"><code class="xref docutils literal notranslate"><span class="pre">PrepRegContentException</span></code></a>
+ | <a class="reference internal" href="#grammar-token-prepifdef"><code class="xref docutils literal notranslate"><span class="pre">PrepIfdef</span></code></a>
+ (<a class="reference internal" href="#grammar-token-prepregion"><code class="xref docutils literal notranslate"><span class="pre">PrepRegion</span></code></a>)*
+ [<a class="reference internal" href="#grammar-token-prepelse"><code class="xref docutils literal notranslate"><span class="pre">PrepElse</span></code></a>]
+ (<a class="reference internal" href="#grammar-token-prepregion"><code class="xref docutils literal notranslate"><span class="pre">PrepRegion</span></code></a>)*
+ <a class="reference internal" href="#grammar-token-prependif"><code class="xref docutils literal notranslate"><span class="pre">PrepEndif</span></code></a>
+</pre>
+<p><a class="reference internal" href="#grammar-token-prepregion"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepRegion</span></code></a> may occur anywhere in a TD file, as long as it matches
+the grammar specification.</p>
+<p><a class="reference internal" href="#grammar-token-prepdefine"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepDefine</span></code></a> allows defining a <a class="reference internal" href="#grammar-token-macroname"><code class="xref std std-token docutils literal notranslate"><span class="pre">MacroName</span></code></a> so that any following
+<a class="reference internal" href="#grammar-token-prepifdef"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepIfdef</span></code></a> - <a class="reference internal" href="#grammar-token-prepelse"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepElse</span></code></a> preprocessing region part and
+<a class="reference internal" href="#grammar-token-prepifdef"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepIfdef</span></code></a> - <a class="reference internal" href="#grammar-token-prependif"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepEndif</span></code></a> preprocessing region
+are enabled for TableGen tokens parsing.</p>
+<p>A preprocessing region, starting (i.e. having its <a class="reference internal" href="#grammar-token-prepifdef"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepIfdef</span></code></a>) in a file,
+must end (i.e. have its <a class="reference internal" href="#grammar-token-prependif"><code class="xref std std-token docutils literal notranslate"><span class="pre">PrepEndif</span></code></a>) in the same file.</p>
+<p>A <a class="reference internal" href="#grammar-token-macroname"><code class="xref std std-token docutils literal notranslate"><span class="pre">MacroName</span></code></a> may be defined externally by using <code class="docutils literal notranslate"><span class="pre">{</span> <span class="pre">-D<NAME></span> <span class="pre">}</span></code>
+option of TableGen.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="LangIntro.html" title="TableGen Language Introduction"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="BackEnds.html" title="TableGen BackEnds"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGen/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGen/index.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGen/index.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGen/index.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,353 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen — LLVM 9 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" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></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>
+ <script type="text/javascript" src="../_static/language_data.js"></script>
+ <link rel="index" title="Index" href="../genindex.html" />
+ <link rel="search" title="Search" href="../search.html" />
+ <link rel="next" title="TableGen BackEnds" href="BackEnds.html" />
+ <link rel="prev" title="TableGen Fundamentals" href="../TableGenFundamentals.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" role="navigation" aria-label="related navigation">
+ <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="BackEnds.html" title="TableGen BackEnds"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="../TableGenFundamentals.html" title="TableGen Fundamentals"
+ 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" role="main">
+
+ <div class="section" id="tablegen">
+<h1>TableGen<a class="headerlink" href="#tablegen" 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="id3">Introduction</a></li>
+<li><a class="reference internal" href="#the-tablegen-program" id="id4">The TableGen program</a><ul>
+<li><a class="reference internal" href="#running-tablegen" id="id5">Running TableGen</a></li>
+<li><a class="reference internal" href="#example" id="id6">Example</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#syntax" id="id7">Syntax</a><ul>
+<li><a class="reference internal" href="#basic-concepts" id="id8">Basic concepts</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#tablegen-backends" id="id9">TableGen backends</a></li>
+<li><a class="reference internal" href="#tablegen-deficiencies" id="id10">TableGen Deficiencies</a></li>
+</ul>
+</div>
+<div class="toctree-wrapper compound">
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id3">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>TableGenâs purpose is to help a human develop and maintain records of
+domain-specific information. Because there may be a large number of these
+records, it is specifically designed to allow writing flexible descriptions and
+for common features of these records to be factored out. This reduces the
+amount of duplication in the description, reduces the chance of error, and makes
+it easier to structure domain specific information.</p>
+<p>The core part of TableGen parses a file, instantiates the declarations, and
+hands the result off to a domain-specific <a class="reference internal" href="#backend">backend</a> for processing.</p>
+<p>The current major users of TableGen are <a class="reference internal" href="../CodeGenerator.html"><span class="doc">The LLVM Target-Independent Code Generator</span></a>
+and the
+<a class="reference external" href="http://clang.llvm.org/docs/UsersManual.html#controlling-errors-and-warnings">Clang diagnostics and attributes</a>.</p>
+<p>Note that if you work on TableGen much, and use emacs or vim, that you can find
+an emacs âTableGen modeâ and a vim language file in the <code class="docutils literal notranslate"><span class="pre">llvm/utils/emacs</span></code> and
+<code class="docutils literal notranslate"><span class="pre">llvm/utils/vim</span></code> directories of your LLVM distribution, respectively.</p>
+</div>
+<div class="section" id="the-tablegen-program">
+<span id="intro"></span><h2><a class="toc-backref" href="#id4">The TableGen program</a><a class="headerlink" href="#the-tablegen-program" title="Permalink to this headline">¶</a></h2>
+<p>TableGen files are interpreted by the TableGen program: <cite>llvm-tblgen</cite> available
+on your build directory under <cite>bin</cite>. It is not installed in the system (or where
+your sysroot is set to), since it has no use beyond LLVMâs build process.</p>
+<div class="section" id="running-tablegen">
+<h3><a class="toc-backref" href="#id5">Running TableGen</a><a class="headerlink" href="#running-tablegen" title="Permalink to this headline">¶</a></h3>
+<p>TableGen runs just like any other LLVM tool. The first (optional) argument
+specifies the file to read. If a filename is not specified, <code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span></code>
+reads from standard input.</p>
+<p>To be useful, one of the <a class="reference internal" href="#backends">backends</a> must be used. These backends are
+selectable on the command line (type â<code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span> <span class="pre">-help</span></code>â for a list). For
+example, to get a list of all of the definitions that subclass a particular type
+(which can be useful for building up an enum list of these records), use the
+<code class="docutils literal notranslate"><span class="pre">-print-enums</span></code> option:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>$ llvm-tblgen X86.td -print-enums -class<span class="o">=</span>Register
+AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
+ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
+MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
+R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
+R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
+RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
+XMM6, XMM7, XMM8, XMM9,
+
+$ llvm-tblgen X86.td -print-enums -class<span class="o">=</span>Instruction
+ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
+ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
+ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
+ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
+ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
+</pre></div>
+</div>
+<p>The default backend prints out all of the records. There is also a general
+backend which outputs all the records as a JSON data structure, enabled using
+the <cite>-dump-json</cite> option.</p>
+<p>If you plan to use TableGen, you will most likely have to write a <a class="reference internal" href="#backend">backend</a>
+that extracts the information specific to what you need and formats it in the
+appropriate way. You can do this by extending TableGen itself in C++, or by
+writing a script in any language that can consume the JSON output.</p>
+</div>
+<div class="section" id="example">
+<h3><a class="toc-backref" href="#id6">Example</a><a class="headerlink" href="#example" title="Permalink to this headline">¶</a></h3>
+<p>With no other arguments, <cite>llvm-tblgen</cite> parses the specified file and prints out all
+of the classes, then all of the definitions. This is a good way to see what the
+various definitions expand to fully. Running this on the <code class="docutils literal notranslate"><span class="pre">X86.td</span></code> file prints
+this (at the time of this writing):</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>...
+def ADD32rr { // Instruction X86Inst I
+ string Namespace = "X86";
+ dag OutOperandList = (outs GR32:$dst);
+ dag InOperandList = (ins GR32:$src1, GR32:$src2);
+ string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
+ list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
+ list<Register> Uses = [];
+ list<Register> Defs = [EFLAGS];
+ list<Predicate> Predicates = [];
+ int CodeSize = 3;
+ int AddedComplexity = 0;
+ bit isReturn = 0;
+ bit isBranch = 0;
+ bit isIndirectBranch = 0;
+ bit isBarrier = 0;
+ bit isCall = 0;
+ bit canFoldAsLoad = 0;
+ bit mayLoad = 0;
+ bit mayStore = 0;
+ bit isImplicitDef = 0;
+ bit isConvertibleToThreeAddress = 1;
+ bit isCommutable = 1;
+ bit isTerminator = 0;
+ bit isReMaterializable = 0;
+ bit isPredicable = 0;
+ bit hasDelaySlot = 0;
+ bit usesCustomInserter = 0;
+ bit hasCtrlDep = 0;
+ bit isNotDuplicable = 0;
+ bit hasSideEffects = 0;
+ InstrItinClass Itinerary = NoItinerary;
+ string Constraints = "";
+ string DisableEncoding = "";
+ bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
+ Format Form = MRMDestReg;
+ bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
+ ImmType ImmT = NoImm;
+ bits<3> ImmTypeBits = { 0, 0, 0 };
+ bit hasOpSizePrefix = 0;
+ bit hasAdSizePrefix = 0;
+ bits<4> Prefix = { 0, 0, 0, 0 };
+ bit hasREX_WPrefix = 0;
+ FPFormat FPForm = ?;
+ bits<3> FPFormBits = { 0, 0, 0 };
+}
+...
+</pre></div>
+</div>
+<p>This definition corresponds to the 32-bit register-register <code class="docutils literal notranslate"><span class="pre">add</span></code> instruction
+of the x86 architecture. <code class="docutils literal notranslate"><span class="pre">def</span> <span class="pre">ADD32rr</span></code> defines a record named
+<code class="docutils literal notranslate"><span class="pre">ADD32rr</span></code>, and the comment at the end of the line indicates the superclasses
+of the definition. The body of the record contains all of the data that
+TableGen assembled for the record, indicating that the instruction is part of
+the âX86â namespace, the pattern indicating how the instruction is selected by
+the code generator, that it is a two-address instruction, has a particular
+encoding, etc. The contents and semantics of the information in the record are
+specific to the needs of the X86 backend, and are only shown as an example.</p>
+<p>As you can see, a lot of information is needed for every instruction supported
+by the code generator, and specifying it all manually would be unmaintainable,
+prone to bugs, and tiring to do in the first place. Because we are using
+TableGen, all of the information was derived from the following definition:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>let Defs = [EFLAGS],
+ isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y
+ isConvertibleToThreeAddress = 1 in // Can transform into LEA.
+def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
+ (ins GR32:$src1, GR32:$src2),
+ "add{l}\t{$src2, $dst|$dst, $src2}",
+ [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
+</pre></div>
+</div>
+<p>This definition makes use of the custom class <code class="docutils literal notranslate"><span class="pre">I</span></code> (extended from the custom
+class <code class="docutils literal notranslate"><span class="pre">X86Inst</span></code>), which is defined in the X86-specific TableGen file, to
+factor out the common features that instructions of its class share. A key
+feature of TableGen is that it allows the end-user to define the abstractions
+they prefer to use when describing their information.</p>
+</div>
+</div>
+<div class="section" id="syntax">
+<h2><a class="toc-backref" href="#id7">Syntax</a><a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
+<p>TableGen has a syntax that is loosely based on C++ templates, with built-in
+types and specification. In addition, TableGenâs syntax introduces some
+automation concepts like multiclass, foreach, let, etc.</p>
+<div class="section" id="basic-concepts">
+<h3><a class="toc-backref" href="#id8">Basic concepts</a><a class="headerlink" href="#basic-concepts" title="Permalink to this headline">¶</a></h3>
+<p>TableGen files consist of two key parts: âclassesâ and âdefinitionsâ, both of
+which are considered ârecordsâ.</p>
+<p><strong>TableGen records</strong> have a unique name, a list of values, and a list of
+superclasses. The list of values is the main data that TableGen builds for each
+record; it is this that holds the domain specific information for the
+application. The interpretation of this data is left to a specific <a class="reference internal" href="#backend">backend</a>,
+but the structure and format rules are taken care of and are fixed by
+TableGen.</p>
+<p><strong>TableGen definitions</strong> are the concrete form of ârecordsâ. These generally do
+not have any undefined values, and are marked with the â<code class="docutils literal notranslate"><span class="pre">def</span></code>â keyword.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
+ "Enable ARMv8 FP">;
+</pre></div>
+</div>
+<p>In this example, FeatureFPARMv8 is <code class="docutils literal notranslate"><span class="pre">SubtargetFeature</span></code> record initialised
+with some values. The names of the classes are defined via the
+keyword <cite>class</cite> either on the same file or some other included. Most target
+TableGen files include the generic ones in <code class="docutils literal notranslate"><span class="pre">include/llvm/Target</span></code>.</p>
+<p><strong>TableGen classes</strong> are abstract records that are used to build and describe
+other records. These classes allow the end-user to build abstractions for
+either the domain they are targeting (such as âRegisterâ, âRegisterClassâ, and
+âInstructionâ in the LLVM code generator) or for the implementor to help factor
+out common properties of records (such as âFPInstâ, which is used to represent
+floating point instructions in the X86 backend). TableGen keeps track of all of
+the classes that are used to build up a definition, so the backend can find all
+definitions of a particular class, such as âInstructionâ.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class ProcNoItin<string Name, list<SubtargetFeature> Features>
+ : Processor<Name, NoItineraries, Features>;
+</pre></div>
+</div>
+<p>Here, the class ProcNoItin, receiving parameters <cite>Name</cite> of type <cite>string</cite> and
+a list of target features is specializing the class Processor by passing the
+arguments down as well as hard-coding NoItineraries.</p>
+<p><strong>TableGen multiclasses</strong> are groups of abstract records that are instantiated
+all at once. Each instantiation can result in multiple TableGen definitions.
+If a multiclass inherits from another multiclass, the definitions in the
+sub-multiclass become part of the current multiclass, as if they were declared
+in the current multiclass.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
+ dag address, ValueType sty> {
+def : Pat<(i32 (!cast<SDNode>("sextload" # sty) address)),
+ (!cast<Instruction>("LDRS" # T # "w_" # Rm # "_RegOffset")
+ Base, Offset, Extend)>;
+
+def : Pat<(i64 (!cast<SDNode>("sextload" # sty) address)),
+ (!cast<Instruction>("LDRS" # T # "x_" # Rm # "_RegOffset")
+ Base, Offset, Extend)>;
+}
+
+defm : ro_signed_pats<"B", Rm, Base, Offset, Extend,
+ !foreach(decls.pattern, address,
+ !subst(SHIFT, imm_eq0, decls.pattern)),
+ i8>;
+</pre></div>
+</div>
+<p>See the <a class="reference internal" href="LangIntro.html"><span class="doc">TableGen Language Introduction</span></a> for more generic
+information on the usage of the language, and the
+<a class="reference internal" href="LangRef.html"><span class="doc">TableGen Language Reference</span></a> for more in-depth description
+of the formal language specification.</p>
+</div>
+</div>
+<div class="section" id="tablegen-backends">
+<span id="backends"></span><span id="backend"></span><h2><a class="toc-backref" href="#id9">TableGen backends</a><a class="headerlink" href="#tablegen-backends" title="Permalink to this headline">¶</a></h2>
+<p>TableGen files have no real meaning without a back-end. The default operation
+of running <code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span></code> is to print the information in a textual format, but
+thatâs only useful for debugging of the TableGen files themselves. The power
+in TableGen is, however, to interpret the source files into an internal
+representation that can be generated into anything you want.</p>
+<p>Current usage of TableGen is to create huge include files with tables that you
+can either include directly (if the output is in the language youâre coding),
+or be used in pre-processing via macros surrounding the include of the file.</p>
+<p>Direct output can be used if the back-end already prints a table in C format
+or if the output is just a list of strings (for error and warning messages).
+Pre-processed output should be used if the same information needs to be used
+in different contexts (like Instruction names), so your back-end should print
+a meta-information list that can be shaped into different compile-time formats.</p>
+<p>See the <a class="reference external" href="BackEnds.html">TableGen BackEnds</a> for more information.</p>
+</div>
+<div class="section" id="tablegen-deficiencies">
+<h2><a class="toc-backref" href="#id10">TableGen Deficiencies</a><a class="headerlink" href="#tablegen-deficiencies" title="Permalink to this headline">¶</a></h2>
+<p>Despite being very generic, TableGen has some deficiencies that have been
+pointed out numerous times. The common theme is that, while TableGen allows
+you to build Domain-Specific-Languages, the final languages that you create
+lack the power of other DSLs, which in turn increase considerably the size
+and complexity of TableGen files.</p>
+<p>At the same time, TableGen allows you to create virtually any meaning of
+the basic concepts via custom-made back-ends, which can pervert the original
+design and make it very hard for newcomers to understand the evil TableGen
+file.</p>
+<p>There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others are suggesting we should move to less,
+more powerful DSLs designed with specific purposes, or even re-using existing
+DSLs.</p>
+<p>Either way, this is a discussion that will likely span across several years,
+if not decades. You can read more in the <a class="reference external" href="Deficiencies.html">TableGen Deficiencies</a>
+document.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="BackEnds.html" title="TableGen BackEnds"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="../TableGenFundamentals.html" title="TableGen Fundamentals"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TableGenFundamentals.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TableGenFundamentals.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TableGenFundamentals.html (added)
+++ www-releases/trunk/9.0.0/docs/TableGenFundamentals.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,95 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>TableGen Fundamentals — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="TableGen" href="TableGen/index.html" />
+ <link rel="prev" title="Segmented Stacks in LLVM" href="SegmentedStacks.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" role="navigation" aria-label="related navigation">
+ <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="TableGen/index.html" title="TableGen"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="SegmentedStacks.html" title="Segmented Stacks in 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" role="main">
+
+ <div class="section" id="tablegen-fundamentals">
+<h1>TableGen Fundamentals<a class="headerlink" href="#tablegen-fundamentals" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="moved">
+<h2>Moved<a class="headerlink" href="#moved" title="Permalink to this headline">¶</a></h2>
+<p>The TableGen fundamentals documentation has moved to a directory on its own
+and is now available at <a class="reference internal" href="TableGen/index.html"><span class="doc">TableGen</span></a>. Please, change your links to
+that page.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="TableGen/index.html" title="TableGen"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="SegmentedStacks.html" title="Segmented Stacks in 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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TestSuiteGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TestSuiteGuide.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TestSuiteGuide.html (added)
+++ www-releases/trunk/9.0.0/docs/TestSuiteGuide.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,449 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>test-suite Guide — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="test-suite Makefile Guide (deprecated)" href="TestSuiteMakefileGuide.html" />
+ <link rel="prev" title="LLVM Testing Infrastructure Guide" href="TestingGuide.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" role="navigation" aria-label="related navigation">
+ <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="TestSuiteMakefileGuide.html" title="test-suite Makefile Guide (deprecated)"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="TestingGuide.html" title="LLVM Testing Infrastructure 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 class="nav-item nav-item-1"><a href="TestingGuide.html" accesskey="U">LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="test-suite-guide">
+<span id="test-suite-guide"></span><h1>test-suite Guide<a class="headerlink" href="#test-suite-guide" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="quickstart">
+<span id="quickstart"></span><h2>Quickstart<a class="headerlink" href="#quickstart" title="Permalink to this headline">¶</a></h2>
+<ol>
+<li><p class="first">The lit test runner is required to run the tests. You can either use one
+from an LLVM build:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% <path to llvm build>/bin/llvm-lit --version
+lit <span class="m">0</span>.8.0dev
+</pre></div>
+</div>
+<p>An alternative is installing it as a python package in a python virtual
+environment:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% mkdir venv
+% virtualenv venv
+% . venv/bin/activate
+% pip install svn+http://llvm.org/svn/llvm-project/llvm/trunk/utils/lit
+% lit --version
+lit <span class="m">0</span>.8.0dev
+</pre></div>
+</div>
+</li>
+<li><p class="first">Check out the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> module with:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% git clone https://github.com/llvm/llvm-test-suite.git test-suite
+</pre></div>
+</div>
+</li>
+<li><p class="first">Create a build directory and use CMake to configure the suite. Use the
+<code class="docutils literal notranslate"><span class="pre">CMAKE_C_COMPILER</span></code> option to specify the compiler to test. Use a cache file
+to choose a typical build configuration:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% mkdir test-suite-build
+% <span class="nb">cd</span> test-suite-build
+% cmake -DCMAKE_C_COMPILER<span class="o">=</span><path to llvm build>/bin/clang <span class="se">\</span>
+ -C../test-suite/cmake/caches/O3.cmake <span class="se">\</span>
+ ../test-suite
+</pre></div>
+</div>
+</li>
+<li><p class="first">Build the benchmarks:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>% make
+Scanning dependencies of target timeit-target
+[ 0%] Building C object tools/CMakeFiles/timeit-target.dir/timeit.c.o
+[ 0%] Linking C executable timeit-target
+...
+</pre></div>
+</div>
+</li>
+<li><p class="first">Run the tests with lit:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>% llvm-lit -v -j 1 -o results.json .
+-- Testing: 474 tests, 1 threads --
+PASS: test-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test (1 of 474)
+********** TEST 'test-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test' RESULTS **********
+compile_time: 0.2192
+exec_time: 0.0462
+hash: "59620e187c6ac38b36382685ccd2b63b"
+size: 83348
+**********
+PASS: test-suite :: MultiSource/Applications/ALAC/encode/alacconvert-encode.test (2 of 474)
+...
+</pre></div>
+</div>
+</li>
+<li><p class="first">Show and compare result files (optional):</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span><span class="c1"># Make sure pandas is installed. Prepend `sudo` if necessary.</span>
+% pip install pandas
+<span class="c1"># Show a single result file:</span>
+% test-suite/utils/compare.py results.json
+<span class="c1"># Compare two result files:</span>
+% test-suite/utils/compare.py results_a.json results_b.json
+</pre></div>
+</div>
+</li>
+</ol>
+</div>
+<div class="section" id="structure">
+<span id="structure"></span><h2>Structure<a class="headerlink" href="#structure" title="Permalink to this headline">¶</a></h2>
+<p>The test-suite contains benchmark and test programs. The programs come with
+reference outputs so that their correctness can be checked. The suite comes
+with tools to collect metrics such as benchmark runtime, compilation time and
+code size.</p>
+<p>The test-suite is divided into several directories:</p>
+<ul>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">SingleSource/</span></code></p>
+<p>Contains test programs that are only a single source file in size. A
+subdirectory may contain several programs.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">MultiSource/</span></code></p>
+<p>Contains subdirectories which entire programs with multiple source files.
+Large benchmarks and whole applications go here.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">MicroBenchmarks/</span></code></p>
+<p>Programs using the <a class="reference external" href="https://github.com/google/benchmark">google-benchmark</a>
+library. The programs define functions that are run multiple times until the
+measurement results are statistically significant.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">External/</span></code></p>
+<p>Contains descriptions and test data for code that cannot be directly
+distributed with the test-suite. The most prominent members of this
+directory are the SPEC CPU benchmark suites.
+See <a class="reference external" href="#external-suites">External Suites</a>.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">Bitcode/</span></code></p>
+<p>These tests are mostly written in LLVM bitcode.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CTMark/</span></code></p>
+<p>Contains symbolic links to other benchmarks forming a representative sample
+for compilation performance measurements.</p>
+</li>
+</ul>
+<div class="section" id="benchmarks">
+<span id="benchmarks"></span><h3>Benchmarks<a class="headerlink" href="#benchmarks" title="Permalink to this headline">¶</a></h3>
+<p>Every program can work as a correctness test. Some programs are unsuitable for
+performance measurements. Setting the <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_BENCHMARKING_ONLY</span></code> CMake
+option to <code class="docutils literal notranslate"><span class="pre">ON</span></code> will disable them.</p>
+</div>
+</div>
+<div class="section" id="configuration">
+<span id="configuration"></span><h2>Configuration<a class="headerlink" href="#configuration" title="Permalink to this headline">¶</a></h2>
+<p>The test-suite has configuration options to customize building and running the
+benchmarks. CMake can print a list of them:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% <span class="nb">cd</span> test-suite-build
+<span class="c1"># Print basic options:</span>
+% cmake -LH
+<span class="c1"># Print all options:</span>
+% cmake -LAH
+</pre></div>
+</div>
+<div class="section" id="common-configuration-options">
+<span id="common-configuration-options"></span><h3>Common Configuration Options<a class="headerlink" href="#common-configuration-options" title="Permalink to this headline">¶</a></h3>
+<ul>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CMAKE_C_FLAGS</span></code></p>
+<p>Specify extra flags to be passed to C compiler invocations. The flags are
+also passed to the C++ compiler and linker invocations. See
+<a class="reference external" href="https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html">https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html</a></p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CMAKE_C_COMPILER</span></code></p>
+<p>Select the C compiler executable to be used. Note that the C++ compiler is
+inferred automatically i.e. when specifying <code class="docutils literal notranslate"><span class="pre">path/to/clang</span></code> CMake will
+automatically use <code class="docutils literal notranslate"><span class="pre">path/to/clang++</span></code> as the C++ compiler. See
+<a class="reference external" href="https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html">https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html</a></p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CMAKE_BUILD_TYPE</span></code></p>
+<p>Select a build type like <code class="docutils literal notranslate"><span class="pre">OPTIMIZE</span></code> or <code class="docutils literal notranslate"><span class="pre">DEBUG</span></code> selecting a set of predefined
+compiler flags. These flags are applied regardless of the <code class="docutils literal notranslate"><span class="pre">CMAKE_C_FLAGS</span></code>
+option and may be changed by modifying <code class="docutils literal notranslate"><span class="pre">CMAKE_C_FLAGS_OPTIMIZE</span></code> etc. See
+[https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html]](https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html)</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_RUN_UNDER</span></code></p>
+<p>Prefix test invocations with the given tool. This is typically used to run
+cross-compiled tests within a simulator tool.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_BENCHMARKING_ONLY</span></code></p>
+<p>Disable tests that are unsuitable for performance measurements. The disabled
+tests either run for a very short time or are dominated by I/O performance
+making them unsuitable as compiler performance tests.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_SUBDIRS</span></code></p>
+<p>Semicolon-separated list of directories to include. This can be used to only
+build parts of the test-suite or to include external suites. This option
+does not work reliably with deeper subdirectories as it skips intermediate
+<code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> files which may be required.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_COLLECT_STATS</span></code></p>
+<p>Collect internal LLVM statistics. Appends <code class="docutils literal notranslate"><span class="pre">-save-stats=obj</span></code> when invocing the
+compiler and makes the lit runner collect and merge the statistic files.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_RUN_BENCHMARKS</span></code></p>
+<p>If this is set to <code class="docutils literal notranslate"><span class="pre">OFF</span></code> then lit will not actually run the tests but just
+collect build statistics like compile time and code size.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_USE_PERF</span></code></p>
+<p>Use the <code class="docutils literal notranslate"><span class="pre">perf</span></code> tool for time measurement instead of the <code class="docutils literal notranslate"><span class="pre">timeit</span></code> tool that
+comes with the test-suite. The <code class="docutils literal notranslate"><span class="pre">perf</span></code> is usually available on linux systems.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">TEST_SUITE_SPEC2000_ROOT</span></code>, <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_SPEC2006_ROOT</span></code>, <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_SPEC2017_ROOT</span></code>, â¦</p>
+<p>Specify installation directories of external benchmark suites. You can find
+more information about expected versions or usage in the README files in the
+<code class="docutils literal notranslate"><span class="pre">External</span></code> directory (such as <code class="docutils literal notranslate"><span class="pre">External/SPEC/README</span></code>)</p>
+</li>
+</ul>
+</div>
+<div class="section" id="common-cmake-flags">
+<span id="common-cmake-flags"></span><h3>Common CMake Flags<a class="headerlink" href="#common-cmake-flags" title="Permalink to this headline">¶</a></h3>
+<ul>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">-GNinja</span></code></p>
+<p>Generate build files for the ninja build tool.</p>
+</li>
+<li><p class="first"><code class="docutils literal notranslate"><span class="pre">-Ctest-suite/cmake/caches/<cachefile.cmake></span></code></p>
+<p>Use a CMake cache. The test-suite comes with several CMake caches which
+predefine common or tricky build configurations.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="section" id="displaying-and-analyzing-results">
+<span id="displaying-and-analyzing-results"></span><h2>Displaying and Analyzing Results<a class="headerlink" href="#displaying-and-analyzing-results" title="Permalink to this headline">¶</a></h2>
+<p>The <code class="docutils literal notranslate"><span class="pre">compare.py</span></code> script displays and compares result files. A result file is
+produced when invoking lit with the <code class="docutils literal notranslate"><span class="pre">-o</span> <span class="pre">filename.json</span></code> flag.</p>
+<p>Example usage:</p>
+<ul>
+<li><p class="first">Basic Usage:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>% test-suite/utils/compare.py baseline.json
+Warning: 'test-suite :: External/SPEC/CINT2006/403.gcc/403.gcc.test' has No metrics!
+Tests: 508
+Metric: exec_time
+
+Program baseline
+
+INT2006/456.hmmer/456.hmmer 1222.90
+INT2006/464.h264ref/464.h264ref 928.70
+...
+ baseline
+count 506.000000
+mean 20.563098
+std 111.423325
+min 0.003400
+25% 0.011200
+50% 0.339450
+75% 4.067200
+max 1222.896800
+</pre></div>
+</div>
+</li>
+<li><p class="first">Show compile_time or text segment size metrics:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% test-suite/utils/compare.py -m compile_time baseline.json
+% test-suite/utils/compare.py -m size.__text baseline.json
+</pre></div>
+</div>
+</li>
+<li><p class="first">Compare two result files and filter short running tests:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% test-suite/utils/compare.py --filter-short baseline.json experiment.json
+...
+Program baseline experiment diff
+
+SingleSour.../Benchmarks/Linpack/linpack-pc <span class="m">5</span>.16 <span class="m">4</span>.30 -16.5%
+MultiSourc...erolling-dbl/LoopRerolling-dbl <span class="m">7</span>.01 <span class="m">7</span>.86 <span class="m">12</span>.2%
+SingleSour...UnitTests/Vectorizer/gcc-loops <span class="m">3</span>.89 <span class="m">3</span>.54 -9.0%
+...
+</pre></div>
+</div>
+</li>
+<li><p class="first">Merge multiple baseline and experiment result files by taking the minimum
+runtime each:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% test-suite/utils/compare.py base0.json base1.json base2.json vs exp0.json exp1.json exp2.json
+</pre></div>
+</div>
+</li>
+</ul>
+<div class="section" id="continuous-tracking-with-lnt">
+<span id="continuous-tracking-with-lnt"></span><h3>Continuous Tracking with LNT<a class="headerlink" href="#continuous-tracking-with-lnt" title="Permalink to this headline">¶</a></h3>
+<p>LNT is a set of client and server tools for continuously monitoring
+performance. You can find more information at
+<a class="reference external" href="http://llvm.org/docs/lnt">http://llvm.org/docs/lnt</a>. The official LNT instance
+of the LLVM project is hosted at <a class="reference external" href="http://lnt.llvm.org">http://lnt.llvm.org</a>.</p>
+</div>
+</div>
+<div class="section" id="external-suites">
+<span id="external-suites"></span><h2>External Suites<a class="headerlink" href="#external-suites" title="Permalink to this headline">¶</a></h2>
+<p>External suites such as SPEC can be enabled by either</p>
+<ul class="simple">
+<li>placing (or linking) them into the <code class="docutils literal notranslate"><span class="pre">test-suite/test-suite-externals/xxx</span></code> directory (example: <code class="docutils literal notranslate"><span class="pre">test-suite/test-suite-externals/speccpu2000</span></code>)</li>
+<li>using a configuration option such as <code class="docutils literal notranslate"><span class="pre">-D</span> <span class="pre">TEST_SUITE_SPEC2000_ROOT=path/to/speccpu2000</span></code></li>
+</ul>
+<p>You can find further information in the respective README files such as
+<code class="docutils literal notranslate"><span class="pre">test-suite/External/SPEC/README</span></code>.</p>
+<p>For the SPEC benchmarks you can switch between the <code class="docutils literal notranslate"><span class="pre">test</span></code>, <code class="docutils literal notranslate"><span class="pre">train</span></code> and
+<code class="docutils literal notranslate"><span class="pre">ref</span></code> input datasets via the <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_RUN_TYPE</span></code> configuration option.
+The <code class="docutils literal notranslate"><span class="pre">train</span></code> dataset is used by default.</p>
+</div>
+<div class="section" id="custom-suites">
+<span id="custom-suites"></span><h2>Custom Suites<a class="headerlink" href="#custom-suites" title="Permalink to this headline">¶</a></h2>
+<p>You can build custom suites using the test-suite infrastructure. A custom suite
+has a <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> file at the top directory. The <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> will be
+picked up automatically if placed into a subdirectory of the test-suite or when
+setting the <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_SUBDIRS</span></code> variable:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% cmake -DTEST_SUITE_SUBDIRS<span class="o">=</span>path/to/my/benchmark-suite ../test-suite
+</pre></div>
+</div>
+</div>
+<div class="section" id="profile-guided-optimization">
+<span id="profile-guided-optimization"></span><h2>Profile Guided Optimization<a class="headerlink" href="#profile-guided-optimization" title="Permalink to this headline">¶</a></h2>
+<p>Profile guided optimization requires to compile and run twice. First the
+benchmark should be compiled with profile generation instrumentation enabled
+and setup for training data. The lit runner will merge the profile files
+using <code class="docutils literal notranslate"><span class="pre">llvm-profdata</span></code> so they can be used by the second compilation run.</p>
+<p>Example:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span><span class="c1"># Profile generation run:</span>
+% cmake -DTEST_SUITE_PROFILE_GENERATE<span class="o">=</span>ON <span class="se">\</span>
+ -DTEST_SUITE_RUN_TYPE<span class="o">=</span>train <span class="se">\</span>
+ ../test-suite
+% make
+% llvm-lit .
+<span class="c1"># Use the profile data for compilation and actual benchmark run:</span>
+% cmake -DTEST_SUITE_PROFILE_GENERATE<span class="o">=</span>OFF <span class="se">\</span>
+ -DTEST_SUITE_PROFILE_USE<span class="o">=</span>ON <span class="se">\</span>
+ -DTEST_SUITE_RUN_TYPE<span class="o">=</span>ref <span class="se">\</span>
+ .
+% make
+% llvm-lit -o result.json .
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_RUN_TYPE</span></code> setting only affects the SPEC benchmark suites.</p>
+</div>
+<div class="section" id="cross-compilation-and-external-devices">
+<span id="cross-compilation-and-external-devices"></span><h2>Cross Compilation and External Devices<a class="headerlink" href="#cross-compilation-and-external-devices" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="compilation">
+<span id="compilation"></span><h3>Compilation<a class="headerlink" href="#compilation" title="Permalink to this headline">¶</a></h3>
+<p>CMake allows to cross compile to a different target via toolchain files. More
+information can be found here:</p>
+<ul class="simple">
+<li><a class="reference external" href="http://llvm.org/docs/lnt/tests.html#cross-compiling">http://llvm.org/docs/lnt/tests.html#cross-compiling</a></li>
+<li><a class="reference external" href="https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html">https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html</a></li>
+</ul>
+<p>Cross compilation from macOS to iOS is possible with the
+<code class="docutils literal notranslate"><span class="pre">test-suite/cmake/caches/target-target-*-iphoneos-internal.cmake</span></code> CMake cache
+files; this requires an internal iOS SDK.</p>
+</div>
+<div class="section" id="running">
+<span id="running"></span><h3>Running<a class="headerlink" href="#running" title="Permalink to this headline">¶</a></h3>
+<p>There are two ways to run the tests in a cross compilation setting:</p>
+<ul>
+<li><p class="first">Via SSH connection to an external device: The <code class="docutils literal notranslate"><span class="pre">TEST_SUITE_REMOTE_HOST</span></code> option
+should be set to the SSH hostname. The executables and data files need to be
+transferred to the device after compilation. This is typically done via the
+<code class="docutils literal notranslate"><span class="pre">rsync</span></code> make target. After this, the lit runner can be used on the host
+machine. It will prefix the benchmark and verification command lines with an
+<code class="docutils literal notranslate"><span class="pre">ssh</span></code> command.</p>
+<p>Example:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% cmake -G Ninja -D <span class="nv">CMAKE_C_COMPILER</span><span class="o">=</span>path/to/clang <span class="se">\</span>
+ -C ../test-suite/cmake/caches/target-arm64-iphoneos-internal.cmake <span class="se">\</span>
+ -D <span class="nv">TEST_SUITE_REMOTE_HOST</span><span class="o">=</span>mydevice <span class="se">\</span>
+ ../test-suite
+% ninja
+% ninja rsync
+% llvm-lit -j1 -o result.json .
+</pre></div>
+</div>
+</li>
+<li><p class="first">You can specify a simulator for the target machine with the
+<code class="docutils literal notranslate"><span class="pre">TEST_SUITE_RUN_UNDER</span></code> setting. The lit runner will prefix all benchmark
+invocations with it.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="section" id="running-the-test-suite-via-lnt">
+<span id="running-the-test-suite-via-lnt"></span><h2>Running the test-suite via LNT<a class="headerlink" href="#running-the-test-suite-via-lnt" title="Permalink to this headline">¶</a></h2>
+<p>The LNT tool can run the test-suite. Use this when submitting test results to
+an LNT instance. See
+<a class="reference external" href="http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite">http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite</a>
+for details.</p>
+</div>
+<div class="section" id="running-the-test-suite-via-makefiles-deprecated">
+<span id="running-the-test-suite-via-makefiles-deprecated"></span><h2>Running the test-suite via Makefiles (deprecated)<a class="headerlink" href="#running-the-test-suite-via-makefiles-deprecated" title="Permalink to this headline">¶</a></h2>
+<p><strong>Note</strong>: The test-suite comes with a set of Makefiles that are considered
+deprecated. They do not support newer testing modes like <code class="docutils literal notranslate"><span class="pre">Bitcode</span></code> or
+<code class="docutils literal notranslate"><span class="pre">Microbenchmarks</span></code> and are harder to use.</p>
+<p>Old documentation is available in the
+<a class="reference external" href="TestSuiteMakefileGuide">test-suite Makefile Guide</a>.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="TestSuiteMakefileGuide.html" title="test-suite Makefile Guide (deprecated)"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="TestingGuide.html" title="LLVM Testing Infrastructure Guide"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="TestingGuide.html" >LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TestSuiteMakefileGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TestSuiteMakefileGuide.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TestSuiteMakefileGuide.html (added)
+++ www-releases/trunk/9.0.0/docs/TestSuiteMakefileGuide.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,265 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>test-suite Makefile Guide (deprecated) — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="LLVM Tutorial: Table of Contents" href="tutorial/index.html" />
+ <link rel="prev" title="test-suite Guide" href="TestSuiteGuide.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" role="navigation" aria-label="related navigation">
+ <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="tutorial/index.html" title="LLVM Tutorial: Table of Contents"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="TestSuiteGuide.html" title="test-suite 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 class="nav-item nav-item-1"><a href="TestingGuide.html" accesskey="U">LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body" role="main">
+
+ <div class="section" id="test-suite-makefile-guide-deprecated">
+<h1>test-suite Makefile Guide (deprecated)<a class="headerlink" href="#test-suite-makefile-guide-deprecated" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#overview" id="id1">Overview</a></li>
+<li><a class="reference internal" href="#configuring-external-tests" id="id2">Configuring External Tests</a></li>
+<li><a class="reference internal" href="#running-different-tests" id="id3">Running Different Tests</a></li>
+<li><a class="reference internal" href="#generating-test-output" id="id4">Generating Test Output</a></li>
+<li><a class="reference internal" href="#writing-custom-tests-for-the-test-suite" id="id5">Writing Custom Tests for the test-suite</a></li>
+</ul>
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id1">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
+<p>First, all tests are executed within the LLVM object directory tree.
+They <em>are not</em> executed inside of the LLVM source tree. This is because
+the test suite creates temporary files during execution.</p>
+<p>To run the test suite, you need to use the following steps:</p>
+<ol class="arabic">
+<li><p class="first">Check out the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> module with:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% git clone https://github.com/llvm/llvm-test-suite.git test-suite
+</pre></div>
+</div>
+</li>
+<li><p class="first">FIXME: these directions are outdated and wonât work. Figure out
+what the correct thing to do is, and write it down here.</p>
+</li>
+<li><p class="first">Configure and build <code class="docutils literal notranslate"><span class="pre">llvm</span></code>.</p>
+</li>
+<li><p class="first">Configure and build <code class="docutils literal notranslate"><span class="pre">llvm-gcc</span></code>.</p>
+</li>
+<li><p class="first">Install <code class="docutils literal notranslate"><span class="pre">llvm-gcc</span></code> somewhere.</p>
+</li>
+<li><p class="first"><em>Re-configure</em> <code class="docutils literal notranslate"><span class="pre">llvm</span></code> from the top level of each build tree (LLVM
+object directory tree) in which you want to run the test suite, just
+as you do before building LLVM.</p>
+<p>During the <em>re-configuration</em>, you must either: (1) have <code class="docutils literal notranslate"><span class="pre">llvm-gcc</span></code>
+you just built in your path, or (2) specify the directory where your
+just-built <code class="docutils literal notranslate"><span class="pre">llvm-gcc</span></code> is installed using
+<code class="docutils literal notranslate"><span class="pre">--with-llvmgccdir=$LLVM_GCC_DIR</span></code>.</p>
+<p>You must also tell the configure machinery that the test suite is
+available so it can be configured for your build tree:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% <span class="nb">cd</span> <span class="nv">$LLVM_OBJ_ROOT</span> <span class="p">;</span> <span class="nv">$LLVM_SRC_ROOT</span>/configure <span class="o">[</span>--with-llvmgccdir<span class="o">=</span><span class="nv">$LLVM_GCC_DIR</span><span class="o">]</span>
+</pre></div>
+</div>
+<p>[Remember that <code class="docutils literal notranslate"><span class="pre">$LLVM_GCC_DIR</span></code> is the directory where you
+<em>installed</em> llvm-gcc, not its src or obj directory.]</p>
+</li>
+<li><p class="first">You can now run the test suite from your build tree as follows:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% <span class="nb">cd</span> <span class="nv">$LLVM_OBJ_ROOT</span>/projects/test-suite
+% make
+</pre></div>
+</div>
+</li>
+</ol>
+<p>Note that the second and third steps only need to be done once. After
+you have the suite checked out and configured, you donât need to do it
+again (unless the test code or configure script changes).</p>
+</div>
+<div class="section" id="configuring-external-tests">
+<h2><a class="toc-backref" href="#id2">Configuring External Tests</a><a class="headerlink" href="#configuring-external-tests" title="Permalink to this headline">¶</a></h2>
+<p>In order to run the External tests in the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> module, you
+must specify <em>âwith-externals</em>. This must be done during the
+<em>re-configuration</em> step (see above), and the <code class="docutils literal notranslate"><span class="pre">llvm</span></code> re-configuration
+must recognize the previously-built <code class="docutils literal notranslate"><span class="pre">llvm-gcc</span></code>. If any of these is
+missing or neglected, the External tests wonât work.</p>
+<ul class="simple">
+<li><em>âwith-externals</em></li>
+<li><em>âwith-externals=<directory></em></li>
+</ul>
+<p>This tells LLVM where to find any external tests. They are expected to
+be in specifically named subdirectories of <<code class="docutils literal notranslate"><span class="pre">directory</span></code>>. If
+<code class="docutils literal notranslate"><span class="pre">directory</span></code> is left unspecified, <code class="docutils literal notranslate"><span class="pre">configure</span></code> uses the default value
+<code class="docutils literal notranslate"><span class="pre">/home/vadve/shared/benchmarks/speccpu2000/benchspec</span></code>. Subdirectory
+names known to LLVM include:</p>
+<ul class="simple">
+<li>spec95</li>
+<li>speccpu2000</li>
+<li>speccpu2006</li>
+<li>povray31</li>
+</ul>
+<p>Others are added from time to time, and can be determined from
+<code class="docutils literal notranslate"><span class="pre">configure</span></code>.</p>
+</div>
+<div class="section" id="running-different-tests">
+<h2><a class="toc-backref" href="#id3">Running Different Tests</a><a class="headerlink" href="#running-different-tests" title="Permalink to this headline">¶</a></h2>
+<p>In addition to the regular âwhole programâ tests, the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code>
+module also provides a mechanism for compiling the programs in different
+ways. If the variable TEST is defined on the <code class="docutils literal notranslate"><span class="pre">gmake</span></code> command line, the
+test system will include a Makefile named
+<code class="docutils literal notranslate"><span class="pre">TEST.<value</span> <span class="pre">of</span> <span class="pre">TEST</span> <span class="pre">variable>.Makefile</span></code>. This Makefile can modify
+build rules to yield different results.</p>
+<p>For example, the LLVM nightly tester uses <code class="docutils literal notranslate"><span class="pre">TEST.nightly.Makefile</span></code> to
+create the nightly test reports. To run the nightly tests, run
+<code class="docutils literal notranslate"><span class="pre">gmake</span> <span class="pre">TEST=nightly</span></code>.</p>
+<p>There are several TEST Makefiles available in the tree. Some of them are
+designed for internal LLVM research and will not work outside of the
+LLVM research group. They may still be valuable, however, as a guide to
+writing your own TEST Makefile for any optimization or analysis passes
+that you develop with LLVM.</p>
+</div>
+<div class="section" id="generating-test-output">
+<h2><a class="toc-backref" href="#id4">Generating Test Output</a><a class="headerlink" href="#generating-test-output" title="Permalink to this headline">¶</a></h2>
+<p>There are a number of ways to run the tests and generate output. The
+most simple one is simply running <code class="docutils literal notranslate"><span class="pre">gmake</span></code> with no arguments. This will
+compile and run all programs in the tree using a number of different
+methods and compare results. Any failures are reported in the output,
+but are likely drowned in the other output. Passes are not reported
+explicitly.</p>
+<p>Somewhat better is running <code class="docutils literal notranslate"><span class="pre">gmake</span> <span class="pre">TEST=sometest</span> <span class="pre">test</span></code>, which runs the
+specified test and usually adds per-program summaries to the output
+(depending on which sometest you use). For example, the <code class="docutils literal notranslate"><span class="pre">nightly</span></code> test
+explicitly outputs TEST-PASS or TEST-FAIL for every test after each
+program. Though these lines are still drowned in the output, itâs easy
+to grep the output logs in the Output directories.</p>
+<p>Even better are the <code class="docutils literal notranslate"><span class="pre">report</span></code> and <code class="docutils literal notranslate"><span class="pre">report.format</span></code> targets (where
+<code class="docutils literal notranslate"><span class="pre">format</span></code> is one of <code class="docutils literal notranslate"><span class="pre">html</span></code>, <code class="docutils literal notranslate"><span class="pre">csv</span></code>, <code class="docutils literal notranslate"><span class="pre">text</span></code> or <code class="docutils literal notranslate"><span class="pre">graphs</span></code>). The
+exact contents of the report are dependent on which <code class="docutils literal notranslate"><span class="pre">TEST</span></code> you are
+running, but the text results are always shown at the end of the run and
+the results are always stored in the <code class="docutils literal notranslate"><span class="pre">report.<type>.format</span></code> file (when
+running with <code class="docutils literal notranslate"><span class="pre">TEST=<type></span></code>). The <code class="docutils literal notranslate"><span class="pre">report</span></code> also generate a file
+called <code class="docutils literal notranslate"><span class="pre">report.<type>.raw.out</span></code> containing the output of the entire
+test run.</p>
+</div>
+<div class="section" id="writing-custom-tests-for-the-test-suite">
+<h2><a class="toc-backref" href="#id5">Writing Custom Tests for the test-suite</a><a class="headerlink" href="#writing-custom-tests-for-the-test-suite" title="Permalink to this headline">¶</a></h2>
+<p>Assuming you can run the test suite, (e.g.
+â<code class="docutils literal notranslate"><span class="pre">gmake</span> <span class="pre">TEST=nightly</span> <span class="pre">report</span></code>â should work), it is really easy to run
+optimizations or code generator components against every program in the
+tree, collecting statistics or running custom checks for correctness. At
+base, this is how the nightly tester works, itâs just one example of a
+general framework.</p>
+<p>Lets say that you have an LLVM optimization pass, and you want to see
+how many times it triggers. First thing you should do is add an LLVM
+<a class="reference external" href="ProgrammersManual.html#Statistic">statistic</a> to your pass, which will
+tally counts of things you care about.</p>
+<p>Following this, you can set up a test and a report that collects these
+and formats them for easy viewing. This consists of two files, a
+â<code class="docutils literal notranslate"><span class="pre">test-suite/TEST.XXX.Makefile</span></code>â fragment (where XXX is the name of
+your test) and a â<code class="docutils literal notranslate"><span class="pre">test-suite/TEST.XXX.report</span></code>â file that indicates
+how to format the output into a table. There are many example reports of
+various levels of sophistication included with the test suite, and the
+framework is very general.</p>
+<p>If you are interested in testing an optimization pass, check out the
+âlibcallsâ test as an example. It can be run like this:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% <span class="nb">cd</span> llvm/projects/test-suite/MultiSource/Benchmarks <span class="c1"># or some other level</span>
+% make <span class="nv">TEST</span><span class="o">=</span>libcalls report
+</pre></div>
+</div>
+<p>This will do a bunch of stuff, then eventually print a table like this:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Name</span> <span class="o">|</span> <span class="n">total</span> <span class="o">|</span> <span class="c1">#exit |</span>
+<span class="o">...</span>
+<span class="n">FreeBench</span><span class="o">/</span><span class="n">analyzer</span><span class="o">/</span><span class="n">analyzer</span> <span class="o">|</span> <span class="mi">51</span> <span class="o">|</span> <span class="mi">6</span> <span class="o">|</span>
+<span class="n">FreeBench</span><span class="o">/</span><span class="n">fourinarow</span><span class="o">/</span><span class="n">fourinarow</span> <span class="o">|</span> <span class="mi">1</span> <span class="o">|</span> <span class="mi">1</span> <span class="o">|</span>
+<span class="n">FreeBench</span><span class="o">/</span><span class="n">neural</span><span class="o">/</span><span class="n">neural</span> <span class="o">|</span> <span class="mi">19</span> <span class="o">|</span> <span class="mi">9</span> <span class="o">|</span>
+<span class="n">FreeBench</span><span class="o">/</span><span class="n">pifft</span><span class="o">/</span><span class="n">pifft</span> <span class="o">|</span> <span class="mi">5</span> <span class="o">|</span> <span class="mi">3</span> <span class="o">|</span>
+<span class="n">MallocBench</span><span class="o">/</span><span class="n">cfrac</span><span class="o">/</span><span class="n">cfrac</span> <span class="o">|</span> <span class="mi">1</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="n">MallocBench</span><span class="o">/</span><span class="n">espresso</span><span class="o">/</span><span class="n">espresso</span> <span class="o">|</span> <span class="mi">52</span> <span class="o">|</span> <span class="mi">12</span> <span class="o">|</span>
+<span class="n">MallocBench</span><span class="o">/</span><span class="n">gs</span><span class="o">/</span><span class="n">gs</span> <span class="o">|</span> <span class="mi">4</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="n">Prolangs</span><span class="o">-</span><span class="n">C</span><span class="o">/</span><span class="n">TimberWolfMC</span><span class="o">/</span><span class="n">timberwolfmc</span> <span class="o">|</span> <span class="mi">302</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="n">Prolangs</span><span class="o">-</span><span class="n">C</span><span class="o">/</span><span class="n">agrep</span><span class="o">/</span><span class="n">agrep</span> <span class="o">|</span> <span class="mi">33</span> <span class="o">|</span> <span class="mi">12</span> <span class="o">|</span>
+<span class="n">Prolangs</span><span class="o">-</span><span class="n">C</span><span class="o">/</span><span class="n">allroots</span><span class="o">/</span><span class="n">allroots</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="n">Prolangs</span><span class="o">-</span><span class="n">C</span><span class="o">/</span><span class="n">assembler</span><span class="o">/</span><span class="n">assembler</span> <span class="o">|</span> <span class="mi">47</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="n">Prolangs</span><span class="o">-</span><span class="n">C</span><span class="o">/</span><span class="n">bison</span><span class="o">/</span><span class="n">mybison</span> <span class="o">|</span> <span class="mi">74</span> <span class="o">|</span> <span class="o">*</span> <span class="o">|</span>
+<span class="o">...</span>
+</pre></div>
+</div>
+<p>This basically is grepping the -stats output and displaying it in a
+table. You can also use the âTEST=libcalls report.htmlâ target to get
+the table in HTML form, similarly for report.csv and report.tex.</p>
+<p>The source for this is in <code class="docutils literal notranslate"><span class="pre">test-suite/TEST.libcalls.*</span></code>. The format is
+pretty simple: the Makefile indicates how to run the test (in this case,
+â<code class="docutils literal notranslate"><span class="pre">opt</span> <span class="pre">-simplify-libcalls</span> <span class="pre">-stats</span></code>â), and the report contains one line
+for each column of the output. The first value is the header for the
+column and the second is the regex to grep the output of the command
+for. There are lots of example reports that can do fancy stuff.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="tutorial/index.html" title="LLVM Tutorial: Table of Contents"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="TestSuiteGuide.html" title="test-suite Guide"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ <li class="nav-item nav-item-1"><a href="TestingGuide.html" >LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TestingGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TestingGuide.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TestingGuide.html (added)
+++ www-releases/trunk/9.0.0/docs/TestingGuide.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,614 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>LLVM Testing Infrastructure Guide — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="test-suite Guide" href="TestSuiteGuide.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" role="navigation" aria-label="related navigation">
+ <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="TestSuiteGuide.html" title="test-suite Guide"
+ 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" role="main">
+
+ <div class="section" id="llvm-testing-infrastructure-guide">
+<h1>LLVM Testing Infrastructure Guide<a class="headerlink" href="#llvm-testing-infrastructure-guide" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#overview" id="id2">Overview</a></li>
+<li><a class="reference internal" href="#requirements" id="id3">Requirements</a></li>
+<li><a class="reference internal" href="#llvm-testing-infrastructure-organization" id="id4">LLVM Testing Infrastructure Organization</a><ul>
+<li><a class="reference internal" href="#unit-tests" id="id5">Unit tests</a></li>
+<li><a class="reference internal" href="#regression-tests" id="id6">Regression tests</a></li>
+<li><a class="reference internal" href="#test-suite" id="id7"><code class="docutils literal notranslate"><span class="pre">test-suite</span></code></a></li>
+<li><a class="reference internal" href="#debugging-information-tests" id="id8">Debugging Information tests</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#quick-start" id="id9">Quick start</a><ul>
+<li><a class="reference internal" href="#unit-and-regression-tests" id="id10">Unit and Regression tests</a></li>
+<li><a class="reference internal" href="#id1" id="id11">Debugging Information tests</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#regression-test-structure" id="id12">Regression test structure</a><ul>
+<li><a class="reference internal" href="#writing-new-regression-tests" id="id13">Writing new regression tests</a></li>
+<li><a class="reference internal" href="#extra-files" id="id14">Extra files</a></li>
+<li><a class="reference internal" href="#fragile-tests" id="id15">Fragile tests</a></li>
+<li><a class="reference internal" href="#platform-specific-tests" id="id16">Platform-Specific Tests</a></li>
+<li><a class="reference internal" href="#constraining-test-execution" id="id17">Constraining test execution</a></li>
+<li><a class="reference internal" href="#substitutions" id="id18">Substitutions</a></li>
+<li><a class="reference internal" href="#options" id="id19">Options</a></li>
+<li><a class="reference internal" href="#other-features" id="id20">Other Features</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="toctree-wrapper compound">
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id2">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
+<p>This document is the reference manual for the LLVM testing
+infrastructure. It documents the structure of the LLVM testing
+infrastructure, the tools needed to use it, and how to add and run
+tests.</p>
+</div>
+<div class="section" id="requirements">
+<h2><a class="toc-backref" href="#id3">Requirements</a><a class="headerlink" href="#requirements" title="Permalink to this headline">¶</a></h2>
+<p>In order to use the LLVM testing infrastructure, you will need all of the
+software required to build LLVM, as well as <a class="reference external" href="http://python.org">Python</a> 2.7 or
+later.</p>
+</div>
+<div class="section" id="llvm-testing-infrastructure-organization">
+<h2><a class="toc-backref" href="#id4">LLVM Testing Infrastructure Organization</a><a class="headerlink" href="#llvm-testing-infrastructure-organization" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM testing infrastructure contains three major categories of tests:
+unit tests, regression tests and whole programs. The unit tests and regression
+tests are contained inside the LLVM repository itself under <code class="docutils literal notranslate"><span class="pre">llvm/unittests</span></code>
+and <code class="docutils literal notranslate"><span class="pre">llvm/test</span></code> respectively and are expected to always pass â they should be
+run before every commit.</p>
+<p>The whole programs tests are referred to as the âLLVM test suiteâ (or
+âtest-suiteâ) and are in the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> module in subversion. For
+historical reasons, these tests are also referred to as the ânightly
+testsâ in places, which is less ambiguous than âtest-suiteâ and remains
+in use although we run them much more often than nightly.</p>
+<div class="section" id="unit-tests">
+<h3><a class="toc-backref" href="#id5">Unit tests</a><a class="headerlink" href="#unit-tests" title="Permalink to this headline">¶</a></h3>
+<p>Unit tests are written using <a class="reference external" href="https://github.com/google/googletest/blob/master/googletest/docs/primer.md">Google Test</a>
+and <a class="reference external" href="https://github.com/google/googletest/blob/master/googlemock/docs/ForDummies.md">Google Mock</a>
+and are located in the <code class="docutils literal notranslate"><span class="pre">llvm/unittests</span></code> directory.</p>
+</div>
+<div class="section" id="regression-tests">
+<h3><a class="toc-backref" href="#id6">Regression tests</a><a class="headerlink" href="#regression-tests" title="Permalink to this headline">¶</a></h3>
+<p>The regression tests are small pieces of code that test a specific
+feature of LLVM or trigger a specific bug in LLVM. The language they are
+written in depends on the part of LLVM being tested. These tests are driven by
+the <a class="reference internal" href="CommandGuide/lit.html"><span class="doc">Lit</span></a> testing tool (which is part of LLVM), and
+are located in the <code class="docutils literal notranslate"><span class="pre">llvm/test</span></code> directory.</p>
+<p>Typically when a bug is found in LLVM, a regression test containing just
+enough code to reproduce the problem should be written and placed
+somewhere underneath this directory. For example, it can be a small
+piece of LLVM IR distilled from an actual application or benchmark.</p>
+</div>
+<div class="section" id="test-suite">
+<h3><a class="toc-backref" href="#id7"><code class="docutils literal notranslate"><span class="pre">test-suite</span></code></a><a class="headerlink" href="#test-suite" title="Permalink to this headline">¶</a></h3>
+<p>The test suite contains whole programs, which are pieces of code which
+can be compiled and linked into a stand-alone program that can be
+executed. These programs are generally written in high level languages
+such as C or C++.</p>
+<p>These programs are compiled using a user specified compiler and set of
+flags, and then executed to capture the program output and timing
+information. The output of these programs is compared to a reference
+output to ensure that the program is being compiled correctly.</p>
+<p>In addition to compiling and executing programs, whole program tests
+serve as a way of benchmarking LLVM performance, both in terms of the
+efficiency of the programs generated as well as the speed with which
+LLVM compiles, optimizes, and generates code.</p>
+<p>The test-suite is located in the <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> Subversion module.</p>
+<p>See the <a class="reference internal" href="TestSuiteGuide.html"><span class="doc">test-suite Guide</span></a> for details.</p>
+</div>
+<div class="section" id="debugging-information-tests">
+<h3><a class="toc-backref" href="#id8">Debugging Information tests</a><a class="headerlink" href="#debugging-information-tests" title="Permalink to this headline">¶</a></h3>
+<p>The test suite contains tests to check quality of debugging information.
+The test are written in C based languages or in LLVM assembly language.</p>
+<p>These tests are compiled and run under a debugger. The debugger output
+is checked to validate of debugging information. See README.txt in the
+test suite for more information . This test suite is located in the
+<code class="docutils literal notranslate"><span class="pre">debuginfo-tests</span></code> Subversion module.</p>
+</div>
+</div>
+<div class="section" id="quick-start">
+<h2><a class="toc-backref" href="#id9">Quick start</a><a class="headerlink" href="#quick-start" title="Permalink to this headline">¶</a></h2>
+<p>The tests are located in two separate Subversion modules. The unit and
+regression tests are in the main âllvmâ module under the directories
+<code class="docutils literal notranslate"><span class="pre">llvm/unittests</span></code> and <code class="docutils literal notranslate"><span class="pre">llvm/test</span></code> (so you get these tests for free with the
+main LLVM tree). Use <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">check-all</span></code> to run the unit and regression tests
+after building LLVM.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">test-suite</span></code> module contains more comprehensive tests including whole C
+and C++ programs. See the <a class="reference internal" href="TestSuiteGuide.html"><span class="doc">test-suite Guide</span></a> for details.</p>
+<div class="section" id="unit-and-regression-tests">
+<h3><a class="toc-backref" href="#id10">Unit and Regression tests</a><a class="headerlink" href="#unit-and-regression-tests" title="Permalink to this headline">¶</a></h3>
+<p>To run all of the LLVM unit tests use the check-llvm-unit target:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% make check-llvm-unit
+</pre></div>
+</div>
+<p>To run all of the LLVM regression tests use the check-llvm target:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% make check-llvm
+</pre></div>
+</div>
+<p>In order to get reasonable testing performance, build LLVM and subprojects
+in release mode, i.e.</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% cmake -DCMAKE_BUILD_TYPE<span class="o">=</span><span class="s2">"Release"</span> -DLLVM_ENABLE_ASSERTIONS<span class="o">=</span>On
+</pre></div>
+</div>
+<p>If you have <a class="reference external" href="http://clang.llvm.org/">Clang</a> checked out and built, you
+can run the LLVM and Clang tests simultaneously using:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% make check-all
+</pre></div>
+</div>
+<p>To run the tests with Valgrind (Memcheck by default), use the <code class="docutils literal notranslate"><span class="pre">LIT_ARGS</span></code> make
+variable to pass the required options to lit. For example, you can use:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% make check <span class="nv">LIT_ARGS</span><span class="o">=</span><span class="s2">"-v --vg --vg-leak"</span>
+</pre></div>
+</div>
+<p>to enable testing with valgrind and with leak checking enabled.</p>
+<p>To run individual tests or subsets of tests, you can use the <code class="docutils literal notranslate"><span class="pre">llvm-lit</span></code>
+script which is built as part of LLVM. For example, to run the
+<code class="docutils literal notranslate"><span class="pre">Integer/BitPacked.ll</span></code> test by itself you can run:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% llvm-lit ~/llvm/test/Integer/BitPacked.ll
+</pre></div>
+</div>
+<p>or to run all of the ARM CodeGen tests:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>% llvm-lit ~/llvm/test/CodeGen/ARM
+</pre></div>
+</div>
+<p>For more information on using the <strong class="program">lit</strong> tool, see <code class="docutils literal notranslate"><span class="pre">llvm-lit</span> <span class="pre">--help</span></code>
+or the <a class="reference internal" href="CommandGuide/lit.html"><span class="doc">lit man page</span></a>.</p>
+</div>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id11">Debugging Information tests</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<p>To run debugging information tests simply add the <code class="docutils literal notranslate"><span class="pre">debuginfo-tests</span></code>
+project to your <code class="docutils literal notranslate"><span class="pre">LLVM_ENABLE_PROJECTS</span></code> define on the cmake
+command-line.</p>
+</div>
+</div>
+<div class="section" id="regression-test-structure">
+<h2><a class="toc-backref" href="#id12">Regression test structure</a><a class="headerlink" href="#regression-test-structure" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM regression tests are driven by <strong class="program">lit</strong> and are located in the
+<code class="docutils literal notranslate"><span class="pre">llvm/test</span></code> directory.</p>
+<p>This directory contains a large array of small tests that exercise
+various features of LLVM and to ensure that regressions do not occur.
+The directory is broken into several sub-directories, each focused on a
+particular area of LLVM.</p>
+<div class="section" id="writing-new-regression-tests">
+<h3><a class="toc-backref" href="#id13">Writing new regression tests</a><a class="headerlink" href="#writing-new-regression-tests" title="Permalink to this headline">¶</a></h3>
+<p>The regression test structure is very simple, but does require some
+information to be set. This information is gathered via <code class="docutils literal notranslate"><span class="pre">configure</span></code>
+and is written to a file, <code class="docutils literal notranslate"><span class="pre">test/lit.site.cfg</span></code> in the build directory.
+The <code class="docutils literal notranslate"><span class="pre">llvm/test</span></code> Makefile does this work for you.</p>
+<p>In order for the regression tests to work, each directory of tests must
+have a <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code> file. <strong class="program">lit</strong> looks for this file to determine
+how to run the tests. This file is just Python code and thus is very
+flexible, but weâve standardized it for the LLVM regression tests. If
+youâre adding a directory of tests, just copy <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code> from
+another directory to get running. The standard <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code> simply
+specifies which files to look in for tests. Any directory that contains
+only directories does not need the <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code> file. Read the <a class="reference internal" href="CommandGuide/lit.html"><span class="doc">Lit
+documentation</span></a> for more information.</p>
+<p>Each test file must contain lines starting with âRUN:â that tell <strong class="program">lit</strong>
+how to run it. If there are no RUN lines, <strong class="program">lit</strong> will issue an error
+while running a test.</p>
+<p>RUN lines are specified in the comments of the test program using the
+keyword <code class="docutils literal notranslate"><span class="pre">RUN</span></code> followed by a colon, and lastly the command (pipeline)
+to execute. Together, these lines form the âscriptâ that <strong class="program">lit</strong>
+executes to run the test case. The syntax of the RUN lines is similar to a
+shellâs syntax for pipelines including I/O redirection and variable
+substitution. However, even though these lines may <em>look</em> like a shell
+script, they are not. RUN lines are interpreted by <strong class="program">lit</strong>.
+Consequently, the syntax differs from shell in a few ways. You can specify
+as many RUN lines as needed.</p>
+<p><strong class="program">lit</strong> performs substitution on each RUN line to replace LLVM tool names
+with the full paths to the executable built for each tool (in
+<code class="docutils literal notranslate"><span class="pre">$(LLVM_OBJ_ROOT)/$(BuildMode)/bin)</span></code>. This ensures that <strong class="program">lit</strong> does
+not invoke any stray LLVM tools in the userâs path during testing.</p>
+<p>Each RUN line is executed on its own, distinct from other lines unless
+its last character is <code class="docutils literal notranslate"><span class="pre">\</span></code>. This continuation character causes the RUN
+line to be concatenated with the next one. In this way you can build up
+long pipelines of commands without making huge line lengths. The lines
+ending in <code class="docutils literal notranslate"><span class="pre">\</span></code> are concatenated until a RUN line that doesnât end in
+<code class="docutils literal notranslate"><span class="pre">\</span></code> is found. This concatenated set of RUN lines then constitutes one
+execution. <strong class="program">lit</strong> will substitute variables and arrange for the pipeline
+to be executed. If any process in the pipeline fails, the entire line (and
+test case) fails too.</p>
+<p>Below is an example of legal RUN lines in a <code class="docutils literal notranslate"><span class="pre">.ll</span></code> file:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; RUN: llvm-as < %s | llvm-dis > %t1</span>
+<span class="c">; RUN: llvm-dis < %s.bc-13 > %t2</span>
+<span class="c">; RUN: diff %t1 %t2</span>
+</pre></div>
+</div>
+<p>As with a Unix shell, the RUN lines permit pipelines and I/O
+redirection to be used.</p>
+<p>There are some quoting rules that you must pay attention to when writing
+your RUN lines. In general nothing needs to be quoted. <strong class="program">lit</strong> wonât
+strip off any quote characters so they will get passed to the invoked program.
+To avoid this use curly braces to tell <strong class="program">lit</strong> that it should treat
+everything enclosed as one value.</p>
+<p>In general, you should strive to keep your RUN lines as simple as possible,
+using them only to run tools that generate textual output you can then examine.
+The recommended way to examine output to figure out if the test passes is using
+the <a class="reference internal" href="CommandGuide/FileCheck.html"><span class="doc">FileCheck tool</span></a>. <em>[The usage of grep in RUN
+lines is deprecated - please do not send or commit patches that use it.]</em></p>
+<p>Put related tests into a single file rather than having a separate file per
+test. Check if there are files already covering your feature and consider
+adding your code there instead of creating a new file.</p>
+</div>
+<div class="section" id="extra-files">
+<h3><a class="toc-backref" href="#id14">Extra files</a><a class="headerlink" href="#extra-files" title="Permalink to this headline">¶</a></h3>
+<p>If your test requires extra files besides the file containing the <code class="docutils literal notranslate"><span class="pre">RUN:</span></code>
+lines, the idiomatic place to put them is in a subdirectory <code class="docutils literal notranslate"><span class="pre">Inputs</span></code>.
+You can then refer to the extra files as <code class="docutils literal notranslate"><span class="pre">%S/Inputs/foo.bar</span></code>.</p>
+<p>For example, consider <code class="docutils literal notranslate"><span class="pre">test/Linker/ident.ll</span></code>. The directory structure is
+as follows:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">test</span><span class="o">/</span>
+ <span class="n">Linker</span><span class="o">/</span>
+ <span class="n">ident</span><span class="o">.</span><span class="n">ll</span>
+ <span class="n">Inputs</span><span class="o">/</span>
+ <span class="n">ident</span><span class="o">.</span><span class="n">a</span><span class="o">.</span><span class="n">ll</span>
+ <span class="n">ident</span><span class="o">.</span><span class="n">b</span><span class="o">.</span><span class="n">ll</span>
+</pre></div>
+</div>
+<p>For convenience, these are the contents:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">;;;;; ident.ll:</span>
+
+<span class="c">; RUN: llvm-link %S/Inputs/ident.a.ll %S/Inputs/ident.b.ll -S | FileCheck %s</span>
+
+<span class="c">; Verify that multiple input llvm.ident metadata are linked together.</span>
+
+<span class="c">; CHECK-DAG: !llvm.ident = !{!0, !1, !2}</span>
+<span class="c">; CHECK-DAG: "Compiler V1"</span>
+<span class="c">; CHECK-DAG: "Compiler V2"</span>
+<span class="c">; CHECK-DAG: "Compiler V3"</span>
+
+<span class="c">;;;;; Inputs/ident.a.ll:</span>
+
+<span class="nv">!llvm.ident</span> <span class="p">=</span> <span class="p">!{</span><span class="nv nv-Anonymous">!0</span><span class="p">,</span> <span class="nv nv-Anonymous">!1</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!0</span> <span class="p">=</span> <span class="kt">metadata</span> <span class="p">!{</span><span class="kt">metadata</span> <span class="nv">!"Compiler V1"</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!1</span> <span class="p">=</span> <span class="kt">metadata</span> <span class="p">!{</span><span class="kt">metadata</span> <span class="nv">!"Compiler V2"</span><span class="p">}</span>
+
+<span class="c">;;;;; Inputs/ident.b.ll:</span>
+
+<span class="nv">!llvm.ident</span> <span class="p">=</span> <span class="p">!{</span><span class="nv nv-Anonymous">!0</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!0</span> <span class="p">=</span> <span class="kt">metadata</span> <span class="p">!{</span><span class="kt">metadata</span> <span class="nv">!"Compiler V3"</span><span class="p">}</span>
+</pre></div>
+</div>
+<p>For symmetry reasons, <code class="docutils literal notranslate"><span class="pre">ident.ll</span></code> is just a dummy file that doesnât
+actually participate in the test besides holding the <code class="docutils literal notranslate"><span class="pre">RUN:</span></code> lines.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Some existing tests use <code class="docutils literal notranslate"><span class="pre">RUN:</span> <span class="pre">true</span></code> in extra files instead of just
+putting the extra files in an <code class="docutils literal notranslate"><span class="pre">Inputs/</span></code> directory. This pattern is
+deprecated.</p>
+</div>
+</div>
+<div class="section" id="fragile-tests">
+<h3><a class="toc-backref" href="#id15">Fragile tests</a><a class="headerlink" href="#fragile-tests" title="Permalink to this headline">¶</a></h3>
+<p>It is easy to write a fragile test that would fail spuriously if the tool being
+tested outputs a full path to the input file. For example, <strong class="program">opt</strong> by
+default outputs a <code class="docutils literal notranslate"><span class="pre">ModuleID</span></code>:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> cat example.ll
+<span class="go">define i32 @main() nounwind {</span>
+<span class="go"> ret i32 0</span>
+<span class="go">}</span>
+
+<span class="gp">$</span> opt -S /path/to/example.ll
+<span class="go">; ModuleID = '/path/to/example.ll'</span>
+
+<span class="go">define i32 @main() nounwind {</span>
+<span class="go"> ret i32 0</span>
+<span class="go">}</span>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">ModuleID</span></code> can unexpectedly match against <code class="docutils literal notranslate"><span class="pre">CHECK</span></code> lines. For example:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; RUN: opt -S %s | FileCheck</span>
+
+<span class="k">define</span> <span class="k">i32</span> <span class="vg">@main</span><span class="p">()</span> <span class="k">nounwind</span> <span class="p">{</span>
+ <span class="c">; CHECK-NOT: load</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="m">0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This test will fail if placed into a <code class="docutils literal notranslate"><span class="pre">download</span></code> directory.</p>
+<p>To make your tests robust, always use <code class="docutils literal notranslate"><span class="pre">opt</span> <span class="pre">...</span> <span class="pre"><</span> <span class="pre">%s</span></code> in the RUN line.
+<strong class="program">opt</strong> does not output a <code class="docutils literal notranslate"><span class="pre">ModuleID</span></code> when input comes from stdin.</p>
+</div>
+<div class="section" id="platform-specific-tests">
+<h3><a class="toc-backref" href="#id16">Platform-Specific Tests</a><a class="headerlink" href="#platform-specific-tests" title="Permalink to this headline">¶</a></h3>
+<p>Whenever adding tests that require the knowledge of a specific platform,
+either related to code generated, specific output or back-end features,
+you must make sure to isolate the features, so that buildbots that
+run on different architectures (and donât even compile all back-ends),
+donât fail.</p>
+<p>The first problem is to check for target-specific output, for example sizes
+of structures, paths and architecture names, for example:</p>
+<ul class="simple">
+<li>Tests containing Windows paths will fail on Linux and vice-versa.</li>
+<li>Tests that check for <code class="docutils literal notranslate"><span class="pre">x86_64</span></code> somewhere in the text will fail anywhere else.</li>
+<li>Tests where the debug information calculates the size of types and structures.</li>
+</ul>
+<p>Also, if the test rely on any behaviour that is coded in any back-end, it must
+go in its own directory. So, for instance, code generator tests for ARM go
+into <code class="docutils literal notranslate"><span class="pre">test/CodeGen/ARM</span></code> and so on. Those directories contain a special
+<code class="docutils literal notranslate"><span class="pre">lit</span></code> configuration file that ensure all tests in that directory will
+only run if a specific back-end is compiled and available.</p>
+<p>For instance, on <code class="docutils literal notranslate"><span class="pre">test/CodeGen/ARM</span></code>, the <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code> is:</p>
+<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">config</span><span class="o">.</span><span class="n">suffixes</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'.ll'</span><span class="p">,</span> <span class="s1">'.c'</span><span class="p">,</span> <span class="s1">'.cpp'</span><span class="p">,</span> <span class="s1">'.test'</span><span class="p">]</span>
+<span class="k">if</span> <span class="ow">not</span> <span class="s1">'ARM'</span> <span class="ow">in</span> <span class="n">config</span><span class="o">.</span><span class="n">root</span><span class="o">.</span><span class="n">targets</span><span class="p">:</span>
+ <span class="n">config</span><span class="o">.</span><span class="n">unsupported</span> <span class="o">=</span> <span class="bp">True</span>
+</pre></div>
+</div>
+<p>Other platform-specific tests are those that depend on a specific feature
+of a specific sub-architecture, for example only to Intel chips that support <code class="docutils literal notranslate"><span class="pre">AVX2</span></code>.</p>
+<p>For instance, <code class="docutils literal notranslate"><span class="pre">test/CodeGen/X86/psubus.ll</span></code> tests three sub-architecture
+variants:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; RUN: llc -mcpu=core2 < %s | FileCheck %s -check-prefix=SSE2</span>
+<span class="c">; RUN: llc -mcpu=corei7-avx < %s | FileCheck %s -check-prefix=AVX1</span>
+<span class="c">; RUN: llc -mcpu=core-avx2 < %s | FileCheck %s -check-prefix=AVX2</span>
+</pre></div>
+</div>
+<p>And the checks are different:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; SSE2: @test1</span>
+<span class="c">; SSE2: psubusw LCPI0_0(%rip), %xmm0</span>
+<span class="c">; AVX1: @test1</span>
+<span class="c">; AVX1: vpsubusw LCPI0_0(%rip), %xmm0, %xmm0</span>
+<span class="c">; AVX2: @test1</span>
+<span class="c">; AVX2: vpsubusw LCPI0_0(%rip), %xmm0, %xmm0</span>
+</pre></div>
+</div>
+<p>So, if youâre testing for a behaviour that you know is platform-specific or
+depends on special features of sub-architectures, you must add the specific
+triple, test with the specific FileCheck and put it into the specific
+directory that will filter out all other architectures.</p>
+</div>
+<div class="section" id="constraining-test-execution">
+<h3><a class="toc-backref" href="#id17">Constraining test execution</a><a class="headerlink" href="#constraining-test-execution" title="Permalink to this headline">¶</a></h3>
+<p>Some tests can be run only in specific configurations, such as
+with debug builds or on particular platforms. Use <code class="docutils literal notranslate"><span class="pre">REQUIRES</span></code>
+and <code class="docutils literal notranslate"><span class="pre">UNSUPPORTED</span></code> to control when the test is enabled.</p>
+<p>Some tests are expected to fail. For example, there may be a known bug
+that the test detect. Use <code class="docutils literal notranslate"><span class="pre">XFAIL</span></code> to mark a test as an expected failure.
+An <code class="docutils literal notranslate"><span class="pre">XFAIL</span></code> test will be successful if its execution fails, and
+will be a failure if its execution succeeds.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; This test will be only enabled in the build with asserts.</span>
+<span class="c">; REQUIRES: asserts</span>
+<span class="c">; This test is disabled on Linux.</span>
+<span class="c">; UNSUPPORTED: -linux-</span>
+<span class="c">; This test is expected to fail on PowerPC.</span>
+<span class="c">; XFAIL: powerpc</span>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">REQUIRES</span></code> and <code class="docutils literal notranslate"><span class="pre">UNSUPPORTED</span></code> and <code class="docutils literal notranslate"><span class="pre">XFAIL</span></code> all accept a comma-separated
+list of boolean expressions. The values in each expression may be:</p>
+<ul class="simple">
+<li>Features added to <code class="docutils literal notranslate"><span class="pre">config.available_features</span></code> by
+configuration files such as <code class="docutils literal notranslate"><span class="pre">lit.cfg</span></code>.</li>
+<li>Substrings of the target triple (<code class="docutils literal notranslate"><span class="pre">UNSUPPORTED</span></code> and <code class="docutils literal notranslate"><span class="pre">XFAIL</span></code> only).</li>
+</ul>
+<div class="line-block">
+<div class="line"><code class="docutils literal notranslate"><span class="pre">REQUIRES</span></code> enables the test if all expressions are true.</div>
+<div class="line"><code class="docutils literal notranslate"><span class="pre">UNSUPPORTED</span></code> disables the test if any expression is true.</div>
+<div class="line"><code class="docutils literal notranslate"><span class="pre">XFAIL</span></code> expects the test to fail if any expression is true.</div>
+</div>
+<p>As a special case, <code class="docutils literal notranslate"><span class="pre">XFAIL:</span> <span class="pre">*</span></code> is expected to fail everywhere.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="c">; This test is disabled on Windows,</span>
+<span class="c">; and is disabled on Linux, except for Android Linux.</span>
+<span class="c">; UNSUPPORTED: windows, linux && !android</span>
+<span class="c">; This test is expected to fail on both PowerPC and ARM.</span>
+<span class="c">; XFAIL: powerpc || arm</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="substitutions">
+<h3><a class="toc-backref" href="#id18">Substitutions</a><a class="headerlink" href="#substitutions" title="Permalink to this headline">¶</a></h3>
+<p>Besides replacing LLVM tool names the following substitutions are performed in
+RUN lines:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">%%</span></code></dt>
+<dd>Replaced by a single <code class="docutils literal notranslate"><span class="pre">%</span></code>. This allows escaping other substitutions.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%s</span></code></dt>
+<dd><p class="first">File path to the test caseâs source. This is suitable for passing on the
+command line as the input to an LLVM tool.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">/home/user/llvm/test/MC/ELF/foo_test.s</span></code></p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%S</span></code></dt>
+<dd><p class="first">Directory path to the test caseâs source.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">/home/user/llvm/test/MC/ELF</span></code></p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%t</span></code></dt>
+<dd><p class="first">File path to a temporary file name that could be used for this test case.
+The file name wonât conflict with other test cases. You can append to it
+if you need multiple temporaries. This is useful as the destination of
+some redirected output.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">/home/user/llvm.build/test/MC/ELF/Output/foo_test.s.tmp</span></code></p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%T</span></code></dt>
+<dd><p class="first">Directory of <code class="docutils literal notranslate"><span class="pre">%t</span></code>. Deprecated. Shouldnât be used, because it can be easily
+misused and cause race conditions between tests.</p>
+<p>Use <code class="docutils literal notranslate"><span class="pre">rm</span> <span class="pre">-rf</span> <span class="pre">%t</span> <span class="pre">&&</span> <span class="pre">mkdir</span> <span class="pre">%t</span></code> instead if a temporary directory is necessary.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">/home/user/llvm.build/test/MC/ELF/Output</span></code></p>
+</dd>
+</dl>
+<p><code class="docutils literal notranslate"><span class="pre">%{pathsep}</span></code></p>
+<blockquote>
+<div>Expands to the path separator, i.e. <code class="docutils literal notranslate"><span class="pre">:</span></code> (or <code class="docutils literal notranslate"><span class="pre">;</span></code> on Windows).</div></blockquote>
+<p><code class="docutils literal notranslate"><span class="pre">%/s,</span> <span class="pre">%/S,</span> <span class="pre">%/t,</span> <span class="pre">%/T:</span></code></p>
+<blockquote>
+<div><p>Act like the corresponding substitution above but replace any <code class="docutils literal notranslate"><span class="pre">\</span></code>
+character with a <code class="docutils literal notranslate"><span class="pre">/</span></code>. This is useful to normalize path separators.</p>
+<blockquote>
+<div><p>Example: <code class="docutils literal notranslate"><span class="pre">%s:</span> <span class="pre">C:\Desktop</span> <span class="pre">Files/foo_test.s.tmp</span></code></p>
+<p>Example: <code class="docutils literal notranslate"><span class="pre">%/s:</span> <span class="pre">C:/Desktop</span> <span class="pre">Files/foo_test.s.tmp</span></code></p>
+</div></blockquote>
+</div></blockquote>
+<p><code class="docutils literal notranslate"><span class="pre">%:s,</span> <span class="pre">%:S,</span> <span class="pre">%:t,</span> <span class="pre">%:T:</span></code></p>
+<blockquote>
+<div><p>Act like the corresponding substitution above but remove colons at
+the beginning of Windows paths. This is useful to allow concatenation
+of absolute paths on Windows to produce a legal path.</p>
+<blockquote>
+<div><p>Example: <code class="docutils literal notranslate"><span class="pre">%s:</span> <span class="pre">C:\Desktop</span> <span class="pre">Files\foo_test.s.tmp</span></code></p>
+<p>Example: <code class="docutils literal notranslate"><span class="pre">%:s:</span> <span class="pre">C\Desktop</span> <span class="pre">Files\foo_test.s.tmp</span></code></p>
+</div></blockquote>
+</div></blockquote>
+<p><strong>LLVM-specific substitutions:</strong></p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">%shlibext</span></code></dt>
+<dd><p class="first">The suffix for the host platforms shared library files. This includes the
+period as the first character.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">.so</span></code> (Linux), <code class="docutils literal notranslate"><span class="pre">.dylib</span></code> (macOS), <code class="docutils literal notranslate"><span class="pre">.dll</span></code> (Windows)</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%exeext</span></code></dt>
+<dd><p class="first">The suffix for the host platforms executable files. This includes the
+period as the first character.</p>
+<p class="last">Example: <code class="docutils literal notranslate"><span class="pre">.exe</span></code> (Windows), empty on Linux.</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%(line)</span></code>, <code class="docutils literal notranslate"><span class="pre">%(line+<number>)</span></code>, <code class="docutils literal notranslate"><span class="pre">%(line-<number>)</span></code></dt>
+<dd>The number of the line where this substitution is used, with an optional
+integer offset. This can be used in tests with multiple RUN lines, which
+reference test fileâs line numbers.</dd>
+</dl>
+<p><strong>Clang-specific substitutions:</strong></p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">%clang</span></code></dt>
+<dd>Invokes the Clang driver.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%clang_cpp</span></code></dt>
+<dd>Invokes the Clang driver for C++.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%clang_cl</span></code></dt>
+<dd>Invokes the CL-compatible Clang driver.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%clangxx</span></code></dt>
+<dd>Invokes the G++-compatible Clang driver.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%clang_cc1</span></code></dt>
+<dd>Invokes the Clang frontend.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">%itanium_abi_triple</span></code>, <code class="docutils literal notranslate"><span class="pre">%ms_abi_triple</span></code></dt>
+<dd>These substitutions can be used to get the current target triple adjusted to
+the desired ABI. For example, if the test suite is running with the
+<code class="docutils literal notranslate"><span class="pre">i686-pc-win32</span></code> target, <code class="docutils literal notranslate"><span class="pre">%itanium_abi_triple</span></code> will expand to
+<code class="docutils literal notranslate"><span class="pre">i686-pc-mingw32</span></code>. This allows a test to run with a specific ABI without
+constraining it to a specific triple.</dd>
+</dl>
+<p>To add more substituations, look at <code class="docutils literal notranslate"><span class="pre">test/lit.cfg</span></code> or <code class="docutils literal notranslate"><span class="pre">lit.local.cfg</span></code>.</p>
+</div>
+<div class="section" id="options">
+<h3><a class="toc-backref" href="#id19">Options</a><a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h3>
+<p>The llvm lit configuration allows to customize some things with user options:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">llc</span></code>, <code class="docutils literal notranslate"><span class="pre">opt</span></code>, â¦</dt>
+<dd><p class="first">Substitute the respective llvm tool name with a custom command line. This
+allows to specify custom paths and default arguments for these tools.
+Example:</p>
+<p class="last">% llvm-lit â-Dllc=llc -verify-machineinstrsâ</p>
+</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">run_long_tests</span></code></dt>
+<dd>Enable the execution of long running tests.</dd>
+<dt><code class="docutils literal notranslate"><span class="pre">llvm_site_config</span></code></dt>
+<dd>Load the specified lit configuration instead of the default one.</dd>
+</dl>
+</div>
+<div class="section" id="other-features">
+<h3><a class="toc-backref" href="#id20">Other Features</a><a class="headerlink" href="#other-features" title="Permalink to this headline">¶</a></h3>
+<p>To make RUN line writing easier, there are several helper programs. These
+helpers are in the PATH when running tests, so you can just call them using
+their name. For example:</p>
+<dl class="docutils">
+<dt><code class="docutils literal notranslate"><span class="pre">not</span></code></dt>
+<dd>This program runs its arguments and then inverts the result code from it.
+Zero result codes become 1. Non-zero result codes become 0.</dd>
+</dl>
+<p>To make the output more useful, <strong class="program">lit</strong> will scan
+the lines of the test case for ones that contain a pattern that matches
+<code class="docutils literal notranslate"><span class="pre">PR[0-9]+</span></code>. This is the syntax for specifying a PR (Problem Report) number
+that is related to the test case. The number after âPRâ specifies the
+LLVM bugzilla number. When a PR number is specified, it will be used in
+the pass/fail reporting. This is useful to quickly get some context when
+a test fails.</p>
+<p>Finally, any line that contains âEND.â will cause the special
+interpretation of lines to terminate. This is generally done right after
+the last RUN: line. This has two side effects:</p>
+<ol class="loweralpha simple">
+<li>it prevents special interpretation of lines that are part of the test
+program, not the instructions to the test case, and</li>
+<li>it speeds things up for really big test cases by avoiding
+interpretation of the remainder of the file.</li>
+</ol>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="TestSuiteGuide.html" title="test-suite Guide"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TransformMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TransformMetadata.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TransformMetadata.html (added)
+++ www-releases/trunk/9.0.0/docs/TransformMetadata.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,479 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Code Transformation Metadata — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="FaultMaps and implicit checks" href="FaultMaps.html" />
+ <link rel="prev" title="Type Metadata" href="TypeMetadata.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" role="navigation" aria-label="related navigation">
+ <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="FaultMaps.html" title="FaultMaps and implicit checks"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="TypeMetadata.html" title="Type 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" role="main">
+
+ <div class="section" id="code-transformation-metadata">
+<span id="transformation-metadata"></span><h1>Code Transformation Metadata<a class="headerlink" href="#code-transformation-metadata" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#overview" id="id1">Overview</a></li>
+<li><a class="reference internal" href="#metadata-on-loops" id="id2">Metadata on Loops</a></li>
+<li><a class="reference internal" href="#transformation-metadata-structure" id="id3">Transformation Metadata Structure</a></li>
+<li><a class="reference internal" href="#pass-specific-transformation-metadata" id="id4">Pass-Specific Transformation Metadata</a><ul>
+<li><a class="reference internal" href="#loop-vectorization-and-interleaving" id="id5">Loop Vectorization and Interleaving</a></li>
+<li><a class="reference internal" href="#loop-unrolling" id="id6">Loop Unrolling</a></li>
+<li><a class="reference internal" href="#unroll-and-jam" id="id7">Unroll-And-Jam</a></li>
+<li><a class="reference internal" href="#loop-distribution" id="id8">Loop Distribution</a></li>
+<li><a class="reference internal" href="#versioning-licm" id="id9">Versioning LICM</a></li>
+<li><a class="reference internal" href="#loop-interchange" id="id10">Loop Interchange</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#ambiguous-transformation-order" id="id11">Ambiguous Transformation Order</a></li>
+<li><a class="reference internal" href="#leftover-transformations" id="id12">Leftover Transformations</a></li>
+</ul>
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id1">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
+<p>LLVM transformation passes can be controlled by attaching metadata to
+the code to transform. By default, transformation passes use heuristics
+to determine whether or not to perform transformations, and when doing
+so, other details of how the transformations are applied (e.g., which
+vectorization factor to select).
+Unless the optimizer is otherwise directed, transformations are applied
+conservatively. This conservatism generally allows the optimizer to
+avoid unprofitable transformations, but in practice, this results in the
+optimizer not applying transformations that would be highly profitable.</p>
+<p>Frontends can give additional hints to LLVM passes on which
+transformations they should apply. This can be additional knowledge that
+cannot be derived from the emitted IR, or directives passed from the
+user/programmer. OpenMP pragmas are an example of the latter.</p>
+<p>If any such metadata is dropped from the program, the codeâs semantics
+must not change.</p>
+</div>
+<div class="section" id="metadata-on-loops">
+<h2><a class="toc-backref" href="#id2">Metadata on Loops</a><a class="headerlink" href="#metadata-on-loops" title="Permalink to this headline">¶</a></h2>
+<p>Attributes can be attached to loops as described in <a class="reference internal" href="LangRef.html#llvm-loop"><span class="std std-ref">âllvm.loopâ</span></a>.
+Attributes can describe properties of the loop, disable transformations,
+force specific transformations and set transformation options.</p>
+<p>Because metadata nodes are immutable (with the exception of
+<code class="docutils literal notranslate"><span class="pre">MDNode::replaceOperandWith</span></code> which is dangerous to use on uniqued
+metadata), in order to add or remove a loop attributes, a new <code class="docutils literal notranslate"><span class="pre">MDNode</span></code>
+must be created and assigned as the new <code class="docutils literal notranslate"><span class="pre">llvm.loop</span></code> metadata. Any
+connection between the old <code class="docutils literal notranslate"><span class="pre">MDNode</span></code> and the loop is lost. The
+<code class="docutils literal notranslate"><span class="pre">llvm.loop</span></code> node is also used as LoopID (<code class="docutils literal notranslate"><span class="pre">Loop::getLoopID()</span></code>), i.e.
+the loop effectively gets a new identifier. For instance,
+<code class="docutils literal notranslate"><span class="pre">llvm.mem.parallel_loop_access</span></code> references the LoopID. Therefore, if
+the parallel access property is to be preserved after adding/removing
+loop attributes, any <code class="docutils literal notranslate"><span class="pre">llvm.mem.parallel_loop_access</span></code> reference must be
+updated to the new LoopID.</p>
+</div>
+<div class="section" id="transformation-metadata-structure">
+<h2><a class="toc-backref" href="#id3">Transformation Metadata Structure</a><a class="headerlink" href="#transformation-metadata-structure" title="Permalink to this headline">¶</a></h2>
+<p>Some attributes describe code transformations (unrolling, vectorizing,
+loop distribution, etc.). They can either be a hint to the optimizer
+that a transformation might be beneficial, instruction to use a specific
+option, , or convey a specific request from the user (such as
+<code class="docutils literal notranslate"><span class="pre">#pragma</span> <span class="pre">clang</span> <span class="pre">loop</span></code> or <code class="docutils literal notranslate"><span class="pre">#pragma</span> <span class="pre">omp</span> <span class="pre">simd</span></code>).</p>
+<p>If a transformation is forced but cannot be carried-out for any reason,
+an optimization-missed warning must be emitted. Semantic information
+such as a transformation being safe (e.g.
+<code class="docutils literal notranslate"><span class="pre">llvm.mem.parallel_loop_access</span></code>) can be unused by the optimizer
+without generating a warning.</p>
+<p>Unless explicitly disabled, any optimization pass may heuristically
+determine whether a transformation is beneficial and apply it. If
+metadata for another transformation was specified, applying a different
+transformation before it might be inadvertent due to being applied on a
+different loop or the loop not existing anymore. To avoid having to
+explicitly disable an unknown number of passes, the attribute
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.disable_nonforced</span></code> disables all optional, high-level,
+restructuring transformations.</p>
+<p>The following example avoids the loop being altered before being
+vectorized, for instance being unrolled.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span> <span class="k">br</span> <span class="k">i1</span> <span class="nv">%exitcond</span><span class="p">,</span> <span class="kt">label</span> <span class="nv">%for.exit</span><span class="p">,</span> <span class="kt">label</span> <span class="nv">%for.header</span><span class="p">,</span> <span class="nv">!llvm.loop</span> <span class="nv nv-Anonymous">!0</span>
+<span class="p">...</span>
+<span class="nv nv-Anonymous">!0</span> <span class="p">=</span> <span class="k">distinct</span> <span class="p">!{</span><span class="nv nv-Anonymous">!0</span><span class="p">,</span> <span class="nv nv-Anonymous">!1</span><span class="p">,</span> <span class="nv nv-Anonymous">!2</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!1</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.vectorize.enable"</span><span class="p">,</span> <span class="k">i1</span> <span class="k">true</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!2</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.disable_nonforced"</span><span class="p">}</span>
+</pre></div>
+</div>
+<p>After a transformation is applied, follow-up attributes are set on the
+transformed and/or new loop(s). This allows additional attributes
+including followup-transformations to be specified. Specifying multiple
+transformations in the same metadata node is possible for compatibility
+reasons, but their execution order is undefined. For instance, when
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.vectorize.enable</span></code> and <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.enable</span></code> are
+specified at the same time, unrolling may occur either before or after
+vectorization.</p>
+<p>As an example, the following instructs a loop to be vectorized and only
+then unrolled.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="nv nv-Anonymous">!0</span> <span class="p">=</span> <span class="k">distinct</span> <span class="p">!{</span><span class="nv nv-Anonymous">!0</span><span class="p">,</span> <span class="nv nv-Anonymous">!1</span><span class="p">,</span> <span class="nv nv-Anonymous">!2</span><span class="p">,</span> <span class="nv nv-Anonymous">!3</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!1</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.vectorize.enable"</span><span class="p">,</span> <span class="k">i1</span> <span class="k">true</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!2</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.disable_nonforced"</span><span class="p">}</span>
+<span class="nv nv-Anonymous">!3</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.vectorize.followup_vectorized"</span><span class="p">,</span> <span class="p">!{</span><span class="s">"llvm.loop.unroll.enable"</span><span class="p">}}</span>
+</pre></div>
+</div>
+<p>If, and only if, no followup is specified, the pass may add attributes itself.
+For instance, the vectorizer adds a <code class="docutils literal notranslate"><span class="pre">llvm.loop.isvectorized</span></code> attribute and
+all attributes from the original loop excluding its loop vectorizer
+attributes. To avoid this, an empty followup attribute can be used, e.g.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="nv nv-Anonymous">!3</span> <span class="p">=</span> <span class="p">!{</span><span class="nv">!"llvm.loop.vectorize.followup_vectorized"</span><span class="p">}</span>
+</pre></div>
+</div>
+<p>The followup attributes of a transformation that cannot be applied will
+never be added to a loop and are therefore effectively ignored. This means
+that any followup-transformation in such attributes requires that its
+prior transformations are applied before the followup-transformation.
+The user should receive a warning about the first transformation in the
+transformation chain that could not be applied if it a forced
+transformation. All following transformations are skipped.</p>
+</div>
+<div class="section" id="pass-specific-transformation-metadata">
+<h2><a class="toc-backref" href="#id4">Pass-Specific Transformation Metadata</a><a class="headerlink" href="#pass-specific-transformation-metadata" title="Permalink to this headline">¶</a></h2>
+<p>Transformation options are specific to each transformation. In the
+following, we present the model for each LLVM loop optimization pass and
+the metadata to influence them.</p>
+<div class="section" id="loop-vectorization-and-interleaving">
+<h3><a class="toc-backref" href="#id5">Loop Vectorization and Interleaving</a><a class="headerlink" href="#loop-vectorization-and-interleaving" title="Permalink to this headline">¶</a></h3>
+<p>Loop vectorization and interleaving is interpreted as a single
+transformation. It is interpreted as forced if
+<code class="docutils literal notranslate"><span class="pre">!{"llvm.loop.vectorize.enable",</span> <span class="pre">i1</span> <span class="pre">true}</span></code> is set.</p>
+<p>Assuming the pre-vectorization loop is</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// original loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>then the code after vectorization will be approximately (assuming an
+SIMD width of 4):</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">rtc</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">3</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">4</span><span class="p">)</span> <span class="c1">// vectorized/interleaved loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="nl">i</span><span class="p">:</span><span class="n">i</span><span class="o">+</span><span class="mi">3</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// epilogue loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>where <code class="docutils literal notranslate"><span class="pre">rtc</span></code> is a generated runtime check.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.vectorize.followup_vectorized</span></code> will set the attributes for
+the vectorized loop. If not specified, <code class="docutils literal notranslate"><span class="pre">llvm.loop.isvectorized</span></code> is
+combined with the original loopâs attributes to avoid it being
+vectorized multiple times.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.vectorize.followup_epilogue</span></code> will set the attributes for
+the remainder loop. If not specified, it will have the original loopâs
+attributes combined with <code class="docutils literal notranslate"><span class="pre">llvm.loop.isvectorized</span></code> and
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.runtime.disable</span></code> (unless the original loop already
+has unroll metadata).</p>
+<p>The attributes specified by <code class="docutils literal notranslate"><span class="pre">llvm.loop.vectorize.followup_all</span></code> are
+added to both loops.</p>
+<p>When using a follow-up attribute, it replaces any automatically deduced
+attributes for the generated loop in question. Therefore it is
+recommended to add <code class="docutils literal notranslate"><span class="pre">llvm.loop.isvectorized</span></code> to
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.vectorize.followup_all</span></code> which avoids that the loop
+vectorizer tries to optimize the loops again.</p>
+</div>
+<div class="section" id="loop-unrolling">
+<h3><a class="toc-backref" href="#id6">Loop Unrolling</a><a class="headerlink" href="#loop-unrolling" title="Permalink to this headline">¶</a></h3>
+<p>Unrolling is interpreted as forced any <code class="docutils literal notranslate"><span class="pre">!{!"llvm.loop.unroll.enable"}</span></code>
+metadata or option (<code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.count</span></code>, <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.full</span></code>)
+is present. Unrolling can be full unrolling, partial unrolling of a loop
+with constant trip count or runtime unrolling of a loop with a trip
+count unknown at compile-time.</p>
+<p>If the loop has been unrolled fully, there is no followup-loop. For
+partial/runtime unrolling, the original loop of</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// original loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>is transformed into (using an unroll factor of 4):</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</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">3</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">4</span><span class="p">)</span> <span class="c1">// unrolled loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">1</span><span class="p">);</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">2</span><span class="p">);</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">3</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// remainder loop</span>
+ <span class="n">Stmt</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.followup_unrolled</span></code> will set the loop attributes of
+the unrolled loop. If not specified, the attributes of the original loop
+without the <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.*</span></code> attributes are copied and
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.disable</span></code> added to it.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.followup_remainder</span></code> defines the attributes of the
+remainder loop. If not specified the remainder loop will have no
+attributes. The remainder loop might not be present due to being fully
+unrolled in which case this attribute has no effect.</p>
+<p>Attributes defined in <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.followup_all</span></code> are added to the
+unrolled and remainder loops.</p>
+<p>To avoid that the partially unrolled loop is unrolled again, it is
+recommended to add <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.disable</span></code> to
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.followup_all</span></code>. If no follow-up attribute specified
+for a generated loop, it is added automatically.</p>
+</div>
+<div class="section" id="unroll-and-jam">
+<h3><a class="toc-backref" href="#id7">Unroll-And-Jam</a><a class="headerlink" href="#unroll-and-jam" title="Permalink to this headline">¶</a></h3>
+<p>Unroll-and-jam uses the following transformation model (here with an
+unroll factor if 2). Currently, it does not support a fallback version
+when the transformation is unsafe.</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// original outer loop</span>
+ <span class="n">Fore</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">j</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">j</span> <span class="o"><</span> <span class="n">m</span><span class="p">;</span> <span class="n">j</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// original inner loop</span>
+ <span class="n">SubLoop</span><span class="p">(</span><span class="n">i</span><span class="p">,</span> <span class="n">j</span><span class="p">);</span>
+ <span class="n">Aft</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">0</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">1</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">2</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// unrolled outer loop</span>
+ <span class="n">Fore</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="n">Fore</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">1</span><span class="p">);</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">j</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">j</span> <span class="o"><</span> <span class="n">m</span><span class="p">;</span> <span class="n">j</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// unrolled inner loop</span>
+ <span class="n">SubLoop</span><span class="p">(</span><span class="n">i</span><span class="p">,</span> <span class="n">j</span><span class="p">);</span>
+ <span class="n">SubLoop</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">1</span><span class="p">,</span> <span class="n">j</span><span class="p">);</span>
+ <span class="p">}</span>
+ <span class="n">Aft</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="n">Aft</span><span class="p">(</span><span class="n">i</span><span class="o">+</span><span class="mi">1</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// remainder outer loop</span>
+ <span class="n">Fore</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">j</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">j</span> <span class="o"><</span> <span class="n">m</span><span class="p">;</span> <span class="n">j</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// remainder inner loop</span>
+ <span class="n">SubLoop</span><span class="p">(</span><span class="n">i</span><span class="p">,</span> <span class="n">j</span><span class="p">);</span>
+ <span class="n">Aft</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_outer</span></code> will set the loop attributes
+of the unrolled outer loop. If not specified, the attributes of the
+original outer loop without the <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.*</span></code> attributes are
+copied and <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.disable</span></code> added to it.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_inner</span></code> will set the loop attributes
+of the unrolled inner loop. If not specified, the attributes of the
+original inner loop are used unchanged.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_remainder_outer</span></code> sets the loop
+attributes of the outer remainder loop. If not specified it will not
+have any attributes. The remainder loop might not be present due to
+being fully unrolled.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_remainder_inner</span></code> sets the loop
+attributes of the inner remainder loop. If not specified it will have
+the attributes of the original inner loop. It the outer remainder loop
+is unrolled, the inner remainder loop might be present multiple times.</p>
+<p>Attributes defined in <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_all</span></code> are
+added to all of the aforementioned output loops.</p>
+<p>To avoid that the unrolled loop is unrolled again, it is
+recommended to add <code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll.disable</span></code> to
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.unroll_and_jam.followup_all</span></code>. It suppresses unroll-and-jam
+as well as an additional inner loop unrolling. If no follow-up
+attribute specified for a generated loop, it is added automatically.</p>
+</div>
+<div class="section" id="loop-distribution">
+<h3><a class="toc-backref" href="#id8">Loop Distribution</a><a class="headerlink" href="#loop-distribution" title="Permalink to this headline">¶</a></h3>
+<p>The LoopDistribution pass tries to separate vectorizable parts of a loop
+from the non-vectorizable part (which otherwise would make the entire
+loop non-vectorizable). Conceptually, it transforms a loop such as</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// original loop</span>
+ <span class="n">A</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="p">;</span>
+ <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">2</span> <span class="o">+</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>
+ <span class="n">C</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">3</span> <span class="o">+</span> <span class="n">C</span><span class="p">[</span><span class="n">i</span> <span class="o">-</span> <span class="mi">1</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>into the following code:</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">rtc</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// coincident loop</span>
+ <span class="n">A</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="p">;</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// coincident loop</span>
+ <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">2</span> <span class="o">+</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// sequential loop</span>
+ <span class="n">C</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">3</span> <span class="o">+</span> <span class="n">C</span><span class="p">[</span><span class="n">i</span> <span class="o">-</span> <span class="mi">1</span><span class="p">];</span>
+<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// fallback loop</span>
+ <span class="n">A</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="p">;</span>
+ <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">2</span> <span class="o">+</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>
+ <span class="n">C</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="mi">3</span> <span class="o">+</span> <span class="n">C</span><span class="p">[</span><span class="n">i</span> <span class="o">-</span> <span class="mi">1</span><span class="p">];</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>where <code class="docutils literal notranslate"><span class="pre">rtc</span></code> is a generated runtime check.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.distribute.followup_coincident</span></code> sets the loop attributes of
+all loops without loop-carried dependencies (i.e. vectorizable loops).
+There might be more than one such loops. If not defined, the loops will
+inherit the original loopâs attributes.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.distribute.followup_sequential</span></code> sets the loop attributes of the
+loop with potentially unsafe dependencies. There should be at most one
+such loop. If not defined, the loop will inherit the original loopâs
+attributes.</p>
+<p><code class="docutils literal notranslate"><span class="pre">llvm.loop.distribute.followup_fallback</span></code> defines the loop attributes
+for the fallback loop, which is a copy of the original loop for when
+loop versioning is required. If undefined, the fallback loop inherits
+all attributes from the original loop.</p>
+<p>Attributes defined in <code class="docutils literal notranslate"><span class="pre">llvm.loop.distribute.followup_all</span></code> are added to
+all of the aforementioned output loops.</p>
+<p>It is recommended to add <code class="docutils literal notranslate"><span class="pre">llvm.loop.disable_nonforced</span></code> to
+<code class="docutils literal notranslate"><span class="pre">llvm.loop.distribute.followup_fallback</span></code>. This avoids that the
+fallback version (which is likely never executed) is further optimzed
+which would increase the code size.</p>
+</div>
+<div class="section" id="versioning-licm">
+<h3><a class="toc-backref" href="#id9">Versioning LICM</a><a class="headerlink" href="#versioning-licm" title="Permalink to this headline">¶</a></h3>
+<p>The pass hoists code out of loops that are only loop-invariant when
+dynamic conditions apply. For instance, it transforms the loop</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// original loop</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="n">B</span><span class="p">[</span><span class="mi">0</span><span class="p">];</span>
+</pre></div>
+</div>
+<p>into:</p>
+<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">rtc</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">auto</span> <span class="n">b</span> <span class="o">=</span> <span class="n">B</span><span class="p">[</span><span class="mi">0</span><span class="p">];</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// versioned loop</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="n">b</span><span class="p">;</span>
+<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">+=</span><span class="mi">1</span><span class="p">)</span> <span class="c1">// unversioned loop</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="n">B</span><span class="p">[</span><span class="mi">0</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The runtime condition (<code class="docutils literal notranslate"><span class="pre">rtc</span></code>) checks that the array <code class="docutils literal notranslate"><span class="pre">A</span></code> and the
+element <cite>B[0]</cite> do not alias.</p>
+<p>Currently, this transformation does not support followup-attributes.</p>
+</div>
+<div class="section" id="loop-interchange">
+<h3><a class="toc-backref" href="#id10">Loop Interchange</a><a class="headerlink" href="#loop-interchange" title="Permalink to this headline">¶</a></h3>
+<p>Currently, the <code class="docutils literal notranslate"><span class="pre">LoopInterchange</span></code> pass does not use any metadata.</p>
+</div>
+</div>
+<div class="section" id="ambiguous-transformation-order">
+<h2><a class="toc-backref" href="#id11">Ambiguous Transformation Order</a><a class="headerlink" href="#ambiguous-transformation-order" title="Permalink to this headline">¶</a></h2>
+<p>If there multiple transformations defined, the order in which they are
+executed depends on the order in LLVMâs pass pipeline, which is subject
+to change. The default optimization pipeline (anything higher than
+<code class="docutils literal notranslate"><span class="pre">-O0</span></code>) has the following order.</p>
+<p>When using the legacy pass manager:</p>
+<blockquote>
+<div><ul class="simple">
+<li>LoopInterchange (if enabled)</li>
+<li>SimpleLoopUnroll/LoopFullUnroll (only performs full unrolling)</li>
+<li>VersioningLICM (if enabled)</li>
+<li>LoopDistribute</li>
+<li>LoopVectorizer</li>
+<li>LoopUnrollAndJam (if enabled)</li>
+<li>LoopUnroll (partial and runtime unrolling)</li>
+</ul>
+</div></blockquote>
+<p>When using the legacy pass manager with LTO:</p>
+<blockquote>
+<div><ul class="simple">
+<li>LoopInterchange (if enabled)</li>
+<li>SimpleLoopUnroll/LoopFullUnroll (only performs full unrolling)</li>
+<li>LoopVectorizer</li>
+<li>LoopUnroll (partial and runtime unrolling)</li>
+</ul>
+</div></blockquote>
+<p>When using the new pass manager:</p>
+<blockquote>
+<div><ul class="simple">
+<li>SimpleLoopUnroll/LoopFullUnroll (only performs full unrolling)</li>
+<li>LoopDistribute</li>
+<li>LoopVectorizer</li>
+<li>LoopUnrollAndJam (if enabled)</li>
+<li>LoopUnroll (partial and runtime unrolling)</li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="leftover-transformations">
+<h2><a class="toc-backref" href="#id12">Leftover Transformations</a><a class="headerlink" href="#leftover-transformations" title="Permalink to this headline">¶</a></h2>
+<p>Forced transformations that have not been applied after the last
+transformation pass should be reported to the user. The transformation
+passes themselves cannot be responsible for this reporting because they
+might not be in the pipeline, there might be multiple passes able to
+apply a transformation (e.g. <code class="docutils literal notranslate"><span class="pre">LoopInterchange</span></code> and Polly) or a
+transformation attribute may be âhiddenâ inside another passesâ followup
+attribute.</p>
+<p>The pass <code class="docutils literal notranslate"><span class="pre">-transform-warning</span></code> (<code class="docutils literal notranslate"><span class="pre">WarnMissedTransformationsPass</span></code>)
+emits such warnings. It should be placed after the last transformation
+pass.</p>
+<p>The current pass pipeline has a fixed order in which transformations
+passes are executed. A transformation can be in the followup of a pass
+that is executed later and thus leftover. For instance, a loop nest
+cannot be distributed and then interchanged with the current pass
+pipeline. The loop distribution will execute, but there is no loop
+interchange pass following such that any loop interchange metadata will
+be ignored. The <code class="docutils literal notranslate"><span class="pre">-transform-warning</span></code> should emit a warning in this
+case.</p>
+<p>Future versions of LLVM may fix this by executing transformations using
+a dynamic ordering.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="FaultMaps.html" title="FaultMaps and implicit checks"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="TypeMetadata.html" title="Type 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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/TypeMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/TypeMetadata.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/TypeMetadata.html (added)
+++ www-releases/trunk/9.0.0/docs/TypeMetadata.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,378 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Type Metadata — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Code Transformation Metadata" href="TransformMetadata.html" />
+ <link rel="prev" title="MergeFunctions pass, how it works" href="MergeFunctions.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" role="navigation" aria-label="related navigation">
+ <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="TransformMetadata.html" title="Code Transformation Metadata"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="MergeFunctions.html" title="MergeFunctions pass, how it works"
+ 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" role="main">
+
+ <div class="section" id="type-metadata">
+<h1>Type Metadata<a class="headerlink" href="#type-metadata" title="Permalink to this headline">¶</a></h1>
+<p>Type metadata is a mechanism that allows IR modules to co-operatively build
+pointer sets corresponding to addresses within a given set of globals. LLVMâs
+<a class="reference external" href="http://clang.llvm.org/docs/ControlFlowIntegrity.html">control flow integrity</a> implementation uses this metadata to efficiently
+check (at each call site) that a given address corresponds to either a
+valid vtable or function pointer for a given class or function type, and its
+whole-program devirtualization pass uses the metadata to identify potential
+callees for a given virtual call.</p>
+<p>To use the mechanism, a client creates metadata nodes with two elements:</p>
+<ol class="arabic simple">
+<li>a byte offset into the global (generally zero for functions)</li>
+<li>a metadata object representing an identifier for the type</li>
+</ol>
+<p>These metadata nodes are associated with globals by using global object
+metadata attachments with the <code class="docutils literal notranslate"><span class="pre">!type</span></code> metadata kind.</p>
+<p>Each type identifier must exclusively identify either global variables
+or functions.</p>
+<div class="admonition-limitation admonition">
+<p class="first admonition-title">Limitation</p>
+<p class="last">The current implementation only supports attaching metadata to functions on
+the x86-32 and x86-64 architectures.</p>
+</div>
+<p>An intrinsic, <a class="reference internal" href="LangRef.html#type-test"><span class="std std-ref">llvm.type.test</span></a>, is used to test whether a
+given pointer is associated with a type identifier.</p>
+<div class="section" id="representing-type-information-using-type-metadata">
+<h2>Representing Type Information using Type Metadata<a class="headerlink" href="#representing-type-information-using-type-metadata" title="Permalink to this headline">¶</a></h2>
+<p>This section describes how Clang represents C++ type information associated with
+virtual tables using type metadata.</p>
+<p>Consider the following inheritance hierarchy:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">B</span> <span class="p">:</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">g</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="n">C</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">h</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">D</span> <span class="p">:</span> <span class="n">A</span><span class="p">,</span> <span class="n">C</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">h</span><span class="p">();</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The virtual table objects for A, B, C and D look like this (under the Itanium ABI):</p>
+<table border="1" class="docutils" id="id1">
+<caption><span class="caption-text">Virtual Table Layout for A, B, C, D</span><a class="headerlink" href="#id1" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+<col width="13%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Class</th>
+<th class="head">0</th>
+<th class="head">1</th>
+<th class="head">2</th>
+<th class="head">3</th>
+<th class="head">4</th>
+<th class="head">5</th>
+<th class="head">6</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A</td>
+<td>A::offset-to-top</td>
+<td>&A::rtti</td>
+<td>&A::f</td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+</tr>
+<tr class="row-odd"><td>B</td>
+<td>B::offset-to-top</td>
+<td>&B::rtti</td>
+<td>&B::f</td>
+<td>&B::g</td>
+<td> </td>
+<td> </td>
+<td> </td>
+</tr>
+<tr class="row-even"><td>C</td>
+<td>C::offset-to-top</td>
+<td>&C::rtti</td>
+<td>&C::h</td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+</tr>
+<tr class="row-odd"><td>D</td>
+<td>D::offset-to-top</td>
+<td>&D::rtti</td>
+<td>&D::f</td>
+<td>&D::h</td>
+<td>D::offset-to-top</td>
+<td>&D::rtti</td>
+<td>thunk for &D::h</td>
+</tr>
+</tbody>
+</table>
+<p>When an object of type A is constructed, the address of <code class="docutils literal notranslate"><span class="pre">&A::f</span></code> in Aâs
+virtual table object is stored in the objectâs vtable pointer. In ABI parlance
+this address is known as an <a class="reference external" href="https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-general">address point</a>. Similarly, when an object of type
+B is constructed, the address of <code class="docutils literal notranslate"><span class="pre">&B::f</span></code> is stored in the vtable pointer. In
+this way, the vtable in Bâs virtual table object is compatible with Aâs vtable.</p>
+<p>D is a little more complicated, due to the use of multiple inheritance. Its
+virtual table object contains two vtables, one compatible with Aâs vtable and
+the other compatible with Câs vtable. Objects of type D contain two virtual
+pointers, one belonging to the A subobject and containing the address of
+the vtable compatible with Aâs vtable, and the other belonging to the C
+subobject and containing the address of the vtable compatible with Câs vtable.</p>
+<p>The full set of compatibility information for the above class hierarchy is
+shown below. The following table shows the name of a class, the offset of an
+address point within that classâs vtable and the name of one of the classes
+with which that address point is compatible.</p>
+<table border="1" class="docutils" id="id2">
+<caption><span class="caption-text">Type Offsets for A, B, C, D</span><a class="headerlink" href="#id2" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">VTable for</th>
+<th class="head">Offset</th>
+<th class="head">Compatible Class</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A</td>
+<td>16</td>
+<td>A</td>
+</tr>
+<tr class="row-odd"><td>B</td>
+<td>16</td>
+<td>A</td>
+</tr>
+<tr class="row-even"><td> </td>
+<td> </td>
+<td>B</td>
+</tr>
+<tr class="row-odd"><td>C</td>
+<td>16</td>
+<td>C</td>
+</tr>
+<tr class="row-even"><td>D</td>
+<td>16</td>
+<td>A</td>
+</tr>
+<tr class="row-odd"><td> </td>
+<td> </td>
+<td>D</td>
+</tr>
+<tr class="row-even"><td> </td>
+<td>48</td>
+<td>C</td>
+</tr>
+</tbody>
+</table>
+<p>The next step is to encode this compatibility information into the IR. The way
+this is done is to create type metadata named after each of the compatible
+classes, with which we associate each of the compatible address points in
+each vtable. For example, these type metadata entries encode the compatibility
+information for the above hierarchy:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>@_ZTV1A = constant [...], !type !0
+ at _ZTV1B = constant [...], !type !0, !type !1
+ at _ZTV1C = constant [...], !type !2
+ at _ZTV1D = constant [...], !type !0, !type !3, !type !4
+
+!0 = !{i64 16, !"_ZTS1A"}
+!1 = !{i64 16, !"_ZTS1B"}
+!2 = !{i64 16, !"_ZTS1C"}
+!3 = !{i64 16, !"_ZTS1D"}
+!4 = !{i64 48, !"_ZTS1C"}
+</pre></div>
+</div>
+<p>With this type metadata, we can now use the <code class="docutils literal notranslate"><span class="pre">llvm.type.test</span></code> intrinsic to
+test whether a given pointer is compatible with a type identifier. Working
+backwards, if <code class="docutils literal notranslate"><span class="pre">llvm.type.test</span></code> returns true for a particular pointer,
+we can also statically determine the identities of the virtual functions
+that a particular virtual call may call. For example, if a program assumes
+a pointer to be a member of <code class="docutils literal notranslate"><span class="pre">!"_ZST1A"</span></code>, we know that the address can
+be only be one of <code class="docutils literal notranslate"><span class="pre">_ZTV1A+16</span></code>, <code class="docutils literal notranslate"><span class="pre">_ZTV1B+16</span></code> or <code class="docutils literal notranslate"><span class="pre">_ZTV1D+16</span></code> (i.e. the
+address points of the vtables of A, B and D respectively). If we then load
+an address from that pointer, we know that the address can only be one of
+<code class="docutils literal notranslate"><span class="pre">&A::f</span></code>, <code class="docutils literal notranslate"><span class="pre">&B::f</span></code> or <code class="docutils literal notranslate"><span class="pre">&D::f</span></code>.</p>
+</div>
+<div class="section" id="testing-addresses-for-type-membership">
+<h2>Testing Addresses For Type Membership<a class="headerlink" href="#testing-addresses-for-type-membership" title="Permalink to this headline">¶</a></h2>
+<p>If a program tests an address using <code class="docutils literal notranslate"><span class="pre">llvm.type.test</span></code>, this will cause
+a link-time optimization pass, <code class="docutils literal notranslate"><span class="pre">LowerTypeTests</span></code>, to replace calls to this
+intrinsic with efficient code to perform type member tests. At a high level,
+the pass will lay out referenced globals in a consecutive memory region in
+the object file, construct bit vectors that map onto that memory region,
+and generate code at each of the <code class="docutils literal notranslate"><span class="pre">llvm.type.test</span></code> call sites to test
+pointers against those bit vectors. Because of the layout manipulation, the
+globalsâ definitions must be available at LTO time. For more information,
+see the <a class="reference external" href="http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html">control flow integrity design document</a>.</p>
+<p>A type identifier that identifies functions is transformed into a jump table,
+which is a block of code consisting of one branch instruction for each
+of the functions associated with the type identifier that branches to the
+target function. The pass will redirect any taken function addresses to the
+corresponding jump table entry. In the object fileâs symbol table, the jump
+table entries take the identities of the original functions, so that addresses
+taken outside the module will pass any verification done inside the module.</p>
+<p>Jump tables may call external functions, so their definitions need not
+be available at LTO time. Note that if an externally defined function is
+associated with a type identifier, there is no guarantee that its identity
+within the module will be the same as its identity outside of the module,
+as the former will be the jump table entry if a jump table is necessary.</p>
+<p>The <a class="reference external" href="https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Transforms/IPO/LowerTypeTests.h">GlobalLayoutBuilder</a> class is responsible for laying out the globals
+efficiently to minimize the sizes of the underlying bitsets.</p>
+<table class="docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field-odd field"><th class="field-name">Example:</th><td class="field-body"></td>
+</tr>
+</tbody>
+</table>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>target datalayout = "e-p:32:32"
+
+ at a = internal global i32 0, !type !0
+ at b = internal global i32 0, !type !0, !type !1
+ at c = internal global i32 0, !type !1
+ at d = internal global [2 x i32] [i32 0, i32 0], !type !2
+
+define void @e() !type !3 {
+ ret void
+}
+
+define void @f() {
+ ret void
+}
+
+declare void @g() !type !3
+
+!0 = !{i32 0, !"typeid1"}
+!1 = !{i32 0, !"typeid2"}
+!2 = !{i32 4, !"typeid2"}
+!3 = !{i32 0, !"typeid3"}
+
+declare i1 @llvm.type.test(i8* %ptr, metadata %typeid) nounwind readnone
+
+define i1 @foo(i32* %p) {
+ %pi8 = bitcast i32* %p to i8*
+ %x = call i1 @llvm.type.test(i8* %pi8, metadata !"typeid1")
+ ret i1 %x
+}
+
+define i1 @bar(i32* %p) {
+ %pi8 = bitcast i32* %p to i8*
+ %x = call i1 @llvm.type.test(i8* %pi8, metadata !"typeid2")
+ ret i1 %x
+}
+
+define i1 @baz(void ()* %p) {
+ %pi8 = bitcast void ()* %p to i8*
+ %x = call i1 @llvm.type.test(i8* %pi8, metadata !"typeid3")
+ ret i1 %x
+}
+
+define void @main() {
+ %a1 = call i1 @foo(i32* @a) ; returns 1
+ %b1 = call i1 @foo(i32* @b) ; returns 1
+ %c1 = call i1 @foo(i32* @c) ; returns 0
+ %a2 = call i1 @bar(i32* @a) ; returns 0
+ %b2 = call i1 @bar(i32* @b) ; returns 1
+ %c2 = call i1 @bar(i32* @c) ; returns 1
+ %d02 = call i1 @bar(i32* getelementptr ([2 x i32]* @d, i32 0, i32 0)) ; returns 0
+ %d12 = call i1 @bar(i32* getelementptr ([2 x i32]* @d, i32 0, i32 1)) ; returns 1
+ %e = call i1 @baz(void ()* @e) ; returns 1
+ %f = call i1 @baz(void ()* @f) ; returns 0
+ %g = call i1 @baz(void ()* @g) ; returns 1
+ ret void
+}
+</pre></div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="TransformMetadata.html" title="Code Transformation Metadata"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="MergeFunctions.html" title="MergeFunctions pass, how it works"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/Vectorizers.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/Vectorizers.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/Vectorizers.html (added)
+++ www-releases/trunk/9.0.0/docs/Vectorizers.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,492 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Auto-Vectorization in LLVM — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Vectorization Plan" href="Proposals/VectorizationPlan.html" />
+ <link rel="prev" title="Source Level Debugging with LLVM" href="SourceLevelDebugging.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" role="navigation" aria-label="related navigation">
+ <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/VectorizationPlan.html" title="Vectorization Plan"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="SourceLevelDebugging.html" title="Source Level Debugging with 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" role="main">
+
+ <div class="section" id="auto-vectorization-in-llvm">
+<h1>Auto-Vectorization in LLVM<a class="headerlink" href="#auto-vectorization-in-llvm" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#the-loop-vectorizer" id="id2">The Loop Vectorizer</a><ul>
+<li><a class="reference internal" href="#usage" id="id3">Usage</a><ul>
+<li><a class="reference internal" href="#command-line-flags" id="id4">Command line flags</a></li>
+<li><a class="reference internal" href="#pragma-loop-hint-directives" id="id5">Pragma loop hint directives</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#diagnostics" id="id6">Diagnostics</a></li>
+<li><a class="reference internal" href="#features" id="id7">Features</a><ul>
+<li><a class="reference internal" href="#loops-with-unknown-trip-count" id="id8">Loops with unknown trip count</a></li>
+<li><a class="reference internal" href="#runtime-checks-of-pointers" id="id9">Runtime Checks of Pointers</a></li>
+<li><a class="reference internal" href="#reductions" id="id10">Reductions</a></li>
+<li><a class="reference internal" href="#inductions" id="id11">Inductions</a></li>
+<li><a class="reference internal" href="#if-conversion" id="id12">If Conversion</a></li>
+<li><a class="reference internal" href="#pointer-induction-variables" id="id13">Pointer Induction Variables</a></li>
+<li><a class="reference internal" href="#reverse-iterators" id="id14">Reverse Iterators</a></li>
+<li><a class="reference internal" href="#scatter-gather" id="id15">Scatter / Gather</a></li>
+<li><a class="reference internal" href="#vectorization-of-mixed-types" id="id16">Vectorization of Mixed Types</a></li>
+<li><a class="reference internal" href="#global-structures-alias-analysis" id="id17">Global Structures Alias Analysis</a></li>
+<li><a class="reference internal" href="#vectorization-of-function-calls" id="id18">Vectorization of function calls</a></li>
+<li><a class="reference internal" href="#partial-unrolling-during-vectorization" id="id19">Partial unrolling during vectorization</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#performance" id="id20">Performance</a></li>
+<li><a class="reference internal" href="#ongoing-development-directions" id="id21">Ongoing Development Directions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-slp-vectorizer" id="id22">The SLP Vectorizer</a><ul>
+<li><a class="reference internal" href="#details" id="id23">Details</a></li>
+<li><a class="reference internal" href="#id1" id="id24">Usage</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<p>LLVM has two vectorizers: The <a class="reference internal" href="#loop-vectorizer"><span class="std std-ref">Loop Vectorizer</span></a>,
+which operates on Loops, and the <a class="reference internal" href="#slp-vectorizer"><span class="std std-ref">SLP Vectorizer</span></a>. These vectorizers
+focus on different optimization opportunities and use different techniques.
+The SLP vectorizer merges multiple scalars that are found in the code into
+vectors while the Loop Vectorizer widens instructions in loops
+to operate on multiple consecutive iterations.</p>
+<p>Both the Loop Vectorizer and the SLP Vectorizer are enabled by default.</p>
+<div class="section" id="the-loop-vectorizer">
+<span id="loop-vectorizer"></span><h2><a class="toc-backref" href="#id2">The Loop Vectorizer</a><a class="headerlink" href="#the-loop-vectorizer" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="usage">
+<h3><a class="toc-backref" href="#id3">Usage</a><a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h3>
+<p>The Loop Vectorizer is enabled by default, but it can be disabled
+through clang using the command line flag:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> clang ... -fno-vectorize file.c
+</pre></div>
+</div>
+<div class="section" id="command-line-flags">
+<h4><a class="toc-backref" href="#id4">Command line flags</a><a class="headerlink" href="#command-line-flags" title="Permalink to this headline">¶</a></h4>
+<p>The loop vectorizer uses a cost model to decide on the optimal vectorization factor
+and unroll factor. However, users of the vectorizer can force the vectorizer to use
+specific values. Both âclangâ and âoptâ support the flags below.</p>
+<p>Users can control the vectorization SIMD width using the command line flag â-force-vector-widthâ.</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> clang -mllvm -force-vector-width<span class="o">=</span><span class="m">8</span> ...
+<span class="gp">$</span> opt -loop-vectorize -force-vector-width<span class="o">=</span><span class="m">8</span> ...
+</pre></div>
+</div>
+<p>Users can control the unroll factor using the command line flag â-force-vector-interleaveâ</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> clang -mllvm -force-vector-interleave<span class="o">=</span><span class="m">2</span> ...
+<span class="gp">$</span> opt -loop-vectorize -force-vector-interleave<span class="o">=</span><span class="m">2</span> ...
+</pre></div>
+</div>
+</div>
+<div class="section" id="pragma-loop-hint-directives">
+<h4><a class="toc-backref" href="#id5">Pragma loop hint directives</a><a class="headerlink" href="#pragma-loop-hint-directives" title="Permalink to this headline">¶</a></h4>
+<p>The <code class="docutils literal notranslate"><span class="pre">#pragma</span> <span class="pre">clang</span> <span class="pre">loop</span></code> directive allows loop vectorization hints to be
+specified for the subsequent for, while, do-while, or c++11 range-based for
+loop. The directive allows vectorization and interleaving to be enabled or
+disabled. Vector width as well as interleave count can also be manually
+specified. The following example explicitly enables vectorization and
+interleaving:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#pragma clang loop vectorize(enable) interleave(enable)</span>
+<span class="k">while</span><span class="p">(...)</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The following example implicitly enables vectorization and interleaving by
+specifying a vector width and interleaving count:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#pragma clang loop vectorize_width(2) interleave_count(2)</span>
+<span class="k">for</span><span class="p">(...)</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>See the Clang
+<a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations">language extensions</a>
+for details.</p>
+</div>
+</div>
+<div class="section" id="diagnostics">
+<h3><a class="toc-backref" href="#id6">Diagnostics</a><a class="headerlink" href="#diagnostics" title="Permalink to this headline">¶</a></h3>
+<p>Many loops cannot be vectorized including loops with complicated control flow,
+unvectorizable types, and unvectorizable calls. The loop vectorizer generates
+optimization remarks which can be queried using command line options to identify
+and diagnose loops that are skipped by the loop-vectorizer.</p>
+<p>Optimization remarks are enabled using:</p>
+<p><code class="docutils literal notranslate"><span class="pre">-Rpass=loop-vectorize</span></code> identifies loops that were successfully vectorized.</p>
+<p><code class="docutils literal notranslate"><span class="pre">-Rpass-missed=loop-vectorize</span></code> identifies loops that failed vectorization and
+indicates if vectorization was specified.</p>
+<p><code class="docutils literal notranslate"><span class="pre">-Rpass-analysis=loop-vectorize</span></code> identifies the statements that caused
+vectorization to fail. If in addition <code class="docutils literal notranslate"><span class="pre">-fsave-optimization-record</span></code> is
+provided, multiple causes of vectorization failure may be listed (this behavior
+might change in the future).</p>
+<p>Consider the following loop:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#pragma clang loop vectorize(enable)</span>
+<span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">Length</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">switch</span><span class="p">(</span><span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">])</span> <span class="p">{</span>
+ <span class="k">case</span> <span class="mi">0</span><span class="o">:</span> <span class="n">A</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="mi">2</span><span class="p">;</span> <span class="k">break</span><span class="p">;</span>
+ <span class="k">case</span> <span class="mi">1</span><span class="o">:</span> <span class="n">A</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="p">;</span> <span class="k">break</span><span class="p">;</span>
+ <span class="k">default</span><span class="o">:</span> <span class="n">A</span><span class="p">[</span><span class="n">i</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>
+</pre></div>
+</div>
+<p>The command line <code class="docutils literal notranslate"><span class="pre">-Rpass-missed=loop-vectorized</span></code> prints the remark:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="go">no_switch.cpp:4:5: remark: loop not vectorized: vectorization is explicitly enabled [-Rpass-missed=loop-vectorize]</span>
+</pre></div>
+</div>
+<p>And the command line <code class="docutils literal notranslate"><span class="pre">-Rpass-analysis=loop-vectorize</span></code> indicates that the
+switch statement cannot be vectorized.</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="go">no_switch.cpp:4:5: remark: loop not vectorized: loop contains a switch statement [-Rpass-analysis=loop-vectorize]</span>
+<span class="go"> switch(A[i]) {</span>
+<span class="go"> ^</span>
+</pre></div>
+</div>
+<p>To ensure line and column numbers are produced include the command line options
+<code class="docutils literal notranslate"><span class="pre">-gline-tables-only</span></code> and <code class="docutils literal notranslate"><span class="pre">-gcolumn-info</span></code>. See the Clang <a class="reference external" href="http://clang.llvm.org/docs/UsersManual.html#options-to-emit-optimization-reports">user manual</a>
+for details</p>
+</div>
+<div class="section" id="features">
+<h3><a class="toc-backref" href="#id7">Features</a><a class="headerlink" href="#features" title="Permalink to this headline">¶</a></h3>
+<p>The LLVM Loop Vectorizer has a number of features that allow it to vectorize
+complex loops.</p>
+<div class="section" id="loops-with-unknown-trip-count">
+<h4><a class="toc-backref" href="#id8">Loops with unknown trip count</a><a class="headerlink" href="#loops-with-unknown-trip-count" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer supports loops with an unknown trip count.
+In the loop below, the iteration <code class="docutils literal notranslate"><span class="pre">start</span></code> and <code class="docutils literal notranslate"><span class="pre">finish</span></code> points are unknown,
+and the Loop Vectorizer has a mechanism to vectorize loops that do not start
+at zero. In this example, ânâ may not be a multiple of the vector width, and
+the vectorizer has to execute the last few iterations as scalar code. Keeping
+a scalar copy of the loop increases the code size.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">bar</span><span class="p">(</span><span class="kt">float</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">float</span><span class="o">*</span> <span class="n">B</span><span class="p">,</span> <span class="kt">float</span> <span class="n">K</span><span class="p">,</span> <span class="kt">int</span> <span class="n">start</span><span class="p">,</span> <span class="kt">int</span> <span class="n">end</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="n">start</span><span class="p">;</span> <span class="n">i</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="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">*=</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+</span> <span class="n">K</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="runtime-checks-of-pointers">
+<h4><a class="toc-backref" href="#id9">Runtime Checks of Pointers</a><a class="headerlink" href="#runtime-checks-of-pointers" title="Permalink to this headline">¶</a></h4>
+<p>In the example below, if the pointers A and B point to consecutive addresses,
+then it is illegal to vectorize the code because some elements of A will be
+written before they are read from array B.</p>
+<p>Some programmers use the ârestrictâ keyword to notify the compiler that the
+pointers are disjointed, but in our example, the Loop Vectorizer has no way of
+knowing that the pointers A and B are unique. The Loop Vectorizer handles this
+loop by placing code that checks, at runtime, if the arrays A and B point to
+disjointed memory locations. If arrays A and B overlap, then the scalar version
+of the loop is executed.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">bar</span><span class="p">(</span><span class="kt">float</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">float</span><span class="o">*</span> <span class="n">B</span><span class="p">,</span> <span class="kt">float</span> <span class="n">K</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">*=</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+</span> <span class="n">K</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="reductions">
+<h4><a class="toc-backref" href="#id10">Reductions</a><a class="headerlink" href="#reductions" title="Permalink to this headline">¶</a></h4>
+<p>In this example the <code class="docutils literal notranslate"><span class="pre">sum</span></code> variable is used by consecutive iterations of
+the loop. Normally, this would prevent vectorization, but the vectorizer can
+detect that âsumâ is a reduction variable. The variable âsumâ becomes a vector
+of integers, and at the end of the loop the elements of the array are added
+together to create the correct result. We support a number of different
+reduction operations, such as addition, multiplication, XOR, AND and OR.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span><span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kt">unsigned</span> <span class="n">sum</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">sum</span> <span class="o">+=</span> <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+</span> <span class="mi">5</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">sum</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>We support floating point reduction operations when <cite>-ffast-math</cite> is used.</p>
+</div>
+<div class="section" id="inductions">
+<h4><a class="toc-backref" href="#id11">Inductions</a><a class="headerlink" href="#inductions" title="Permalink to this headline">¶</a></h4>
+<p>In this example the value of the induction variable <code class="docutils literal notranslate"><span class="pre">i</span></code> is saved into an
+array. The Loop Vectorizer knows to vectorize induction variables.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">bar</span><span class="p">(</span><span class="kt">float</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">float</span><span class="o">*</span> <span class="n">B</span><span class="p">,</span> <span class="kt">float</span> <span class="n">K</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">A</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="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="if-conversion">
+<h4><a class="toc-backref" href="#id12">If Conversion</a><a class="headerlink" href="#if-conversion" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer is able to âflattenâ the IF statement in the code and
+generate a single stream of instructions. The Loop Vectorizer supports any
+control flow in the innermost loop. The innermost loop may contain complex
+nesting of IFs, ELSEs and even GOTOs.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span><span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kt">unsigned</span> <span class="n">sum</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</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">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">></span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">])</span>
+ <span class="n">sum</span> <span class="o">+=</span> <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+</span> <span class="mi">5</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">sum</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="pointer-induction-variables">
+<h4><a class="toc-backref" href="#id13">Pointer Induction Variables</a><a class="headerlink" href="#pointer-induction-variables" title="Permalink to this headline">¶</a></h4>
+<p>This example uses the âaccumulateâ function of the standard c++ library. This
+loop uses C++ iterators, which are pointers, and not integer indices.
+The Loop Vectorizer detects pointer induction variables and can vectorize
+this loop. This feature is important because many C++ programs use iterators.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">baz</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">std</span><span class="o">::</span><span class="n">accumulate</span><span class="p">(</span><span class="n">A</span><span class="p">,</span> <span class="n">A</span> <span class="o">+</span> <span class="n">n</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="reverse-iterators">
+<h4><a class="toc-backref" href="#id14">Reverse Iterators</a><a class="headerlink" href="#reverse-iterators" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer can vectorize loops that count backwards.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span><span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="n">n</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="o">--</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+=</span><span class="mi">1</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="scatter-gather">
+<h4><a class="toc-backref" href="#id15">Scatter / Gather</a><a class="headerlink" href="#scatter-gather" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer can vectorize code that becomes a sequence of scalar instructions
+that scatter/gathers memory.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span> <span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span> <span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">intptr_t</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+=</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span> <span class="o">*</span> <span class="mi">4</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In many situations the cost model will inform LLVM that this is not beneficial
+and LLVM will only vectorize such code if forced with â-mllvm -force-vector-width=#â.</p>
+</div>
+<div class="section" id="vectorization-of-mixed-types">
+<h4><a class="toc-backref" href="#id16">Vectorization of Mixed Types</a><a class="headerlink" href="#vectorization-of-mixed-types" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer can vectorize programs with mixed types. The Vectorizer
+cost model can estimate the cost of the type conversion and decide if
+vectorization is profitable.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">char</span> <span class="o">*</span><span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">,</span> <span class="kt">int</span> <span class="n">k</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+=</span> <span class="mi">4</span> <span class="o">*</span> <span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="global-structures-alias-analysis">
+<h4><a class="toc-backref" href="#id17">Global Structures Alias Analysis</a><a class="headerlink" href="#global-structures-alias-analysis" title="Permalink to this headline">¶</a></h4>
+<p>Access to global structures can also be vectorized, with alias analysis being
+used to make sure accesses donât alias. Run-time checks can also be added on
+pointer access to structure members.</p>
+<p>Many variations are supported, but some that rely on undefined behaviour being
+ignored (as other compilers do) are still being left un-vectorized.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">A</span><span class="p">[</span><span class="mi">100</span><span class="p">],</span> <span class="n">K</span><span class="p">,</span> <span class="n">B</span><span class="p">[</span><span class="mi">100</span><span class="p">];</span> <span class="p">}</span> <span class="n">Foo</span><span class="p">;</span>
+
+<span class="kt">int</span> <span class="nf">foo</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">Foo</span><span class="p">.</span><span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="n">Foo</span><span class="p">.</span><span class="n">B</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+</span> <span class="mi">100</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="vectorization-of-function-calls">
+<h4><a class="toc-backref" href="#id18">Vectorization of function calls</a><a class="headerlink" href="#vectorization-of-function-calls" title="Permalink to this headline">¶</a></h4>
+<p>The Loop Vectorizer can vectorize intrinsic math functions.
+See the table below for a list of these functions.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="26%" />
+<col width="26%" />
+<col width="47%" />
+</colgroup>
+<tbody valign="top">
+<tr class="row-odd"><td>pow</td>
+<td>exp</td>
+<td>exp2</td>
+</tr>
+<tr class="row-even"><td>sin</td>
+<td>cos</td>
+<td>sqrt</td>
+</tr>
+<tr class="row-odd"><td>log</td>
+<td>log2</td>
+<td>log10</td>
+</tr>
+<tr class="row-even"><td>fabs</td>
+<td>floor</td>
+<td>ceil</td>
+</tr>
+<tr class="row-odd"><td>fma</td>
+<td>trunc</td>
+<td>nearbyint</td>
+</tr>
+<tr class="row-even"><td> </td>
+<td> </td>
+<td>fmuladd</td>
+</tr>
+</tbody>
+</table>
+<p>Note that the optimizer may not be able to vectorize math library functions
+that correspond to these intrinsics if the library calls access external state
+such as âerrnoâ. To allow better optimization of C/C++ math library functions,
+use â-fno-math-errnoâ.</p>
+<p>The loop vectorizer knows about special instructions on the target and will
+vectorize a loop containing a function call that maps to the instructions. For
+example, the loop below will be vectorized on Intel x86 if the SSE4.1 roundps
+instruction is available.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">float</span> <span class="o">*</span><span class="n">f</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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">1024</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">f</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">=</span> <span class="n">floorf</span><span class="p">(</span><span class="n">f</span><span class="p">[</span><span class="n">i</span><span class="p">]);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="partial-unrolling-during-vectorization">
+<h4><a class="toc-backref" href="#id19">Partial unrolling during vectorization</a><a class="headerlink" href="#partial-unrolling-during-vectorization" title="Permalink to this headline">¶</a></h4>
+<p>Modern processors feature multiple execution units, and only programs that contain a
+high degree of parallelism can fully utilize the entire width of the machine.
+The Loop Vectorizer increases the instruction level parallelism (ILP) by
+performing partial-unrolling of loops.</p>
+<p>In the example below the entire array is accumulated into the variable âsumâ.
+This is inefficient because only a single execution port can be used by the processor.
+By unrolling the code the Loop Vectorizer allows two or more execution ports
+to be used simultaneously.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span><span class="n">B</span><span class="p">,</span> <span class="kt">int</span> <span class="n">n</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kt">unsigned</span> <span class="n">sum</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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="n">n</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">sum</span> <span class="o">+=</span> <span class="n">A</span><span class="p">[</span><span class="n">i</span><span class="p">];</span>
+ <span class="k">return</span> <span class="n">sum</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The Loop Vectorizer uses a cost model to decide when it is profitable to unroll loops.
+The decision to unroll the loop depends on the register pressure and the generated code size.</p>
+</div>
+</div>
+<div class="section" id="performance">
+<h3><a class="toc-backref" href="#id20">Performance</a><a class="headerlink" href="#performance" title="Permalink to this headline">¶</a></h3>
+<p>This section shows the execution time of Clang on a simple benchmark:
+<a class="reference external" href="https://github.com/llvm/llvm-test-suite/tree/master/SingleSource/UnitTests/Vectorizer">gcc-loops</a>.
+This benchmarks is a collection of loops from the GCC autovectorization
+<a class="reference external" href="http://gcc.gnu.org/projects/tree-ssa/vectorization.html">page</a> by Dorit Nuzman.</p>
+<p>The chart below compares GCC-4.7, ICC-13, and Clang-SVN with and without loop vectorization at -O3, tuned for âcorei7-avxâ, running on a Sandybridge iMac.
+The Y-axis shows the time in msec. Lower is better. The last column shows the geomean of all the kernels.</p>
+<img alt="_images/gcc-loops.png" src="_images/gcc-loops.png" />
+<p>And Linpack-pc with the same configuration. Result is Mflops, higher is better.</p>
+<img alt="_images/linpack-pc.png" src="_images/linpack-pc.png" />
+</div>
+<div class="section" id="ongoing-development-directions">
+<h3><a class="toc-backref" href="#id21">Ongoing Development Directions</a><a class="headerlink" href="#ongoing-development-directions" title="Permalink to this headline">¶</a></h3>
+<div class="toctree-wrapper compound">
+</div>
+<dl class="docutils">
+<dt><a class="reference internal" href="Proposals/VectorizationPlan.html"><span class="doc">Vectorization Plan</span></a></dt>
+<dd>Modeling the process and upgrading the infrastructure of LLVMâs Loop Vectorizer.</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="the-slp-vectorizer">
+<span id="slp-vectorizer"></span><h2><a class="toc-backref" href="#id22">The SLP Vectorizer</a><a class="headerlink" href="#the-slp-vectorizer" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="details">
+<h3><a class="toc-backref" href="#id23">Details</a><a class="headerlink" href="#details" title="Permalink to this headline">¶</a></h3>
+<p>The goal of SLP vectorization (a.k.a. superword-level parallelism) is
+to combine similar independent instructions
+into vector instructions. Memory accesses, arithmetic operations, comparison
+operations, PHI-nodes, can all be vectorized using this technique.</p>
+<p>For example, the following function performs very similar operations on its
+inputs (a1, b1) and (a2, b2). The basic-block vectorizer may combine these
+into vector operations.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">foo</span><span class="p">(</span><span class="kt">int</span> <span class="n">a1</span><span class="p">,</span> <span class="kt">int</span> <span class="n">a2</span><span class="p">,</span> <span class="kt">int</span> <span class="n">b1</span><span class="p">,</span> <span class="kt">int</span> <span class="n">b2</span><span class="p">,</span> <span class="kt">int</span> <span class="o">*</span><span class="n">A</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">A</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">=</span> <span class="n">a1</span><span class="o">*</span><span class="p">(</span><span class="n">a1</span> <span class="o">+</span> <span class="n">b1</span><span class="p">)</span><span class="o">/</span><span class="n">b1</span> <span class="o">+</span> <span class="mi">50</span><span class="o">*</span><span class="n">b1</span><span class="o">/</span><span class="n">a1</span><span class="p">;</span>
+ <span class="n">A</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span> <span class="o">=</span> <span class="n">a2</span><span class="o">*</span><span class="p">(</span><span class="n">a2</span> <span class="o">+</span> <span class="n">b2</span><span class="p">)</span><span class="o">/</span><span class="n">b2</span> <span class="o">+</span> <span class="mi">50</span><span class="o">*</span><span class="n">b2</span><span class="o">/</span><span class="n">a2</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The SLP-vectorizer processes the code bottom-up, across basic blocks, in search of scalars to combine.</p>
+</div>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id24">Usage</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<p>The SLP Vectorizer is enabled by default, but it can be disabled
+through clang using the command line flag:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> clang -fno-slp-vectorize file.c
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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/VectorizationPlan.html" title="Vectorization Plan"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="SourceLevelDebugging.html" title="Source Level Debugging with 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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/WritingAnLLVMBackend.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/WritingAnLLVMBackend.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/WritingAnLLVMBackend.html (added)
+++ www-releases/trunk/9.0.0/docs/WritingAnLLVMBackend.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,1845 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Writing an LLVM Backend — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="How To Use Instruction Mappings" href="HowToUseInstrMappings.html" />
+ <link rel="prev" title="Vectorization Plan" href="Proposals/VectorizationPlan.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" role="navigation" aria-label="related navigation">
+ <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="HowToUseInstrMappings.html" title="How To Use Instruction Mappings"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="Proposals/VectorizationPlan.html" title="Vectorization Plan"
+ 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" role="main">
+
+ <div class="section" id="writing-an-llvm-backend">
+<h1>Writing an LLVM Backend<a class="headerlink" href="#writing-an-llvm-backend" title="Permalink to this headline">¶</a></h1>
+<div class="toctree-wrapper compound">
+</div>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id3">Introduction</a><ul>
+<li><a class="reference internal" href="#audience" id="id4">Audience</a></li>
+<li><a class="reference internal" href="#prerequisite-reading" id="id5">Prerequisite Reading</a></li>
+<li><a class="reference internal" href="#basic-steps" id="id6">Basic Steps</a></li>
+<li><a class="reference internal" href="#preliminaries" id="id7">Preliminaries</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#target-machine" id="id8">Target Machine</a></li>
+<li><a class="reference internal" href="#target-registration" id="id9">Target Registration</a></li>
+<li><a class="reference internal" href="#register-set-and-register-classes" id="id10">Register Set and Register Classes</a><ul>
+<li><a class="reference internal" href="#defining-a-register" id="id11">Defining a Register</a></li>
+<li><a class="reference internal" href="#defining-a-register-class" id="id12">Defining a Register Class</a></li>
+<li><a class="reference internal" href="#implement-a-subclass-of-targetregisterinfo" id="id13">Implement a subclass of <code class="docutils literal notranslate"><span class="pre">TargetRegisterInfo</span></code></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#instruction-set" id="id14">Instruction Set</a><ul>
+<li><a class="reference internal" href="#instruction-operand-mapping" id="id15">Instruction Operand Mapping</a><ul>
+<li><a class="reference internal" href="#instruction-operand-name-mapping" id="id16">Instruction Operand Name Mapping</a></li>
+<li><a class="reference internal" href="#instruction-operand-types" id="id17">Instruction Operand Types</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#instruction-scheduling" id="id18">Instruction Scheduling</a></li>
+<li><a class="reference internal" href="#instruction-relation-mapping" id="id19">Instruction Relation Mapping</a></li>
+<li><a class="reference internal" href="#implement-a-subclass-of-targetinstrinfo" id="id20">Implement a subclass of <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo</span></code></a></li>
+<li><a class="reference internal" href="#branch-folding-and-if-conversion" id="id21">Branch Folding and If Conversion</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#instruction-selector" id="id22">Instruction Selector</a><ul>
+<li><a class="reference internal" href="#the-selectiondag-legalize-phase" id="id23">The SelectionDAG Legalize Phase</a><ul>
+<li><a class="reference internal" href="#promote" id="id24">Promote</a></li>
+<li><a class="reference internal" href="#expand" id="id25">Expand</a></li>
+<li><a class="reference internal" href="#custom" id="id26">Custom</a></li>
+<li><a class="reference internal" href="#legal" id="id27">Legal</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#calling-conventions" id="id28">Calling Conventions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#assembly-printer" id="id29">Assembly Printer</a></li>
+<li><a class="reference internal" href="#subtarget-support" id="id30">Subtarget Support</a></li>
+<li><a class="reference internal" href="#jit-support" id="id31">JIT Support</a><ul>
+<li><a class="reference internal" href="#machine-code-emitter" id="id32">Machine Code Emitter</a></li>
+<li><a class="reference internal" href="#target-jit-info" id="id33">Target JIT Info</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id3">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document describes techniques for writing compiler backends that convert
+the LLVM Intermediate Representation (IR) to code for a specified machine or
+other languages. Code intended for a specific machine can take the form of
+either assembly code or binary code (usable for a JIT compiler).</p>
+<p>The backend of LLVM features a target-independent code generator that may
+create output for several types of target CPUs â including X86, PowerPC,
+ARM, and SPARC. The backend may also be used to generate code targeted at SPUs
+of the Cell processor or GPUs to support the execution of compute kernels.</p>
+<p>The document focuses on existing examples found in subdirectories of
+<code class="docutils literal notranslate"><span class="pre">llvm/lib/Target</span></code> in a downloaded LLVM release. In particular, this document
+focuses on the example of creating a static compiler (one that emits text
+assembly) for a SPARC target, because SPARC has fairly standard
+characteristics, such as a RISC instruction set and straightforward calling
+conventions.</p>
+<div class="section" id="audience">
+<h3><a class="toc-backref" href="#id4">Audience</a><a class="headerlink" href="#audience" title="Permalink to this headline">¶</a></h3>
+<p>The audience for this document is anyone who needs to write an LLVM backend to
+generate code for a specific hardware or software target.</p>
+</div>
+<div class="section" id="prerequisite-reading">
+<h3><a class="toc-backref" href="#id5">Prerequisite Reading</a><a class="headerlink" href="#prerequisite-reading" title="Permalink to this headline">¶</a></h3>
+<p>These essential documents must be read before reading this document:</p>
+<ul class="simple">
+<li><a class="reference external" href="LangRef.html">LLVM Language Reference Manual</a> â a reference manual for
+the LLVM assembly language.</li>
+<li><a class="reference internal" href="CodeGenerator.html"><span class="doc">The LLVM Target-Independent Code Generator</span></a> â a guide to the components (classes and code
+generation algorithms) for translating the LLVM internal representation into
+machine code for a specified target. Pay particular attention to the
+descriptions of code generation stages: Instruction Selection, Scheduling and
+Formation, SSA-based Optimization, Register Allocation, Prolog/Epilog Code
+Insertion, Late Machine Code Optimizations, and Code Emission.</li>
+<li><a class="reference internal" href="TableGen/index.html"><span class="doc">TableGen</span></a> â a document that describes the TableGen
+(<code class="docutils literal notranslate"><span class="pre">tblgen</span></code>) application that manages domain-specific information to support
+LLVM code generation. TableGen processes input from a target description
+file (<code class="docutils literal notranslate"><span class="pre">.td</span></code> suffix) and generates C++ code that can be used for code
+generation.</li>
+<li><a class="reference internal" href="WritingAnLLVMPass.html"><span class="doc">Writing an LLVM Pass</span></a> â The assembly printer is a <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>, as
+are several <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> processing steps.</li>
+</ul>
+<p>To follow the SPARC examples in this document, have a copy of <a class="reference external" href="http://www.sparc.org/standards/V8.pdf">The SPARC
+Architecture Manual, Version 8</a> for
+reference. For details about the ARM instruction set, refer to the <a class="reference external" href="http://infocenter.arm.com/">ARM
+Architecture Reference Manual</a>. For more about
+the GNU Assembler format (<code class="docutils literal notranslate"><span class="pre">GAS</span></code>), see <a class="reference external" href="http://sourceware.org/binutils/docs/as/index.html">Using As</a>, especially for the
+assembly printer. âUsing Asâ contains a list of target machine dependent
+features.</p>
+</div>
+<div class="section" id="basic-steps">
+<h3><a class="toc-backref" href="#id6">Basic Steps</a><a class="headerlink" href="#basic-steps" title="Permalink to this headline">¶</a></h3>
+<p>To write a compiler backend for LLVM that converts the LLVM IR to code for a
+specified target (machine or other language), follow these steps:</p>
+<ul class="simple">
+<li>Create a subclass of the <code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code> class that describes
+characteristics of your target machine. Copy existing examples of specific
+<code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code> class and header files; for example, start with
+<code class="docutils literal notranslate"><span class="pre">SparcTargetMachine.cpp</span></code> and <code class="docutils literal notranslate"><span class="pre">SparcTargetMachine.h</span></code>, but change the file
+names for your target. Similarly, change code that references â<code class="docutils literal notranslate"><span class="pre">Sparc</span></code>â to
+reference your target.</li>
+<li>Describe the register set of the target. Use TableGen to generate code for
+register definition, register aliases, and register classes from a
+target-specific <code class="docutils literal notranslate"><span class="pre">RegisterInfo.td</span></code> input file. You should also write
+additional code for a subclass of the <code class="docutils literal notranslate"><span class="pre">TargetRegisterInfo</span></code> class that
+represents the class register file data used for register allocation and also
+describes the interactions between registers.</li>
+<li>Describe the instruction set of the target. Use TableGen to generate code
+for target-specific instructions from target-specific versions of
+<code class="docutils literal notranslate"><span class="pre">TargetInstrFormats.td</span></code> and <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo.td</span></code>. You should write
+additional code for a subclass of the <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo</span></code> class to represent
+machine instructions supported by the target machine.</li>
+<li>Describe the selection and conversion of the LLVM IR from a Directed Acyclic
+Graph (DAG) representation of instructions to native target-specific
+instructions. Use TableGen to generate code that matches patterns and
+selects instructions based on additional information in a target-specific
+version of <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo.td</span></code>. Write code for <code class="docutils literal notranslate"><span class="pre">XXXISelDAGToDAG.cpp</span></code>,
+where <code class="docutils literal notranslate"><span class="pre">XXX</span></code> identifies the specific target, to perform pattern matching and
+DAG-to-DAG instruction selection. Also write code in <code class="docutils literal notranslate"><span class="pre">XXXISelLowering.cpp</span></code>
+to replace or remove operations and data types that are not supported
+natively in a SelectionDAG.</li>
+<li>Write code for an assembly printer that converts LLVM IR to a GAS format for
+your target machine. You should add assembly strings to the instructions
+defined in your target-specific version of <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo.td</span></code>. You
+should also write code for a subclass of <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> that performs the
+LLVM-to-assembly conversion and a trivial subclass of <code class="docutils literal notranslate"><span class="pre">TargetAsmInfo</span></code>.</li>
+<li>Optionally, add support for subtargets (i.e., variants with different
+capabilities). You should also write code for a subclass of the
+<code class="docutils literal notranslate"><span class="pre">TargetSubtarget</span></code> class, which allows you to use the <code class="docutils literal notranslate"><span class="pre">-mcpu=</span></code> and
+<code class="docutils literal notranslate"><span class="pre">-mattr=</span></code> command-line options.</li>
+<li>Optionally, add JIT support and create a machine code emitter (subclass of
+<code class="docutils literal notranslate"><span class="pre">TargetJITInfo</span></code>) that is used to emit binary code directly into memory.</li>
+</ul>
+<p>In the <code class="docutils literal notranslate"><span class="pre">.cpp</span></code> and <code class="docutils literal notranslate"><span class="pre">.h</span></code>. files, initially stub up these methods and then
+implement them later. Initially, you may not know which private members that
+the class will need and which components will need to be subclassed.</p>
+</div>
+<div class="section" id="preliminaries">
+<h3><a class="toc-backref" href="#id7">Preliminaries</a><a class="headerlink" href="#preliminaries" title="Permalink to this headline">¶</a></h3>
+<p>To actually create your compiler backend, you need to create and modify a few
+files. The absolute minimum is discussed here. But to actually use the LLVM
+target-independent code generator, you must perform the steps described in the
+<a class="reference internal" href="CodeGenerator.html"><span class="doc">LLVM Target-Independent Code Generator</span></a> document.</p>
+<p>First, you should create a subdirectory under <code class="docutils literal notranslate"><span class="pre">lib/Target</span></code> to hold all the
+files related to your target. If your target is called âDummyâ, create the
+directory <code class="docutils literal notranslate"><span class="pre">lib/Target/Dummy</span></code>.</p>
+<p>In this new directory, create a <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code>. It is easiest to copy a
+<code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> of another target and modify it. It should at least contain
+the <code class="docutils literal notranslate"><span class="pre">LLVM_TARGET_DEFINITIONS</span></code> variable. The library can be named <code class="docutils literal notranslate"><span class="pre">LLVMDummy</span></code>
+(for example, see the MIPS target). Alternatively, you can split the library
+into <code class="docutils literal notranslate"><span class="pre">LLVMDummyCodeGen</span></code> and <code class="docutils literal notranslate"><span class="pre">LLVMDummyAsmPrinter</span></code>, the latter of which
+should be implemented in a subdirectory below <code class="docutils literal notranslate"><span class="pre">lib/Target/Dummy</span></code> (for example,
+see the PowerPC target).</p>
+<p>Note that these two naming schemes are hardcoded into <code class="docutils literal notranslate"><span class="pre">llvm-config</span></code>. Using
+any other naming scheme will confuse <code class="docutils literal notranslate"><span class="pre">llvm-config</span></code> and produce a lot of
+(seemingly unrelated) linker errors when linking <code class="docutils literal notranslate"><span class="pre">llc</span></code>.</p>
+<p>To make your target actually do something, you need to implement a subclass of
+<code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code>. This implementation should typically be in the file
+<code class="docutils literal notranslate"><span class="pre">lib/Target/DummyTargetMachine.cpp</span></code>, but any file in the <code class="docutils literal notranslate"><span class="pre">lib/Target</span></code>
+directory will be built and should work. To use LLVMâs target independent code
+generator, you should do what all current machine backends do: create a
+subclass of <code class="docutils literal notranslate"><span class="pre">LLVMTargetMachine</span></code>. (To create a target from scratch, create a
+subclass of <code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code>.)</p>
+<p>To get LLVM to actually build and link your target, you need to run <code class="docutils literal notranslate"><span class="pre">cmake</span></code>
+with <code class="docutils literal notranslate"><span class="pre">-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Dummy</span></code>. This will build your
+target without needing to add it to the list of all the targets.</p>
+<p>Once your target is stable, you can add it to the <code class="docutils literal notranslate"><span class="pre">LLVM_ALL_TARGETS</span></code> variable
+located in the main <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code>.</p>
+</div>
+</div>
+<div class="section" id="target-machine">
+<h2><a class="toc-backref" href="#id8">Target Machine</a><a class="headerlink" href="#target-machine" title="Permalink to this headline">¶</a></h2>
+<p><code class="docutils literal notranslate"><span class="pre">LLVMTargetMachine</span></code> is designed as a base class for targets implemented with
+the LLVM target-independent code generator. The <code class="docutils literal notranslate"><span class="pre">LLVMTargetMachine</span></code> class
+should be specialized by a concrete target class that implements the various
+virtual methods. <code class="docutils literal notranslate"><span class="pre">LLVMTargetMachine</span></code> is defined as a subclass of
+<code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code> in <code class="docutils literal notranslate"><span class="pre">include/llvm/Target/TargetMachine.h</span></code>. The
+<code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code> class implementation (<code class="docutils literal notranslate"><span class="pre">TargetMachine.cpp</span></code>) also processes
+numerous command-line options.</p>
+<p>To create a concrete target-specific subclass of <code class="docutils literal notranslate"><span class="pre">LLVMTargetMachine</span></code>, start
+by copying an existing <code class="docutils literal notranslate"><span class="pre">TargetMachine</span></code> class and header. You should name the
+files that you create to reflect your specific target. For instance, for the
+SPARC target, name the files <code class="docutils literal notranslate"><span class="pre">SparcTargetMachine.h</span></code> and
+<code class="docutils literal notranslate"><span class="pre">SparcTargetMachine.cpp</span></code>.</p>
+<p>For a target machine <code class="docutils literal notranslate"><span class="pre">XXX</span></code>, the implementation of <code class="docutils literal notranslate"><span class="pre">XXXTargetMachine</span></code> must
+have access methods to obtain objects that represent target components. These
+methods are named <code class="docutils literal notranslate"><span class="pre">get*Info</span></code>, and are intended to obtain the instruction set
+(<code class="docutils literal notranslate"><span class="pre">getInstrInfo</span></code>), register set (<code class="docutils literal notranslate"><span class="pre">getRegisterInfo</span></code>), stack frame layout
+(<code class="docutils literal notranslate"><span class="pre">getFrameInfo</span></code>), and similar information. <code class="docutils literal notranslate"><span class="pre">XXXTargetMachine</span></code> must also
+implement the <code class="docutils literal notranslate"><span class="pre">getDataLayout</span></code> method to access an object with target-specific
+data characteristics, such as data type size and alignment requirements.</p>
+<p>For instance, for the SPARC target, the header file <code class="docutils literal notranslate"><span class="pre">SparcTargetMachine.h</span></code>
+declares prototypes for several <code class="docutils literal notranslate"><span class="pre">get*Info</span></code> and <code class="docutils literal notranslate"><span class="pre">getDataLayout</span></code> methods that
+simply return a class member.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">namespace</span> <span class="n">llvm</span> <span class="p">{</span>
+
+<span class="k">class</span> <span class="nc">Module</span><span class="p">;</span>
+
+<span class="k">class</span> <span class="nc">SparcTargetMachine</span> <span class="o">:</span> <span class="k">public</span> <span class="n">LLVMTargetMachine</span> <span class="p">{</span>
+ <span class="k">const</span> <span class="n">DataLayout</span> <span class="n">DataLayout</span><span class="p">;</span> <span class="c1">// Calculates type size & alignment</span>
+ <span class="n">SparcSubtarget</span> <span class="n">Subtarget</span><span class="p">;</span>
+ <span class="n">SparcInstrInfo</span> <span class="n">InstrInfo</span><span class="p">;</span>
+ <span class="n">TargetFrameInfo</span> <span class="n">FrameInfo</span><span class="p">;</span>
+
+<span class="k">protected</span><span class="o">:</span>
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">TargetAsmInfo</span> <span class="o">*</span><span class="n">createTargetAsmInfo</span><span class="p">()</span> <span class="k">const</span><span class="p">;</span>
+
+<span class="k">public</span><span class="o">:</span>
+ <span class="n">SparcTargetMachine</span><span class="p">(</span><span class="k">const</span> <span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">,</span> <span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="o">&</span><span class="n">FS</span><span class="p">);</span>
+
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">SparcInstrInfo</span> <span class="o">*</span><span class="nf">getInstrInfo</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span><span class="k">return</span> <span class="o">&</span><span class="n">InstrInfo</span><span class="p">;</span> <span class="p">}</span>
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">TargetFrameInfo</span> <span class="o">*</span><span class="nf">getFrameInfo</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span><span class="k">return</span> <span class="o">&</span><span class="n">FrameInfo</span><span class="p">;</span> <span class="p">}</span>
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">TargetSubtarget</span> <span class="o">*</span><span class="nf">getSubtargetImpl</span><span class="p">()</span> <span class="k">const</span><span class="p">{</span><span class="k">return</span> <span class="o">&</span><span class="n">Subtarget</span><span class="p">;</span> <span class="p">}</span>
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">TargetRegisterInfo</span> <span class="o">*</span><span class="nf">getRegisterInfo</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="o">&</span><span class="n">InstrInfo</span><span class="p">.</span><span class="n">getRegisterInfo</span><span class="p">();</span>
+ <span class="p">}</span>
+ <span class="k">virtual</span> <span class="k">const</span> <span class="n">DataLayout</span> <span class="o">*</span><span class="nf">getDataLayout</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="o">&</span><span class="n">DataLayout</span><span class="p">;</span> <span class="p">}</span>
+ <span class="k">static</span> <span class="kt">unsigned</span> <span class="nf">getModuleMatchQuality</span><span class="p">(</span><span class="k">const</span> <span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">);</span>
+
+ <span class="c1">// Pass Pipeline Configuration</span>
+ <span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">addInstSelector</span><span class="p">(</span><span class="n">PassManagerBase</span> <span class="o">&</span><span class="n">PM</span><span class="p">,</span> <span class="kt">bool</span> <span class="n">Fast</span><span class="p">);</span>
+ <span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">addPreEmitPass</span><span class="p">(</span><span class="n">PassManagerBase</span> <span class="o">&</span><span class="n">PM</span><span class="p">,</span> <span class="kt">bool</span> <span class="n">Fast</span><span class="p">);</span>
+<span class="p">};</span>
+
+<span class="p">}</span> <span class="c1">// end namespace llvm</span>
+</pre></div>
+</div>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">getInstrInfo()</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">getRegisterInfo()</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">getFrameInfo()</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">getDataLayout()</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">getSubtargetImpl()</span></code></li>
+</ul>
+<p>For some targets, you also need to support the following methods:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">getTargetLowering()</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">getJITInfo()</span></code></li>
+</ul>
+<p>Some architectures, such as GPUs, do not support jumping to an arbitrary
+program location and implement branching using masked execution and loop using
+special instructions around the loop body. In order to avoid CFG modifications
+that introduce irreducible control flow not handled by such hardware, a target
+must call <cite>setRequiresStructuredCFG(true)</cite> when being initialized.</p>
+<p>In addition, the <code class="docutils literal notranslate"><span class="pre">XXXTargetMachine</span></code> constructor should specify a
+<code class="docutils literal notranslate"><span class="pre">TargetDescription</span></code> string that determines the data layout for the target
+machine, including characteristics such as pointer size, alignment, and
+endianness. For example, the constructor for <code class="docutils literal notranslate"><span class="pre">SparcTargetMachine</span></code> contains
+the following:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">SparcTargetMachine</span><span class="o">::</span><span class="n">SparcTargetMachine</span><span class="p">(</span><span class="k">const</span> <span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">,</span> <span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="o">&</span><span class="n">FS</span><span class="p">)</span>
+ <span class="o">:</span> <span class="n">DataLayout</span><span class="p">(</span><span class="s">"E-p:32:32-f128:128:128"</span><span class="p">),</span>
+ <span class="n">Subtarget</span><span class="p">(</span><span class="n">M</span><span class="p">,</span> <span class="n">FS</span><span class="p">),</span> <span class="n">InstrInfo</span><span class="p">(</span><span class="n">Subtarget</span><span class="p">),</span>
+ <span class="n">FrameInfo</span><span class="p">(</span><span class="n">TargetFrameInfo</span><span class="o">::</span><span class="n">StackGrowsDown</span><span class="p">,</span> <span class="mi">8</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Hyphens separate portions of the <code class="docutils literal notranslate"><span class="pre">TargetDescription</span></code> string.</p>
+<ul class="simple">
+<li>An upper-case â<code class="docutils literal notranslate"><span class="pre">E</span></code>â in the string indicates a big-endian target data model.
+A lower-case â<code class="docutils literal notranslate"><span class="pre">e</span></code>â indicates little-endian.</li>
+<li>â<code class="docutils literal notranslate"><span class="pre">p:</span></code>â is followed by pointer information: size, ABI alignment, and
+preferred alignment. If only two figures follow â<code class="docutils literal notranslate"><span class="pre">p:</span></code>â, then the first
+value is pointer size, and the second value is both ABI and preferred
+alignment.</li>
+<li>Then a letter for numeric type alignment: â<code class="docutils literal notranslate"><span class="pre">i</span></code>â, â<code class="docutils literal notranslate"><span class="pre">f</span></code>â, â<code class="docutils literal notranslate"><span class="pre">v</span></code>â, or
+â<code class="docutils literal notranslate"><span class="pre">a</span></code>â (corresponding to integer, floating point, vector, or aggregate).
+â<code class="docutils literal notranslate"><span class="pre">i</span></code>â, â<code class="docutils literal notranslate"><span class="pre">v</span></code>â, or â<code class="docutils literal notranslate"><span class="pre">a</span></code>â are followed by ABI alignment and preferred
+alignment. â<code class="docutils literal notranslate"><span class="pre">f</span></code>â is followed by three values: the first indicates the size
+of a long double, then ABI alignment, and then ABI preferred alignment.</li>
+</ul>
+</div>
+<div class="section" id="target-registration">
+<h2><a class="toc-backref" href="#id9">Target Registration</a><a class="headerlink" href="#target-registration" title="Permalink to this headline">¶</a></h2>
+<p>You must also register your target with the <code class="docutils literal notranslate"><span class="pre">TargetRegistry</span></code>, which is what
+other LLVM tools use to be able to lookup and use your target at runtime. The
+<code class="docutils literal notranslate"><span class="pre">TargetRegistry</span></code> can be used directly, but for most targets there are helper
+templates which should take care of the work for you.</p>
+<p>All targets should declare a global <code class="docutils literal notranslate"><span class="pre">Target</span></code> object which is used to
+represent the target during registration. Then, in the targetâs <code class="docutils literal notranslate"><span class="pre">TargetInfo</span></code>
+library, the target should define that object and use the <code class="docutils literal notranslate"><span class="pre">RegisterTarget</span></code>
+template to register the target. For example, the Sparc registration code
+looks like this:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">Target</span> <span class="n">llvm</span><span class="o">::</span><span class="n">getTheSparcTarget</span><span class="p">();</span>
+
+<span class="k">extern</span> <span class="s">"C"</span> <span class="kt">void</span> <span class="n">LLVMInitializeSparcTargetInfo</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">RegisterTarget</span><span class="o"><</span><span class="n">Triple</span><span class="o">::</span><span class="n">sparc</span><span class="p">,</span> <span class="cm">/*HasJIT=*/</span><span class="nb">false</span><span class="o">></span>
+ <span class="n">X</span><span class="p">(</span><span class="n">getTheSparcTarget</span><span class="p">(),</span> <span class="s">"sparc"</span><span class="p">,</span> <span class="s">"Sparc"</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This allows the <code class="docutils literal notranslate"><span class="pre">TargetRegistry</span></code> to look up the target by name or by target
+triple. In addition, most targets will also register additional features which
+are available in separate libraries. These registration steps are separate,
+because some clients may wish to only link in some parts of the target â the
+JIT code generator does not require the use of the assembler printer, for
+example. Here is an example of registering the Sparc assembly printer:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">extern</span> <span class="s">"C"</span> <span class="kt">void</span> <span class="n">LLVMInitializeSparcAsmPrinter</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">RegisterAsmPrinter</span><span class="o"><</span><span class="n">SparcAsmPrinter</span><span class="o">></span> <span class="n">X</span><span class="p">(</span><span class="n">getTheSparcTarget</span><span class="p">());</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>For more information, see â<a class="reference external" href="/doxygen/TargetRegistry_8h-source.html">llvm/Target/TargetRegistry.h</a>â.</p>
+</div>
+<div class="section" id="register-set-and-register-classes">
+<h2><a class="toc-backref" href="#id10">Register Set and Register Classes</a><a class="headerlink" href="#register-set-and-register-classes" title="Permalink to this headline">¶</a></h2>
+<p>You should describe a concrete target-specific class that represents the
+register file of a target machine. This class is called <code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo</span></code>
+(where <code class="docutils literal notranslate"><span class="pre">XXX</span></code> identifies the target) and represents the class register file
+data that is used for register allocation. It also describes the interactions
+between registers.</p>
+<p>You also need to define register classes to categorize related registers. A
+register class should be added for groups of registers that are all treated the
+same way for some instruction. Typical examples are register classes for
+integer, floating-point, or vector registers. A register allocator allows an
+instruction to use any register in a specified register class to perform the
+instruction in a similar manner. Register classes allocate virtual registers
+to instructions from these sets, and register classes let the
+target-independent register allocator automatically choose the actual
+registers.</p>
+<p>Much of the code for registers, including register definition, register
+aliases, and register classes, is generated by TableGen from
+<code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo.td</span></code> input files and placed in <code class="docutils literal notranslate"><span class="pre">XXXGenRegisterInfo.h.inc</span></code>
+and <code class="docutils literal notranslate"><span class="pre">XXXGenRegisterInfo.inc</span></code> output files. Some of the code in the
+implementation of <code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo</span></code> requires hand-coding.</p>
+<div class="section" id="defining-a-register">
+<h3><a class="toc-backref" href="#id11">Defining a Register</a><a class="headerlink" href="#defining-a-register" title="Permalink to this headline">¶</a></h3>
+<p>The <code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo.td</span></code> file typically starts with register definitions for
+a target machine. The <code class="docutils literal notranslate"><span class="pre">Register</span></code> class (specified in <code class="docutils literal notranslate"><span class="pre">Target.td</span></code>) is used
+to define an object for each register. The specified string <code class="docutils literal notranslate"><span class="pre">n</span></code> becomes the
+<code class="docutils literal notranslate"><span class="pre">Name</span></code> of the register. The basic <code class="docutils literal notranslate"><span class="pre">Register</span></code> object does not have any
+subregisters and does not specify any aliases.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class Register<string n> {
+ string Namespace = "";
+ string AsmName = n;
+ string Name = n;
+ int SpillSize = 0;
+ int SpillAlignment = 0;
+ list<Register> Aliases = [];
+ list<Register> SubRegs = [];
+ list<int> DwarfNumbers = [];
+}
+</pre></div>
+</div>
+<p>For example, in the <code class="docutils literal notranslate"><span class="pre">X86RegisterInfo.td</span></code> file, there are register definitions
+that utilize the <code class="docutils literal notranslate"><span class="pre">Register</span></code> class, such as:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
+</pre></div>
+</div>
+<p>This defines the register <code class="docutils literal notranslate"><span class="pre">AL</span></code> and assigns it values (with <code class="docutils literal notranslate"><span class="pre">DwarfRegNum</span></code>)
+that are used by <code class="docutils literal notranslate"><span class="pre">gcc</span></code>, <code class="docutils literal notranslate"><span class="pre">gdb</span></code>, or a debug information writer to identify a
+register. For register <code class="docutils literal notranslate"><span class="pre">AL</span></code>, <code class="docutils literal notranslate"><span class="pre">DwarfRegNum</span></code> takes an array of 3 values
+representing 3 different modes: the first element is for X86-64, the second for
+exception handling (EH) on X86-32, and the third is generic. -1 is a special
+Dwarf number that indicates the gcc number is undefined, and -2 indicates the
+register number is invalid for this mode.</p>
+<p>From the previously described line in the <code class="docutils literal notranslate"><span class="pre">X86RegisterInfo.td</span></code> file, TableGen
+generates this code in the <code class="docutils literal notranslate"><span class="pre">X86GenRegisterInfo.inc</span></code> file:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="k">const</span> <span class="kt">unsigned</span> <span class="n">GR8</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span> <span class="n">X86</span><span class="o">::</span><span class="n">AL</span><span class="p">,</span> <span class="p">...</span> <span class="p">};</span>
+
+<span class="k">const</span> <span class="kt">unsigned</span> <span class="n">AL_AliasSet</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span> <span class="n">X86</span><span class="o">::</span><span class="n">AX</span><span class="p">,</span> <span class="n">X86</span><span class="o">::</span><span class="n">EAX</span><span class="p">,</span> <span class="n">X86</span><span class="o">::</span><span class="n">RAX</span><span class="p">,</span> <span class="mi">0</span> <span class="p">};</span>
+
+<span class="k">const</span> <span class="n">TargetRegisterDesc</span> <span class="n">RegisterDescriptors</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="p">...</span>
+<span class="p">{</span> <span class="s">"AL"</span><span class="p">,</span> <span class="s">"AL"</span><span class="p">,</span> <span class="n">AL_AliasSet</span><span class="p">,</span> <span class="n">Empty_SubRegsSet</span><span class="p">,</span> <span class="n">Empty_SubRegsSet</span><span class="p">,</span> <span class="n">AL_SuperRegsSet</span> <span class="p">},</span> <span class="p">...</span>
+</pre></div>
+</div>
+<p>From the register info file, TableGen generates a <code class="docutils literal notranslate"><span class="pre">TargetRegisterDesc</span></code> object
+for each register. <code class="docutils literal notranslate"><span class="pre">TargetRegisterDesc</span></code> is defined in
+<code class="docutils literal notranslate"><span class="pre">include/llvm/Target/TargetRegisterInfo.h</span></code> with the following fields:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">TargetRegisterDesc</span> <span class="p">{</span>
+ <span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">AsmName</span><span class="p">;</span> <span class="c1">// Assembly language name for the register</span>
+ <span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">Name</span><span class="p">;</span> <span class="c1">// Printable name for the reg (for debugging)</span>
+ <span class="k">const</span> <span class="kt">unsigned</span> <span class="o">*</span><span class="n">AliasSet</span><span class="p">;</span> <span class="c1">// Register Alias Set</span>
+ <span class="k">const</span> <span class="kt">unsigned</span> <span class="o">*</span><span class="n">SubRegs</span><span class="p">;</span> <span class="c1">// Sub-register set</span>
+ <span class="k">const</span> <span class="kt">unsigned</span> <span class="o">*</span><span class="n">ImmSubRegs</span><span class="p">;</span> <span class="c1">// Immediate sub-register set</span>
+ <span class="k">const</span> <span class="kt">unsigned</span> <span class="o">*</span><span class="n">SuperRegs</span><span class="p">;</span> <span class="c1">// Super-register set</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>TableGen uses the entire target description file (<code class="docutils literal notranslate"><span class="pre">.td</span></code>) to determine text
+names for the register (in the <code class="docutils literal notranslate"><span class="pre">AsmName</span></code> and <code class="docutils literal notranslate"><span class="pre">Name</span></code> fields of
+<code class="docutils literal notranslate"><span class="pre">TargetRegisterDesc</span></code>) and the relationships of other registers to the defined
+register (in the other <code class="docutils literal notranslate"><span class="pre">TargetRegisterDesc</span></code> fields). In this example, other
+definitions establish the registers â<code class="docutils literal notranslate"><span class="pre">AX</span></code>â, â<code class="docutils literal notranslate"><span class="pre">EAX</span></code>â, and â<code class="docutils literal notranslate"><span class="pre">RAX</span></code>â as
+aliases for one another, so TableGen generates a null-terminated array
+(<code class="docutils literal notranslate"><span class="pre">AL_AliasSet</span></code>) for this register alias set.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">Register</span></code> class is commonly used as a base class for more complex
+classes. In <code class="docutils literal notranslate"><span class="pre">Target.td</span></code>, the <code class="docutils literal notranslate"><span class="pre">Register</span></code> class is the base for the
+<code class="docutils literal notranslate"><span class="pre">RegisterWithSubRegs</span></code> class that is used to define registers that need to
+specify subregisters in the <code class="docutils literal notranslate"><span class="pre">SubRegs</span></code> list, as shown here:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> {
+ let SubRegs = subregs;
+}
+</pre></div>
+</div>
+<p>In <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code>, additional register classes are defined for SPARC:
+a <code class="docutils literal notranslate"><span class="pre">Register</span></code> subclass, <code class="docutils literal notranslate"><span class="pre">SparcReg</span></code>, and further subclasses: <code class="docutils literal notranslate"><span class="pre">Ri</span></code>, <code class="docutils literal notranslate"><span class="pre">Rf</span></code>,
+and <code class="docutils literal notranslate"><span class="pre">Rd</span></code>. SPARC registers are identified by 5-bit ID numbers, which is a
+feature common to these subclasses. Note the use of â<code class="docutils literal notranslate"><span class="pre">let</span></code>â expressions to
+override values that are initially defined in a superclass (such as <code class="docutils literal notranslate"><span class="pre">SubRegs</span></code>
+field in the <code class="docutils literal notranslate"><span class="pre">Rd</span></code> class).</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class SparcReg<string n> : Register<n> {
+ field bits<5> Num;
+ let Namespace = "SP";
+}
+// Ri - 32-bit integer registers
+class Ri<bits<5> num, string n> :
+SparcReg<n> {
+ let Num = num;
+}
+// Rf - 32-bit floating-point registers
+class Rf<bits<5> num, string n> :
+SparcReg<n> {
+ let Num = num;
+}
+// Rd - Slots in the FP register file for 64-bit floating-point values.
+class Rd<bits<5> num, string n, list<Register> subregs> : SparcReg<n> {
+ let Num = num;
+ let SubRegs = subregs;
+}
+</pre></div>
+</div>
+<p>In the <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code> file, there are register definitions that
+utilize these subclasses of <code class="docutils literal notranslate"><span class="pre">Register</span></code>, such as:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>;
+def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
+...
+def F0 : Rf< 0, "F0">, DwarfRegNum<[32]>;
+def F1 : Rf< 1, "F1">, DwarfRegNum<[33]>;
+...
+def D0 : Rd< 0, "F0", [F0, F1]>, DwarfRegNum<[32]>;
+def D1 : Rd< 2, "F2", [F2, F3]>, DwarfRegNum<[34]>;
+</pre></div>
+</div>
+<p>The last two registers shown above (<code class="docutils literal notranslate"><span class="pre">D0</span></code> and <code class="docutils literal notranslate"><span class="pre">D1</span></code>) are double-precision
+floating-point registers that are aliases for pairs of single-precision
+floating-point sub-registers. In addition to aliases, the sub-register and
+super-register relationships of the defined register are in fields of a
+registerâs <code class="docutils literal notranslate"><span class="pre">TargetRegisterDesc</span></code>.</p>
+</div>
+<div class="section" id="defining-a-register-class">
+<h3><a class="toc-backref" href="#id12">Defining a Register Class</a><a class="headerlink" href="#defining-a-register-class" title="Permalink to this headline">¶</a></h3>
+<p>The <code class="docutils literal notranslate"><span class="pre">RegisterClass</span></code> class (specified in <code class="docutils literal notranslate"><span class="pre">Target.td</span></code>) is used to define an
+object that represents a group of related registers and also defines the
+default allocation order of the registers. A target description file
+<code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo.td</span></code> that uses <code class="docutils literal notranslate"><span class="pre">Target.td</span></code> can construct register classes
+using the following class:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class RegisterClass<string namespace,
+list<ValueType> regTypes, int alignment, dag regList> {
+ string Namespace = namespace;
+ list<ValueType> RegTypes = regTypes;
+ int Size = 0; // spill size, in bits; zero lets tblgen pick the size
+ int Alignment = alignment;
+
+ // CopyCost is the cost of copying a value between two registers
+ // default value 1 means a single instruction
+ // A negative value means copying is extremely expensive or impossible
+ int CopyCost = 1;
+ dag MemberList = regList;
+
+ // for register classes that are subregisters of this class
+ list<RegisterClass> SubRegClassList = [];
+
+ code MethodProtos = [{}]; // to insert arbitrary code
+ code MethodBodies = [{}];
+}
+</pre></div>
+</div>
+<p>To define a <code class="docutils literal notranslate"><span class="pre">RegisterClass</span></code>, use the following 4 arguments:</p>
+<ul class="simple">
+<li>The first argument of the definition is the name of the namespace.</li>
+<li>The second argument is a list of <code class="docutils literal notranslate"><span class="pre">ValueType</span></code> register type values that are
+defined in <code class="docutils literal notranslate"><span class="pre">include/llvm/CodeGen/ValueTypes.td</span></code>. Defined values include
+integer types (such as <code class="docutils literal notranslate"><span class="pre">i16</span></code>, <code class="docutils literal notranslate"><span class="pre">i32</span></code>, and <code class="docutils literal notranslate"><span class="pre">i1</span></code> for Boolean),
+floating-point types (<code class="docutils literal notranslate"><span class="pre">f32</span></code>, <code class="docutils literal notranslate"><span class="pre">f64</span></code>), and vector types (for example,
+<code class="docutils literal notranslate"><span class="pre">v8i16</span></code> for an <code class="docutils literal notranslate"><span class="pre">8</span> <span class="pre">x</span> <span class="pre">i16</span></code> vector). All registers in a <code class="docutils literal notranslate"><span class="pre">RegisterClass</span></code>
+must have the same <code class="docutils literal notranslate"><span class="pre">ValueType</span></code>, but some registers may store vector data in
+different configurations. For example a register that can process a 128-bit
+vector may be able to handle 16 8-bit integer elements, 8 16-bit integers, 4
+32-bit integers, and so on.</li>
+<li>The third argument of the <code class="docutils literal notranslate"><span class="pre">RegisterClass</span></code> definition specifies the
+alignment required of the registers when they are stored or loaded to
+memory.</li>
+<li>The final argument, <code class="docutils literal notranslate"><span class="pre">regList</span></code>, specifies which registers are in this class.
+If an alternative allocation order method is not specified, then <code class="docutils literal notranslate"><span class="pre">regList</span></code>
+also defines the order of allocation used by the register allocator. Besides
+simply listing registers with <code class="docutils literal notranslate"><span class="pre">(add</span> <span class="pre">R0,</span> <span class="pre">R1,</span> <span class="pre">...)</span></code>, more advanced set
+operators are available. See <code class="docutils literal notranslate"><span class="pre">include/llvm/Target/Target.td</span></code> for more
+information.</li>
+</ul>
+<p>In <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code>, three <code class="docutils literal notranslate"><span class="pre">RegisterClass</span></code> objects are defined:
+<code class="docutils literal notranslate"><span class="pre">FPRegs</span></code>, <code class="docutils literal notranslate"><span class="pre">DFPRegs</span></code>, and <code class="docutils literal notranslate"><span class="pre">IntRegs</span></code>. For all three register classes, the
+first argument defines the namespace with the string â<code class="docutils literal notranslate"><span class="pre">SP</span></code>â. <code class="docutils literal notranslate"><span class="pre">FPRegs</span></code>
+defines a group of 32 single-precision floating-point registers (<code class="docutils literal notranslate"><span class="pre">F0</span></code> to
+<code class="docutils literal notranslate"><span class="pre">F31</span></code>); <code class="docutils literal notranslate"><span class="pre">DFPRegs</span></code> defines a group of 16 double-precision registers
+(<code class="docutils literal notranslate"><span class="pre">D0-D15</span></code>).</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>// F0, F1, F2, ..., F31
+def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>;
+
+def DFPRegs : RegisterClass<"SP", [f64], 64,
+ (add D0, D1, D2, D3, D4, D5, D6, D7, D8,
+ D9, D10, D11, D12, D13, D14, D15)>;
+
+def IntRegs : RegisterClass<"SP", [i32], 32,
+ (add L0, L1, L2, L3, L4, L5, L6, L7,
+ I0, I1, I2, I3, I4, I5,
+ O0, O1, O2, O3, O4, O5, O7,
+ G1,
+ // Non-allocatable regs:
+ G2, G3, G4,
+ O6, // stack ptr
+ I6, // frame ptr
+ I7, // return address
+ G0, // constant zero
+ G5, G6, G7 // reserved for kernel
+ )>;
+</pre></div>
+</div>
+<p>Using <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code> with TableGen generates several output files
+that are intended for inclusion in other source code that you write.
+<code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code> generates <code class="docutils literal notranslate"><span class="pre">SparcGenRegisterInfo.h.inc</span></code>, which should
+be included in the header file for the implementation of the SPARC register
+implementation that you write (<code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.h</span></code>). In
+<code class="docutils literal notranslate"><span class="pre">SparcGenRegisterInfo.h.inc</span></code> a new structure is defined called
+<code class="docutils literal notranslate"><span class="pre">SparcGenRegisterInfo</span></code> that uses <code class="docutils literal notranslate"><span class="pre">TargetRegisterInfo</span></code> as its base. It also
+specifies types, based upon the defined register classes: <code class="docutils literal notranslate"><span class="pre">DFPRegsClass</span></code>,
+<code class="docutils literal notranslate"><span class="pre">FPRegsClass</span></code>, and <code class="docutils literal notranslate"><span class="pre">IntRegsClass</span></code>.</p>
+<p><code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.td</span></code> also generates <code class="docutils literal notranslate"><span class="pre">SparcGenRegisterInfo.inc</span></code>, which is
+included at the bottom of <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.cpp</span></code>, the SPARC register
+implementation. The code below shows only the generated integer registers and
+associated register classes. The order of registers in <code class="docutils literal notranslate"><span class="pre">IntRegs</span></code> reflects
+the order in the definition of <code class="docutils literal notranslate"><span class="pre">IntRegs</span></code> in the target description file.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="c1">// IntRegs Register Class...</span>
+<span class="k">static</span> <span class="k">const</span> <span class="kt">unsigned</span> <span class="n">IntRegs</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">L0</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L1</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L2</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L3</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L4</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L5</span><span class="p">,</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">L6</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">L7</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I0</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I1</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I2</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I3</span><span class="p">,</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">I4</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I5</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O0</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O1</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O2</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O3</span><span class="p">,</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">O4</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O5</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O7</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G1</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G2</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G3</span><span class="p">,</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">G4</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">O6</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I6</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">I7</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G0</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G5</span><span class="p">,</span>
+ <span class="n">SP</span><span class="o">::</span><span class="n">G6</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">G7</span><span class="p">,</span>
+<span class="p">};</span>
+
+<span class="c1">// IntRegsVTs Register Class Value Types...</span>
+<span class="k">static</span> <span class="k">const</span> <span class="n">MVT</span><span class="o">::</span><span class="n">ValueType</span> <span class="n">IntRegsVTs</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">Other</span>
+<span class="p">};</span>
+
+<span class="k">namespace</span> <span class="n">SP</span> <span class="p">{</span> <span class="c1">// Register class instances</span>
+ <span class="n">DFPRegsClass</span> <span class="n">DFPRegsRegClass</span><span class="p">;</span>
+ <span class="n">FPRegsClass</span> <span class="n">FPRegsRegClass</span><span class="p">;</span>
+ <span class="n">IntRegsClass</span> <span class="n">IntRegsRegClass</span><span class="p">;</span>
+<span class="p">...</span>
+ <span class="c1">// IntRegs Sub-register Classes...</span>
+ <span class="k">static</span> <span class="k">const</span> <span class="n">TargetRegisterClass</span><span class="o">*</span> <span class="k">const</span> <span class="n">IntRegsSubRegClasses</span> <span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="nb">NULL</span>
+ <span class="p">};</span>
+<span class="p">...</span>
+ <span class="c1">// IntRegs Super-register Classes..</span>
+ <span class="k">static</span> <span class="k">const</span> <span class="n">TargetRegisterClass</span><span class="o">*</span> <span class="k">const</span> <span class="n">IntRegsSuperRegClasses</span> <span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="nb">NULL</span>
+ <span class="p">};</span>
+<span class="p">...</span>
+ <span class="c1">// IntRegs Register Class sub-classes...</span>
+ <span class="k">static</span> <span class="k">const</span> <span class="n">TargetRegisterClass</span><span class="o">*</span> <span class="k">const</span> <span class="n">IntRegsSubclasses</span> <span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="nb">NULL</span>
+ <span class="p">};</span>
+<span class="p">...</span>
+ <span class="c1">// IntRegs Register Class super-classes...</span>
+ <span class="k">static</span> <span class="k">const</span> <span class="n">TargetRegisterClass</span><span class="o">*</span> <span class="k">const</span> <span class="n">IntRegsSuperclasses</span> <span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
+ <span class="nb">NULL</span>
+ <span class="p">};</span>
+
+ <span class="n">IntRegsClass</span><span class="o">::</span><span class="n">IntRegsClass</span><span class="p">()</span> <span class="o">:</span> <span class="n">TargetRegisterClass</span><span class="p">(</span><span class="n">IntRegsRegClassID</span><span class="p">,</span>
+ <span class="n">IntRegsVTs</span><span class="p">,</span> <span class="n">IntRegsSubclasses</span><span class="p">,</span> <span class="n">IntRegsSuperclasses</span><span class="p">,</span> <span class="n">IntRegsSubRegClasses</span><span class="p">,</span>
+ <span class="n">IntRegsSuperRegClasses</span><span class="p">,</span> <span class="mi">4</span><span class="p">,</span> <span class="mi">4</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">IntRegs</span><span class="p">,</span> <span class="n">IntRegs</span> <span class="o">+</span> <span class="mi">32</span><span class="p">)</span> <span class="p">{}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The register allocators will avoid using reserved registers, and callee saved
+registers are not used until all the volatile registers have been used. That
+is usually good enough, but in some cases it may be necessary to provide custom
+allocation orders.</p>
+</div>
+<div class="section" id="implement-a-subclass-of-targetregisterinfo">
+<h3><a class="toc-backref" href="#id13">Implement a subclass of <code class="docutils literal notranslate"><span class="pre">TargetRegisterInfo</span></code></a><a class="headerlink" href="#implement-a-subclass-of-targetregisterinfo" title="Permalink to this headline">¶</a></h3>
+<p>The final step is to hand code portions of <code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo</span></code>, which
+implements the interface described in <code class="docutils literal notranslate"><span class="pre">TargetRegisterInfo.h</span></code> (see
+<a class="reference internal" href="CodeGenerator.html#targetregisterinfo"><span class="std std-ref">The TargetRegisterInfo class</span></a>). These functions return <code class="docutils literal notranslate"><span class="pre">0</span></code>, <code class="docutils literal notranslate"><span class="pre">NULL</span></code>, or
+<code class="docutils literal notranslate"><span class="pre">false</span></code>, unless overridden. Here is a list of functions that are overridden
+for the SPARC implementation in <code class="docutils literal notranslate"><span class="pre">SparcRegisterInfo.cpp</span></code>:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">getCalleeSavedRegs</span></code> â Returns a list of callee-saved registers in the
+order of the desired callee-save stack frame offset.</li>
+<li><code class="docutils literal notranslate"><span class="pre">getReservedRegs</span></code> â Returns a bitset indexed by physical register
+numbers, indicating if a particular register is unavailable.</li>
+<li><code class="docutils literal notranslate"><span class="pre">hasFP</span></code> â Return a Boolean indicating if a function should have a
+dedicated frame pointer register.</li>
+<li><code class="docutils literal notranslate"><span class="pre">eliminateCallFramePseudoInstr</span></code> â If call frame setup or destroy pseudo
+instructions are used, this can be called to eliminate them.</li>
+<li><code class="docutils literal notranslate"><span class="pre">eliminateFrameIndex</span></code> â Eliminate abstract frame indices from
+instructions that may use them.</li>
+<li><code class="docutils literal notranslate"><span class="pre">emitPrologue</span></code> â Insert prologue code into the function.</li>
+<li><code class="docutils literal notranslate"><span class="pre">emitEpilogue</span></code> â Insert epilogue code into the function.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="instruction-set">
+<span id="id1"></span><h2><a class="toc-backref" href="#id14">Instruction Set</a><a class="headerlink" href="#instruction-set" title="Permalink to this headline">¶</a></h2>
+<p>During the early stages of code generation, the LLVM IR code is converted to a
+<code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> with nodes that are instances of the <code class="docutils literal notranslate"><span class="pre">SDNode</span></code> class
+containing target instructions. An <code class="docutils literal notranslate"><span class="pre">SDNode</span></code> has an opcode, operands, type
+requirements, and operation properties. For example, is an operation
+commutative, does an operation load from memory. The various operation node
+types are described in the <code class="docutils literal notranslate"><span class="pre">include/llvm/CodeGen/SelectionDAGNodes.h</span></code> file
+(values of the <code class="docutils literal notranslate"><span class="pre">NodeType</span></code> enum in the <code class="docutils literal notranslate"><span class="pre">ISD</span></code> namespace).</p>
+<p>TableGen uses the following target description (<code class="docutils literal notranslate"><span class="pre">.td</span></code>) input files to
+generate much of the code for instruction definition:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">Target.td</span></code> â Where the <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>, <code class="docutils literal notranslate"><span class="pre">Operand</span></code>, <code class="docutils literal notranslate"><span class="pre">InstrInfo</span></code>, and
+other fundamental classes are defined.</li>
+<li><code class="docutils literal notranslate"><span class="pre">TargetSelectionDAG.td</span></code> â Used by <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> instruction selection
+generators, contains <code class="docutils literal notranslate"><span class="pre">SDTC*</span></code> classes (selection DAG type constraint),
+definitions of <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> nodes (such as <code class="docutils literal notranslate"><span class="pre">imm</span></code>, <code class="docutils literal notranslate"><span class="pre">cond</span></code>, <code class="docutils literal notranslate"><span class="pre">bb</span></code>,
+<code class="docutils literal notranslate"><span class="pre">add</span></code>, <code class="docutils literal notranslate"><span class="pre">fadd</span></code>, <code class="docutils literal notranslate"><span class="pre">sub</span></code>), and pattern support (<code class="docutils literal notranslate"><span class="pre">Pattern</span></code>, <code class="docutils literal notranslate"><span class="pre">Pat</span></code>,
+<code class="docutils literal notranslate"><span class="pre">PatFrag</span></code>, <code class="docutils literal notranslate"><span class="pre">PatLeaf</span></code>, <code class="docutils literal notranslate"><span class="pre">ComplexPattern</span></code>.</li>
+<li><code class="docutils literal notranslate"><span class="pre">XXXInstrFormats.td</span></code> â Patterns for definitions of target-specific
+instructions.</li>
+<li><code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code> â Target-specific definitions of instruction templates,
+condition codes, and instructions of an instruction set. For architecture
+modifications, a different file name may be used. For example, for Pentium
+with SSE instruction, this file is <code class="docutils literal notranslate"><span class="pre">X86InstrSSE.td</span></code>, and for Pentium with
+MMX, this file is <code class="docutils literal notranslate"><span class="pre">X86InstrMMX.td</span></code>.</li>
+</ul>
+<p>There is also a target-specific <code class="docutils literal notranslate"><span class="pre">XXX.td</span></code> file, where <code class="docutils literal notranslate"><span class="pre">XXX</span></code> is the name of
+the target. The <code class="docutils literal notranslate"><span class="pre">XXX.td</span></code> file includes the other <code class="docutils literal notranslate"><span class="pre">.td</span></code> input files, but
+its contents are only directly important for subtargets.</p>
+<p>You should describe a concrete target-specific class <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo</span></code> that
+represents machine instructions supported by a target machine.
+<code class="docutils literal notranslate"><span class="pre">XXXInstrInfo</span></code> contains an array of <code class="docutils literal notranslate"><span class="pre">XXXInstrDescriptor</span></code> objects, each of
+which describes one instruction. An instruction descriptor defines:</p>
+<ul class="simple">
+<li>Opcode mnemonic</li>
+<li>Number of operands</li>
+<li>List of implicit register definitions and uses</li>
+<li>Target-independent properties (such as memory access, is commutable)</li>
+<li>Target-specific flags</li>
+</ul>
+<p>The Instruction class (defined in <code class="docutils literal notranslate"><span class="pre">Target.td</span></code>) is mostly used as a base for
+more complex instruction classes.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class Instruction {
+ string Namespace = "";
+ dag OutOperandList; // A dag containing the MI def operand list.
+ dag InOperandList; // A dag containing the MI use operand list.
+ string AsmString = ""; // The .s format to print the instruction with.
+ list<dag> Pattern; // Set to the DAG pattern for this instruction.
+ list<Register> Uses = [];
+ list<Register> Defs = [];
+ list<Predicate> Predicates = []; // predicates turned into isel match code
+ ... remainder not shown for space ...
+}
+</pre></div>
+</div>
+<p>A <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> node (<code class="docutils literal notranslate"><span class="pre">SDNode</span></code>) should contain an object representing a
+target-specific instruction that is defined in <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code>. The
+instruction objects should represent instructions from the architecture manual
+of the target machine (such as the SPARC Architecture Manual for the SPARC
+target).</p>
+<p>A single instruction from the architecture manual is often modeled as multiple
+target instructions, depending upon its operands. For example, a manual might
+describe an add instruction that takes a register or an immediate operand. An
+LLVM target could model this with two instructions named <code class="docutils literal notranslate"><span class="pre">ADDri</span></code> and
+<code class="docutils literal notranslate"><span class="pre">ADDrr</span></code>.</p>
+<p>You should define a class for each instruction category and define each opcode
+as a subclass of the category with appropriate parameters such as the fixed
+binary encoding of opcodes and extended opcodes. You should map the register
+bits to the bits of the instruction in which they are encoded (for the JIT).
+Also you should specify how the instruction should be printed when the
+automatic assembly printer is used.</p>
+<p>As is described in the SPARC Architecture Manual, Version 8, there are three
+major 32-bit formats for instructions. Format 1 is only for the <code class="docutils literal notranslate"><span class="pre">CALL</span></code>
+instruction. Format 2 is for branch on condition codes and <code class="docutils literal notranslate"><span class="pre">SETHI</span></code> (set high
+bits of a register) instructions. Format 3 is for other instructions.</p>
+<p>Each of these formats has corresponding classes in <code class="docutils literal notranslate"><span class="pre">SparcInstrFormat.td</span></code>.
+<code class="docutils literal notranslate"><span class="pre">InstSP</span></code> is a base class for other instruction classes. Additional base
+classes are specified for more precise formats: for example in
+<code class="docutils literal notranslate"><span class="pre">SparcInstrFormat.td</span></code>, <code class="docutils literal notranslate"><span class="pre">F2_1</span></code> is for <code class="docutils literal notranslate"><span class="pre">SETHI</span></code>, and <code class="docutils literal notranslate"><span class="pre">F2_2</span></code> is for
+branches. There are three other base classes: <code class="docutils literal notranslate"><span class="pre">F3_1</span></code> for register/register
+operations, <code class="docutils literal notranslate"><span class="pre">F3_2</span></code> for register/immediate operations, and <code class="docutils literal notranslate"><span class="pre">F3_3</span></code> for
+floating-point operations. <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code> also adds the base class
+<code class="docutils literal notranslate"><span class="pre">Pseudo</span></code> for synthetic SPARC instructions.</p>
+<p><code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code> largely consists of operand and instruction definitions
+for the SPARC target. In <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>, the following target
+description file entry, <code class="docutils literal notranslate"><span class="pre">LDrr</span></code>, defines the Load Integer instruction for a
+Word (the <code class="docutils literal notranslate"><span class="pre">LD</span></code> SPARC opcode) from a memory address to a register. The first
+parameter, the value 3 (<code class="docutils literal notranslate"><span class="pre">11</span></code><sub>2</sub>), is the operation value for this
+category of operation. The second parameter (<code class="docutils literal notranslate"><span class="pre">000000</span></code><sub>2</sub>) is the
+specific operation value for <code class="docutils literal notranslate"><span class="pre">LD</span></code>/Load Word. The third parameter is the
+output destination, which is a register operand and defined in the <code class="docutils literal notranslate"><span class="pre">Register</span></code>
+target description file (<code class="docutils literal notranslate"><span class="pre">IntRegs</span></code>).</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
+ "ld [$addr], $dst",
+ [(set i32:$dst, (load ADDRrr:$addr))]>;
+</pre></div>
+</div>
+<p>The fourth parameter is the input source, which uses the address operand
+<code class="docutils literal notranslate"><span class="pre">MEMrr</span></code> that is defined earlier in <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def MEMrr : Operand<i32> {
+ let PrintMethod = "printMemOperand";
+ let MIOperandInfo = (ops IntRegs, IntRegs);
+}
+</pre></div>
+</div>
+<p>The fifth parameter is a string that is used by the assembly printer and can be
+left as an empty string until the assembly printer interface is implemented.
+The sixth and final parameter is the pattern used to match the instruction
+during the SelectionDAG Select Phase described in <a class="reference internal" href="CodeGenerator.html"><span class="doc">The LLVM Target-Independent Code Generator</span></a>.
+This parameter is detailed in the next section, <a class="reference internal" href="#instruction-selector"><span class="std std-ref">Instruction Selector</span></a>.</p>
+<p>Instruction class definitions are not overloaded for different operand types,
+so separate versions of instructions are needed for register, memory, or
+immediate value operands. For example, to perform a Load Integer instruction
+for a Word from an immediate operand to a register, the following instruction
+class is defined:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
+ "ld [$addr], $dst",
+ [(set i32:$dst, (load ADDRri:$addr))]>;
+</pre></div>
+</div>
+<p>Writing these definitions for so many similar instructions can involve a lot of
+cut and paste. In <code class="docutils literal notranslate"><span class="pre">.td</span></code> files, the <code class="docutils literal notranslate"><span class="pre">multiclass</span></code> directive enables the
+creation of templates to define several instruction classes at once (using the
+<code class="docutils literal notranslate"><span class="pre">defm</span></code> directive). For example in <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>, the <code class="docutils literal notranslate"><span class="pre">multiclass</span></code>
+pattern <code class="docutils literal notranslate"><span class="pre">F3_12</span></code> is defined to create 2 instruction classes each time
+<code class="docutils literal notranslate"><span class="pre">F3_12</span></code> is invoked:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
+ def rr : F3_1 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set i32:$dst, (OpNode i32:$b, i32:$c))]>;
+ def ri : F3_2 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set i32:$dst, (OpNode i32:$b, simm13:$c))]>;
+}
+</pre></div>
+</div>
+<p>So when the <code class="docutils literal notranslate"><span class="pre">defm</span></code> directive is used for the <code class="docutils literal notranslate"><span class="pre">XOR</span></code> and <code class="docutils literal notranslate"><span class="pre">ADD</span></code>
+instructions, as seen below, it creates four instruction objects: <code class="docutils literal notranslate"><span class="pre">XORrr</span></code>,
+<code class="docutils literal notranslate"><span class="pre">XORri</span></code>, <code class="docutils literal notranslate"><span class="pre">ADDrr</span></code>, and <code class="docutils literal notranslate"><span class="pre">ADDri</span></code>.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>defm XOR : F3_12<"xor", 0b000011, xor>;
+defm ADD : F3_12<"add", 0b000000, add>;
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code> also includes definitions for condition codes that are
+referenced by branch instructions. The following definitions in
+<code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code> indicate the bit location of the SPARC condition code.
+For example, the 10<sup>th</sup> bit represents the âgreater thanâ condition for
+integers, and the 22<sup>nd</sup> bit represents the âgreater thanâ condition for
+floats.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def ICC_NE : ICC_VAL< 9>; // Not Equal
+def ICC_E : ICC_VAL< 1>; // Equal
+def ICC_G : ICC_VAL<10>; // Greater
+...
+def FCC_U : FCC_VAL<23>; // Unordered
+def FCC_G : FCC_VAL<22>; // Greater
+def FCC_UG : FCC_VAL<21>; // Unordered or Greater
+...
+</pre></div>
+</div>
+<p>(Note that <code class="docutils literal notranslate"><span class="pre">Sparc.h</span></code> also defines enums that correspond to the same SPARC
+condition codes. Care must be taken to ensure the values in <code class="docutils literal notranslate"><span class="pre">Sparc.h</span></code>
+correspond to the values in <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>. I.e., <code class="docutils literal notranslate"><span class="pre">SPCC::ICC_NE</span> <span class="pre">=</span> <span class="pre">9</span></code>,
+<code class="docutils literal notranslate"><span class="pre">SPCC::FCC_U</span> <span class="pre">=</span> <span class="pre">23</span></code> and so on.)</p>
+<div class="section" id="instruction-operand-mapping">
+<h3><a class="toc-backref" href="#id15">Instruction Operand Mapping</a><a class="headerlink" href="#instruction-operand-mapping" title="Permalink to this headline">¶</a></h3>
+<p>The code generator backend maps instruction operands to fields in the
+instruction. Operands are assigned to unbound fields in the instruction in the
+order they are defined. Fields are bound when they are assigned a value. For
+example, the Sparc target defines the <code class="docutils literal notranslate"><span class="pre">XNORrr</span></code> instruction as a <code class="docutils literal notranslate"><span class="pre">F3_1</span></code>
+format instruction having three operands.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def XNORrr : F3_1<2, 0b000111,
+ (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
+ "xnor $b, $c, $dst",
+ [(set i32:$dst, (not (xor i32:$b, i32:$c)))]>;
+</pre></div>
+</div>
+<p>The instruction templates in <code class="docutils literal notranslate"><span class="pre">SparcInstrFormats.td</span></code> show the base class for
+<code class="docutils literal notranslate"><span class="pre">F3_1</span></code> is <code class="docutils literal notranslate"><span class="pre">InstSP</span></code>.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
+ field bits<32> Inst;
+ let Namespace = "SP";
+ bits<2> op;
+ let Inst{31-30} = op;
+ dag OutOperandList = outs;
+ dag InOperandList = ins;
+ let AsmString = asmstr;
+ let Pattern = pattern;
+}
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">InstSP</span></code> leaves the <code class="docutils literal notranslate"><span class="pre">op</span></code> field unbound.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
+ : InstSP<outs, ins, asmstr, pattern> {
+ bits<5> rd;
+ bits<6> op3;
+ bits<5> rs1;
+ let op{1} = 1; // Op = 2 or 3
+ let Inst{29-25} = rd;
+ let Inst{24-19} = op3;
+ let Inst{18-14} = rs1;
+}
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">F3</span></code> binds the <code class="docutils literal notranslate"><span class="pre">op</span></code> field and defines the <code class="docutils literal notranslate"><span class="pre">rd</span></code>, <code class="docutils literal notranslate"><span class="pre">op3</span></code>, and <code class="docutils literal notranslate"><span class="pre">rs1</span></code>
+fields. <code class="docutils literal notranslate"><span class="pre">F3</span></code> format instructions will bind the operands <code class="docutils literal notranslate"><span class="pre">rd</span></code>, <code class="docutils literal notranslate"><span class="pre">op3</span></code>, and
+<code class="docutils literal notranslate"><span class="pre">rs1</span></code> fields.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
+ string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
+ bits<8> asi = 0; // asi not currently used
+ bits<5> rs2;
+ let op = opVal;
+ let op3 = op3val;
+ let Inst{13} = 0; // i field = 0
+ let Inst{12-5} = asi; // address space identifier
+ let Inst{4-0} = rs2;
+}
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">F3_1</span></code> binds the <code class="docutils literal notranslate"><span class="pre">op3</span></code> field and defines the <code class="docutils literal notranslate"><span class="pre">rs2</span></code> fields. <code class="docutils literal notranslate"><span class="pre">F3_1</span></code>
+format instructions will bind the operands to the <code class="docutils literal notranslate"><span class="pre">rd</span></code>, <code class="docutils literal notranslate"><span class="pre">rs1</span></code>, and <code class="docutils literal notranslate"><span class="pre">rs2</span></code>
+fields. This results in the <code class="docutils literal notranslate"><span class="pre">XNORrr</span></code> instruction binding <code class="docutils literal notranslate"><span class="pre">$dst</span></code>, <code class="docutils literal notranslate"><span class="pre">$b</span></code>,
+and <code class="docutils literal notranslate"><span class="pre">$c</span></code> operands to the <code class="docutils literal notranslate"><span class="pre">rd</span></code>, <code class="docutils literal notranslate"><span class="pre">rs1</span></code>, and <code class="docutils literal notranslate"><span class="pre">rs2</span></code> fields respectively.</p>
+<div class="section" id="instruction-operand-name-mapping">
+<h4><a class="toc-backref" href="#id16">Instruction Operand Name Mapping</a><a class="headerlink" href="#instruction-operand-name-mapping" title="Permalink to this headline">¶</a></h4>
+<p>TableGen will also generate a function called getNamedOperandIdx() which
+can be used to look up an operandâs index in a MachineInstr based on its
+TableGen name. Setting the UseNamedOperandTable bit in an instructionâs
+TableGen definition will add all of its operands to an enumeration in the
+llvm::XXX:OpName namespace and also add an entry for it into the OperandMap
+table, which can be queried using getNamedOperandIdx()</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); // => 0
+int BIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::b); // => 1
+int CIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::c); // => 2
+int DIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::d); // => -1
+
+...
+</pre></div>
+</div>
+<p>The entries in the OpName enum are taken verbatim from the TableGen definitions,
+so operands with lowercase names will have lower case entries in the enum.</p>
+<p>To include the getNamedOperandIdx() function in your backend, you will need
+to define a few preprocessor macros in XXXInstrInfo.cpp and XXXInstrInfo.h.
+For example:</p>
+<p>XXXInstrInfo.cpp:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#define GET_INSTRINFO_NAMED_OPS </span><span class="c1">// For getNamedOperandIdx() function</span>
+<span class="cp">#include</span> <span class="cpf">"XXXGenInstrInfo.inc"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>XXXInstrInfo.h:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#define GET_INSTRINFO_OPERAND_ENUM </span><span class="c1">// For OpName enum</span>
+<span class="cp">#include</span> <span class="cpf">"XXXGenInstrInfo.inc"</span><span class="cp"></span>
+
+<span class="k">namespace</span> <span class="n">XXX</span> <span class="p">{</span>
+ <span class="kt">int16_t</span> <span class="n">getNamedOperandIdx</span><span class="p">(</span><span class="kt">uint16_t</span> <span class="n">Opcode</span><span class="p">,</span> <span class="kt">uint16_t</span> <span class="n">NamedIndex</span><span class="p">);</span>
+<span class="p">}</span> <span class="c1">// End namespace XXX</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="instruction-operand-types">
+<h4><a class="toc-backref" href="#id17">Instruction Operand Types</a><a class="headerlink" href="#instruction-operand-types" title="Permalink to this headline">¶</a></h4>
+<p>TableGen will also generate an enumeration consisting of all named Operand
+types defined in the backend, in the llvm::XXX::OpTypes namespace.
+Some common immediate Operand types (for instance i8, i32, i64, f32, f64)
+are defined for all targets in <code class="docutils literal notranslate"><span class="pre">include/llvm/Target/Target.td</span></code>, and are
+available in each Targetâs OpTypes enum. Also, only named Operand types appear
+in the enumeration: anonymous types are ignored.
+For example, the X86 backend defines <code class="docutils literal notranslate"><span class="pre">brtarget</span></code> and <code class="docutils literal notranslate"><span class="pre">brtarget8</span></code>, both
+instances of the TableGen <code class="docutils literal notranslate"><span class="pre">Operand</span></code> class, which represent branch target
+operands:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def brtarget : Operand<OtherVT>;
+def brtarget8 : Operand<OtherVT>;
+</pre></div>
+</div>
+<p>This results in:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">namespace</span> <span class="n">X86</span> <span class="p">{</span>
+<span class="k">namespace</span> <span class="n">OpTypes</span> <span class="p">{</span>
+<span class="k">enum</span> <span class="n">OperandType</span> <span class="p">{</span>
+ <span class="p">...</span>
+ <span class="n">brtarget</span><span class="p">,</span>
+ <span class="n">brtarget8</span><span class="p">,</span>
+ <span class="p">...</span>
+ <span class="n">i32imm</span><span class="p">,</span>
+ <span class="n">i64imm</span><span class="p">,</span>
+ <span class="p">...</span>
+ <span class="n">OPERAND_TYPE_LIST_END</span>
+<span class="p">}</span> <span class="c1">// End namespace OpTypes</span>
+<span class="p">}</span> <span class="c1">// End namespace X86</span>
+</pre></div>
+</div>
+<p>In typical TableGen fashion, to use the enum, you will need to define a
+preprocessor macro:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#define GET_INSTRINFO_OPERAND_TYPES_ENUM </span><span class="c1">// For OpTypes enum</span>
+<span class="cp">#include</span> <span class="cpf">"XXXGenInstrInfo.inc"</span><span class="cp"></span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="instruction-scheduling">
+<h3><a class="toc-backref" href="#id18">Instruction Scheduling</a><a class="headerlink" href="#instruction-scheduling" title="Permalink to this headline">¶</a></h3>
+<p>Instruction itineraries can be queried using MCDesc::getSchedClass(). The
+value can be named by an enumeration in llvm::XXX::Sched namespace generated
+by TableGen in XXXGenInstrInfo.inc. The name of the schedule classes are
+the same as provided in XXXSchedule.td plus a default NoItinerary class.</p>
+<p>The schedule models are generated by TableGen by the SubtargetEmitter,
+using the <code class="docutils literal notranslate"><span class="pre">CodeGenSchedModels</span></code> class. This is distinct from the itinerary
+method of specifying machine resource use. The tool <code class="docutils literal notranslate"><span class="pre">utils/schedcover.py</span></code>
+can be used to determine which instructions have been covered by the
+schedule model description and which havenât. The first step is to use the
+instructions below to create an output file. Then run <code class="docutils literal notranslate"><span class="pre">schedcover.py</span></code> on the
+output file:</p>
+<div class="highlight-shell notranslate"><div class="highlight"><pre><span></span>$ <src>/utils/schedcover.py <build>/lib/Target/AArch64/tblGenSubtarget.with
+instruction, default, CortexA53Model, CortexA57Model, CycloneModel, ExynosM1Model, FalkorModel, KryoModel, ThunderX2T99Model, ThunderXT8XModel
+ABSv16i8, WriteV, , , CyWriteV3, M1WriteNMISC1, FalkorWr_2VXVY_2cyc, KryoWrite_2cyc_XY_XY_150ln, ,
+ABSv1i64, WriteV, , , CyWriteV3, M1WriteNMISC1, FalkorWr_1VXVY_2cyc, KryoWrite_2cyc_XY_noRSV_67ln, ,
+...
+</pre></div>
+</div>
+<p>To capture the debug output from generating a schedule model, change to the
+appropriate target directory and use the following command:
+command with the <code class="docutils literal notranslate"><span class="pre">subtarget-emitter</span></code> debug option:</p>
+<div class="highlight-shell notranslate"><div class="highlight"><pre><span></span>$ <build>/bin/llvm-tblgen -debug-only<span class="o">=</span>subtarget-emitter -gen-subtarget <span class="se">\</span>
+ -I <src>/lib/Target/<target> -I <src>/include <span class="se">\</span>
+ -I <src>/lib/Target <src>/lib/Target/<target>/<target>.td <span class="se">\</span>
+ -o <build>/lib/Target/<target>/<target>GenSubtargetInfo.inc.tmp <span class="se">\</span>
+ > tblGenSubtarget.dbg <span class="m">2</span>><span class="p">&</span><span class="m">1</span>
+</pre></div>
+</div>
+<p>Where <code class="docutils literal notranslate"><span class="pre"><build></span></code> is the build directory, <code class="docutils literal notranslate"><span class="pre">src</span></code> is the source directory,
+and <code class="docutils literal notranslate"><span class="pre"><target></span></code> is the name of the target.
+To double check that the above command is what is needed, one can capture the
+exact TableGen command from a build by using:</p>
+<div class="highlight-shell notranslate"><div class="highlight"><pre><span></span>$ <span class="nv">VERBOSE</span><span class="o">=</span><span class="m">1</span> make ...
+</pre></div>
+</div>
+<p>and search for <code class="docutils literal notranslate"><span class="pre">llvm-tblgen</span></code> commands in the output.</p>
+</div>
+<div class="section" id="instruction-relation-mapping">
+<h3><a class="toc-backref" href="#id19">Instruction Relation Mapping</a><a class="headerlink" href="#instruction-relation-mapping" title="Permalink to this headline">¶</a></h3>
+<p>This TableGen feature is used to relate instructions with each other. It is
+particularly useful when you have multiple instruction formats and need to
+switch between them after instruction selection. This entire feature is driven
+by relation models which can be defined in <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code> files
+according to the target-specific instruction set. Relation models are defined
+using <code class="docutils literal notranslate"><span class="pre">InstrMapping</span></code> class as a base. TableGen parses all the models
+and generates instruction relation maps using the specified information.
+Relation maps are emitted as tables in the <code class="docutils literal notranslate"><span class="pre">XXXGenInstrInfo.inc</span></code> file
+along with the functions to query them. For the detailed information on how to
+use this feature, please refer to <a class="reference internal" href="HowToUseInstrMappings.html"><span class="doc">How To Use Instruction Mappings</span></a>.</p>
+</div>
+<div class="section" id="implement-a-subclass-of-targetinstrinfo">
+<h3><a class="toc-backref" href="#id20">Implement a subclass of <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo</span></code></a><a class="headerlink" href="#implement-a-subclass-of-targetinstrinfo" title="Permalink to this headline">¶</a></h3>
+<p>The final step is to hand code portions of <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo</span></code>, which implements
+the interface described in <code class="docutils literal notranslate"><span class="pre">TargetInstrInfo.h</span></code> (see <a class="reference internal" href="CodeGenerator.html#targetinstrinfo"><span class="std std-ref">The TargetInstrInfo class</span></a>).
+These functions return <code class="docutils literal notranslate"><span class="pre">0</span></code> or a Boolean or they assert, unless overridden.
+Hereâs a list of functions that are overridden for the SPARC implementation in
+<code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.cpp</span></code>:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">isLoadFromStackSlot</span></code> â If the specified machine instruction is a direct
+load from a stack slot, return the register number of the destination and the
+<code class="docutils literal notranslate"><span class="pre">FrameIndex</span></code> of the stack slot.</li>
+<li><code class="docutils literal notranslate"><span class="pre">isStoreToStackSlot</span></code> â If the specified machine instruction is a direct
+store to a stack slot, return the register number of the destination and the
+<code class="docutils literal notranslate"><span class="pre">FrameIndex</span></code> of the stack slot.</li>
+<li><code class="docutils literal notranslate"><span class="pre">copyPhysReg</span></code> â Copy values between a pair of physical registers.</li>
+<li><code class="docutils literal notranslate"><span class="pre">storeRegToStackSlot</span></code> â Store a register value to a stack slot.</li>
+<li><code class="docutils literal notranslate"><span class="pre">loadRegFromStackSlot</span></code> â Load a register value from a stack slot.</li>
+<li><code class="docutils literal notranslate"><span class="pre">storeRegToAddr</span></code> â Store a register value to memory.</li>
+<li><code class="docutils literal notranslate"><span class="pre">loadRegFromAddr</span></code> â Load a register value from memory.</li>
+<li><code class="docutils literal notranslate"><span class="pre">foldMemoryOperand</span></code> â Attempt to combine instructions of any load or
+store instruction for the specified operand(s).</li>
+</ul>
+</div>
+<div class="section" id="branch-folding-and-if-conversion">
+<h3><a class="toc-backref" href="#id21">Branch Folding and If Conversion</a><a class="headerlink" href="#branch-folding-and-if-conversion" title="Permalink to this headline">¶</a></h3>
+<p>Performance can be improved by combining instructions or by eliminating
+instructions that are never reached. The <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> method in
+<code class="docutils literal notranslate"><span class="pre">XXXInstrInfo</span></code> may be implemented to examine conditional instructions and
+remove unnecessary instructions. <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> looks at the end of a
+machine basic block (MBB) for opportunities for improvement, such as branch
+folding and if conversion. The <code class="docutils literal notranslate"><span class="pre">BranchFolder</span></code> and <code class="docutils literal notranslate"><span class="pre">IfConverter</span></code> machine
+function passes (see the source files <code class="docutils literal notranslate"><span class="pre">BranchFolding.cpp</span></code> and
+<code class="docutils literal notranslate"><span class="pre">IfConversion.cpp</span></code> in the <code class="docutils literal notranslate"><span class="pre">lib/CodeGen</span></code> directory) call <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code>
+to improve the control flow graph that represents the instructions.</p>
+<p>Several implementations of <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> (for ARM, Alpha, and X86) can be
+examined as models for your own <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> implementation. Since SPARC
+does not implement a useful <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code>, the ARM target implementation is
+shown below.</p>
+<p><code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> returns a Boolean value and takes four parameters:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">MachineBasicBlock</span> <span class="pre">&MBB</span></code> â The incoming block to be examined.</li>
+<li><code class="docutils literal notranslate"><span class="pre">MachineBasicBlock</span> <span class="pre">*&TBB</span></code> â A destination block that is returned. For a
+conditional branch that evaluates to true, <code class="docutils literal notranslate"><span class="pre">TBB</span></code> is the destination.</li>
+<li><code class="docutils literal notranslate"><span class="pre">MachineBasicBlock</span> <span class="pre">*&FBB</span></code> â For a conditional branch that evaluates to
+false, <code class="docutils literal notranslate"><span class="pre">FBB</span></code> is returned as the destination.</li>
+<li><code class="docutils literal notranslate"><span class="pre">std::vector<MachineOperand></span> <span class="pre">&Cond</span></code> â List of operands to evaluate a
+condition for a conditional branch.</li>
+</ul>
+<p>In the simplest case, if a block ends without a branch, then it falls through
+to the successor block. No destination blocks are specified for either <code class="docutils literal notranslate"><span class="pre">TBB</span></code>
+or <code class="docutils literal notranslate"><span class="pre">FBB</span></code>, so both parameters return <code class="docutils literal notranslate"><span class="pre">NULL</span></code>. The start of the
+<code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> (see code below for the ARM target) shows the function
+parameters and the code for the simplest case.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">bool</span> <span class="n">ARMInstrInfo</span><span class="o">::</span><span class="n">AnalyzeBranch</span><span class="p">(</span><span class="n">MachineBasicBlock</span> <span class="o">&</span><span class="n">MBB</span><span class="p">,</span>
+ <span class="n">MachineBasicBlock</span> <span class="o">*&</span><span class="n">TBB</span><span class="p">,</span>
+ <span class="n">MachineBasicBlock</span> <span class="o">*&</span><span class="n">FBB</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="n">MachineOperand</span><span class="o">></span> <span class="o">&</span><span class="n">Cond</span><span class="p">)</span> <span class="k">const</span>
+<span class="p">{</span>
+ <span class="n">MachineBasicBlock</span><span class="o">::</span><span class="n">iterator</span> <span class="n">I</span> <span class="o">=</span> <span class="n">MBB</span><span class="p">.</span><span class="n">end</span><span class="p">();</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">I</span> <span class="o">==</span> <span class="n">MBB</span><span class="p">.</span><span class="n">begin</span><span class="p">()</span> <span class="o">||</span> <span class="o">!</span><span class="n">isUnpredicatedTerminator</span><span class="p">(</span><span class="o">--</span><span class="n">I</span><span class="p">))</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>If a block ends with a single unconditional branch instruction, then
+<code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> (shown below) should return the destination of that branch in
+the <code class="docutils literal notranslate"><span class="pre">TBB</span></code> parameter.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">B</span> <span class="o">||</span> <span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tB</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">TBB</span> <span class="o">=</span> <span class="n">LastInst</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">getMBB</span><span class="p">();</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>If a block ends with two unconditional branches, then the second branch is
+never reached. In that situation, as shown below, remove the last branch
+instruction and return the penultimate branch in the <code class="docutils literal notranslate"><span class="pre">TBB</span></code> parameter.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">((</span><span class="n">SecondLastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">B</span> <span class="o">||</span> <span class="n">SecondLastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tB</span><span class="p">)</span> <span class="o">&&</span>
+ <span class="p">(</span><span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">B</span> <span class="o">||</span> <span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tB</span><span class="p">))</span> <span class="p">{</span>
+ <span class="n">TBB</span> <span class="o">=</span> <span class="n">SecondLastInst</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">getMBB</span><span class="p">();</span>
+ <span class="n">I</span> <span class="o">=</span> <span class="n">LastInst</span><span class="p">;</span>
+ <span class="n">I</span><span class="o">-></span><span class="n">eraseFromParent</span><span class="p">();</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>A block may end with a single conditional branch instruction that falls through
+to successor block if the condition evaluates to false. In that case,
+<code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> (shown below) should return the destination of that
+conditional branch in the <code class="docutils literal notranslate"><span class="pre">TBB</span></code> parameter and a list of operands in the
+<code class="docutils literal notranslate"><span class="pre">Cond</span></code> parameter to evaluate the condition.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">Bcc</span> <span class="o">||</span> <span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tBcc</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// Block ends with fall-through condbranch.</span>
+ <span class="n">TBB</span> <span class="o">=</span> <span class="n">LastInst</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">getMBB</span><span class="p">();</span>
+ <span class="n">Cond</span><span class="p">.</span><span class="n">push_back</span><span class="p">(</span><span class="n">LastInst</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="n">Cond</span><span class="p">.</span><span class="n">push_back</span><span class="p">(</span><span class="n">LastInst</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">2</span><span class="p">));</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>If a block ends with both a conditional branch and an ensuing unconditional
+branch, then <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> (shown below) should return the conditional
+branch destination (assuming it corresponds to a conditional evaluation of
+â<code class="docutils literal notranslate"><span class="pre">true</span></code>â) in the <code class="docutils literal notranslate"><span class="pre">TBB</span></code> parameter and the unconditional branch destination
+in the <code class="docutils literal notranslate"><span class="pre">FBB</span></code> (corresponding to a conditional evaluation of â<code class="docutils literal notranslate"><span class="pre">false</span></code>â). A
+list of operands to evaluate the condition should be returned in the <code class="docutils literal notranslate"><span class="pre">Cond</span></code>
+parameter.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">unsigned</span> <span class="n">SecondLastOpc</span> <span class="o">=</span> <span class="n">SecondLastInst</span><span class="o">-></span><span class="n">getOpcode</span><span class="p">();</span>
+
+<span class="k">if</span> <span class="p">((</span><span class="n">SecondLastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">Bcc</span> <span class="o">&&</span> <span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">B</span><span class="p">)</span> <span class="o">||</span>
+ <span class="p">(</span><span class="n">SecondLastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tBcc</span> <span class="o">&&</span> <span class="n">LastOpc</span> <span class="o">==</span> <span class="n">ARM</span><span class="o">::</span><span class="n">tB</span><span class="p">))</span> <span class="p">{</span>
+ <span class="n">TBB</span> <span class="o">=</span> <span class="n">SecondLastInst</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">getMBB</span><span class="p">();</span>
+ <span class="n">Cond</span><span class="p">.</span><span class="n">push_back</span><span class="p">(</span><span class="n">SecondLastInst</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="n">Cond</span><span class="p">.</span><span class="n">push_back</span><span class="p">(</span><span class="n">SecondLastInst</span><span class="o">-></span><span class="n">getOperand</span><span class="p">(</span><span class="mi">2</span><span class="p">));</span>
+ <span class="n">FBB</span> <span class="o">=</span> <span class="n">LastInst</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">getMBB</span><span class="p">();</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>For the last two cases (ending with a single conditional branch or ending with
+one conditional and one unconditional branch), the operands returned in the
+<code class="docutils literal notranslate"><span class="pre">Cond</span></code> parameter can be passed to methods of other instructions to create new
+branches or perform other operations. An implementation of <code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code>
+requires the helper methods <code class="docutils literal notranslate"><span class="pre">RemoveBranch</span></code> and <code class="docutils literal notranslate"><span class="pre">InsertBranch</span></code> to manage
+subsequent operations.</p>
+<p><code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> should return false indicating success in most circumstances.
+<code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> should only return true when the method is stumped about what
+to do, for example, if a block has three terminating branches.
+<code class="docutils literal notranslate"><span class="pre">AnalyzeBranch</span></code> may return true if it encounters a terminator it cannot
+handle, such as an indirect branch.</p>
+</div>
+</div>
+<div class="section" id="instruction-selector">
+<span id="id2"></span><h2><a class="toc-backref" href="#id22">Instruction Selector</a><a class="headerlink" href="#instruction-selector" title="Permalink to this headline">¶</a></h2>
+<p>LLVM uses a <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> to represent LLVM IR instructions, and nodes of
+the <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> ideally represent native target instructions. During code
+generation, instruction selection passes are performed to convert non-native
+DAG instructions into native target-specific instructions. The pass described
+in <code class="docutils literal notranslate"><span class="pre">XXXISelDAGToDAG.cpp</span></code> is used to match patterns and perform DAG-to-DAG
+instruction selection. Optionally, a pass may be defined (in
+<code class="docutils literal notranslate"><span class="pre">XXXBranchSelector.cpp</span></code>) to perform similar DAG-to-DAG operations for branch
+instructions. Later, the code in <code class="docutils literal notranslate"><span class="pre">XXXISelLowering.cpp</span></code> replaces or removes
+operations and data types not supported natively (legalizes) in a
+<code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code>.</p>
+<p>TableGen generates code for instruction selection using the following target
+description input files:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code> â Contains definitions of instructions in a
+target-specific instruction set, generates <code class="docutils literal notranslate"><span class="pre">XXXGenDAGISel.inc</span></code>, which is
+included in <code class="docutils literal notranslate"><span class="pre">XXXISelDAGToDAG.cpp</span></code>.</li>
+<li><code class="docutils literal notranslate"><span class="pre">XXXCallingConv.td</span></code> â Contains the calling and return value conventions
+for the target architecture, and it generates <code class="docutils literal notranslate"><span class="pre">XXXGenCallingConv.inc</span></code>,
+which is included in <code class="docutils literal notranslate"><span class="pre">XXXISelLowering.cpp</span></code>.</li>
+</ul>
+<p>The implementation of an instruction selection pass must include a header that
+declares the <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> class or a subclass of <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>. In
+<code class="docutils literal notranslate"><span class="pre">XXXTargetMachine.cpp</span></code>, a Pass Manager (PM) should add each instruction
+selection pass into the queue of passes to run.</p>
+<p>The LLVM static compiler (<code class="docutils literal notranslate"><span class="pre">llc</span></code>) is an excellent tool for visualizing the
+contents of DAGs. To display the <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> before or after specific
+processing phases, use the command line options for <code class="docutils literal notranslate"><span class="pre">llc</span></code>, described at
+<a class="reference internal" href="CodeGenerator.html#selectiondag-process"><span class="std std-ref">SelectionDAG Instruction Selection Process</span></a>.</p>
+<p>To describe instruction selector behavior, you should add patterns for lowering
+LLVM code into a <code class="docutils literal notranslate"><span class="pre">SelectionDAG</span></code> as the last parameter of the instruction
+definitions in <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code>. For example, in <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>,
+this entry defines a register store operation, and the last parameter describes
+a pattern with the store DAG operator.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
+ "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>;
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">ADDRrr</span></code> is a memory mode that is also defined in <code class="docutils literal notranslate"><span class="pre">SparcInstrInfo.td</span></code>:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
+</pre></div>
+</div>
+<p>The definition of <code class="docutils literal notranslate"><span class="pre">ADDRrr</span></code> refers to <code class="docutils literal notranslate"><span class="pre">SelectADDRrr</span></code>, which is a function
+defined in an implementation of the Instructor Selector (such as
+<code class="docutils literal notranslate"><span class="pre">SparcISelDAGToDAG.cpp</span></code>).</p>
+<p>In <code class="docutils literal notranslate"><span class="pre">lib/Target/TargetSelectionDAG.td</span></code>, the DAG operator for store is defined
+below:</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def store : PatFrag<(ops node:$val, node:$ptr),
+ (st node:$val, node:$ptr), [{
+ if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N))
+ return !ST->isTruncatingStore() &&
+ ST->getAddressingMode() == ISD::UNINDEXED;
+ return false;
+}]>;
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code> also generates (in <code class="docutils literal notranslate"><span class="pre">XXXGenDAGISel.inc</span></code>) the
+<code class="docutils literal notranslate"><span class="pre">SelectCode</span></code> method that is used to call the appropriate processing method
+for an instruction. In this example, <code class="docutils literal notranslate"><span class="pre">SelectCode</span></code> calls <code class="docutils literal notranslate"><span class="pre">Select_ISD_STORE</span></code>
+for the <code class="docutils literal notranslate"><span class="pre">ISD::STORE</span></code> opcode.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">SDNode</span> <span class="o">*</span><span class="nf">SelectCode</span><span class="p">(</span><span class="n">SDValue</span> <span class="n">N</span><span class="p">)</span> <span class="p">{</span>
+ <span class="p">...</span>
+ <span class="n">MVT</span><span class="o">::</span><span class="n">ValueType</span> <span class="n">NVT</span> <span class="o">=</span> <span class="n">N</span><span class="p">.</span><span class="n">getNode</span><span class="p">()</span><span class="o">-></span><span class="n">getValueType</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+ <span class="k">switch</span> <span class="p">(</span><span class="n">N</span><span class="p">.</span><span class="n">getOpcode</span><span class="p">())</span> <span class="p">{</span>
+ <span class="k">case</span> <span class="n">ISD</span><span class="o">::</span><span class="nl">STORE</span><span class="p">:</span> <span class="p">{</span>
+ <span class="k">switch</span> <span class="p">(</span><span class="n">NVT</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">default</span><span class="o">:</span>
+ <span class="k">return</span> <span class="n">Select_ISD_STORE</span><span class="p">(</span><span class="n">N</span><span class="p">);</span>
+ <span class="k">break</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="k">break</span><span class="p">;</span>
+ <span class="p">}</span>
+ <span class="p">...</span>
+</pre></div>
+</div>
+<p>The pattern for <code class="docutils literal notranslate"><span class="pre">STrr</span></code> is matched, so elsewhere in <code class="docutils literal notranslate"><span class="pre">XXXGenDAGISel.inc</span></code>,
+code for <code class="docutils literal notranslate"><span class="pre">STrr</span></code> is created for <code class="docutils literal notranslate"><span class="pre">Select_ISD_STORE</span></code>. The <code class="docutils literal notranslate"><span class="pre">Emit_22</span></code> method
+is also generated in <code class="docutils literal notranslate"><span class="pre">XXXGenDAGISel.inc</span></code> to complete the processing of this
+instruction.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">SDNode</span> <span class="o">*</span><span class="nf">Select_ISD_STORE</span><span class="p">(</span><span class="k">const</span> <span class="n">SDValue</span> <span class="o">&</span><span class="n">N</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">SDValue</span> <span class="n">Chain</span> <span class="o">=</span> <span class="n">N</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Predicate_store</span><span class="p">(</span><span class="n">N</span><span class="p">.</span><span class="n">getNode</span><span class="p">()))</span> <span class="p">{</span>
+ <span class="n">SDValue</span> <span class="n">N1</span> <span class="o">=</span> <span class="n">N</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
+ <span class="n">SDValue</span> <span class="n">N2</span> <span class="o">=</span> <span class="n">N</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="mi">2</span><span class="p">);</span>
+ <span class="n">SDValue</span> <span class="n">CPTmp0</span><span class="p">;</span>
+ <span class="n">SDValue</span> <span class="n">CPTmp1</span><span class="p">;</span>
+
+ <span class="c1">// Pattern: (st:void i32:i32:$src,</span>
+ <span class="c1">// ADDRrr:i32:$addr)<<P:Predicate_store>></span>
+ <span class="c1">// Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)</span>
+ <span class="c1">// Pattern complexity = 13 cost = 1 size = 0</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">SelectADDRrr</span><span class="p">(</span><span class="n">N</span><span class="p">,</span> <span class="n">N2</span><span class="p">,</span> <span class="n">CPTmp0</span><span class="p">,</span> <span class="n">CPTmp1</span><span class="p">)</span> <span class="o">&&</span>
+ <span class="n">N1</span><span class="p">.</span><span class="n">getNode</span><span class="p">()</span><span class="o">-></span><span class="n">getValueType</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="o">==</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span> <span class="o">&&</span>
+ <span class="n">N2</span><span class="p">.</span><span class="n">getNode</span><span class="p">()</span><span class="o">-></span><span class="n">getValueType</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="o">==</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">Emit_22</span><span class="p">(</span><span class="n">N</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">STrr</span><span class="p">,</span> <span class="n">CPTmp0</span><span class="p">,</span> <span class="n">CPTmp1</span><span class="p">);</span>
+ <span class="p">}</span>
+<span class="p">...</span>
+</pre></div>
+</div>
+<div class="section" id="the-selectiondag-legalize-phase">
+<h3><a class="toc-backref" href="#id23">The SelectionDAG Legalize Phase</a><a class="headerlink" href="#the-selectiondag-legalize-phase" title="Permalink to this headline">¶</a></h3>
+<p>The Legalize phase converts a DAG to use types and operations that are natively
+supported by the target. For natively unsupported types and operations, you
+need to add code to the target-specific <code class="docutils literal notranslate"><span class="pre">XXXTargetLowering</span></code> implementation to
+convert unsupported types and operations to supported ones.</p>
+<p>In the constructor for the <code class="docutils literal notranslate"><span class="pre">XXXTargetLowering</span></code> class, first use the
+<code class="docutils literal notranslate"><span class="pre">addRegisterClass</span></code> method to specify which types are supported and which
+register classes are associated with them. The code for the register classes
+are generated by TableGen from <code class="docutils literal notranslate"><span class="pre">XXXRegisterInfo.td</span></code> and placed in
+<code class="docutils literal notranslate"><span class="pre">XXXGenRegisterInfo.h.inc</span></code>. For example, the implementation of the
+constructor for the SparcTargetLowering class (in <code class="docutils literal notranslate"><span class="pre">SparcISelLowering.cpp</span></code>)
+starts with the following code:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">addRegisterClass</span><span class="p">(</span><span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">IntRegsRegisterClass</span><span class="p">);</span>
+<span class="n">addRegisterClass</span><span class="p">(</span><span class="n">MVT</span><span class="o">::</span><span class="n">f32</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">FPRegsRegisterClass</span><span class="p">);</span>
+<span class="n">addRegisterClass</span><span class="p">(</span><span class="n">MVT</span><span class="o">::</span><span class="n">f64</span><span class="p">,</span> <span class="n">SP</span><span class="o">::</span><span class="n">DFPRegsRegisterClass</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>You should examine the node types in the <code class="docutils literal notranslate"><span class="pre">ISD</span></code> namespace
+(<code class="docutils literal notranslate"><span class="pre">include/llvm/CodeGen/SelectionDAGNodes.h</span></code>) and determine which operations
+the target natively supports. For operations that do <strong>not</strong> have native
+support, add a callback to the constructor for the <code class="docutils literal notranslate"><span class="pre">XXXTargetLowering</span></code> class,
+so the instruction selection process knows what to do. The <code class="docutils literal notranslate"><span class="pre">TargetLowering</span></code>
+class callback methods (declared in <code class="docutils literal notranslate"><span class="pre">llvm/Target/TargetLowering.h</span></code>) are:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">setOperationAction</span></code> â General operation.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setLoadExtAction</span></code> â Load with extension.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setTruncStoreAction</span></code> â Truncating store.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setIndexedLoadAction</span></code> â Indexed load.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setIndexedStoreAction</span></code> â Indexed store.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setConvertAction</span></code> â Type conversion.</li>
+<li><code class="docutils literal notranslate"><span class="pre">setCondCodeAction</span></code> â Support for a given condition code.</li>
+</ul>
+<p>Note: on older releases, <code class="docutils literal notranslate"><span class="pre">setLoadXAction</span></code> is used instead of
+<code class="docutils literal notranslate"><span class="pre">setLoadExtAction</span></code>. Also, on older releases, <code class="docutils literal notranslate"><span class="pre">setCondCodeAction</span></code> may not
+be supported. Examine your release to see what methods are specifically
+supported.</p>
+<p>These callbacks are used to determine that an operation does or does not work
+with a specified type (or types). And in all cases, the third parameter is a
+<code class="docutils literal notranslate"><span class="pre">LegalAction</span></code> type enum value: <code class="docutils literal notranslate"><span class="pre">Promote</span></code>, <code class="docutils literal notranslate"><span class="pre">Expand</span></code>, <code class="docutils literal notranslate"><span class="pre">Custom</span></code>, or
+<code class="docutils literal notranslate"><span class="pre">Legal</span></code>. <code class="docutils literal notranslate"><span class="pre">SparcISelLowering.cpp</span></code> contains examples of all four
+<code class="docutils literal notranslate"><span class="pre">LegalAction</span></code> values.</p>
+<div class="section" id="promote">
+<h4><a class="toc-backref" href="#id24">Promote</a><a class="headerlink" href="#promote" title="Permalink to this headline">¶</a></h4>
+<p>For an operation without native support for a given type, the specified type
+may be promoted to a larger type that is supported. For example, SPARC does
+not support a sign-extending load for Boolean values (<code class="docutils literal notranslate"><span class="pre">i1</span></code> type), so in
+<code class="docutils literal notranslate"><span class="pre">SparcISelLowering.cpp</span></code> the third parameter below, <code class="docutils literal notranslate"><span class="pre">Promote</span></code>, changes
+<code class="docutils literal notranslate"><span class="pre">i1</span></code> type values to a large type before loading.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">setLoadExtAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">SEXTLOAD</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i1</span><span class="p">,</span> <span class="n">Promote</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="expand">
+<h4><a class="toc-backref" href="#id25">Expand</a><a class="headerlink" href="#expand" title="Permalink to this headline">¶</a></h4>
+<p>For a type without native support, a value may need to be broken down further,
+rather than promoted. For an operation without native support, a combination
+of other operations may be used to similar effect. In SPARC, the
+floating-point sine and cosine trig operations are supported by expansion to
+other operations, as indicated by the third parameter, <code class="docutils literal notranslate"><span class="pre">Expand</span></code>, to
+<code class="docutils literal notranslate"><span class="pre">setOperationAction</span></code>:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">setOperationAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">FSIN</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">f32</span><span class="p">,</span> <span class="n">Expand</span><span class="p">);</span>
+<span class="n">setOperationAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">FCOS</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">f32</span><span class="p">,</span> <span class="n">Expand</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="custom">
+<h4><a class="toc-backref" href="#id26">Custom</a><a class="headerlink" href="#custom" title="Permalink to this headline">¶</a></h4>
+<p>For some operations, simple type promotion or operation expansion may be
+insufficient. In some cases, a special intrinsic function must be implemented.</p>
+<p>For example, a constant value may require special treatment, or an operation
+may require spilling and restoring registers in the stack and working with
+register allocators.</p>
+<p>As seen in <code class="docutils literal notranslate"><span class="pre">SparcISelLowering.cpp</span></code> code below, to perform a type conversion
+from a floating point value to a signed integer, first the
+<code class="docutils literal notranslate"><span class="pre">setOperationAction</span></code> should be called with <code class="docutils literal notranslate"><span class="pre">Custom</span></code> as the third parameter:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">setOperationAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">FP_TO_SINT</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">Custom</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>In the <code class="docutils literal notranslate"><span class="pre">LowerOperation</span></code> method, for each <code class="docutils literal notranslate"><span class="pre">Custom</span></code> operation, a case
+statement should be added to indicate what function to call. In the following
+code, an <code class="docutils literal notranslate"><span class="pre">FP_TO_SINT</span></code> opcode will call the <code class="docutils literal notranslate"><span class="pre">LowerFP_TO_SINT</span></code> method:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">SDValue</span> <span class="n">SparcTargetLowering</span><span class="o">::</span><span class="n">LowerOperation</span><span class="p">(</span><span class="n">SDValue</span> <span class="n">Op</span><span class="p">,</span> <span class="n">SelectionDAG</span> <span class="o">&</span><span class="n">DAG</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">switch</span> <span class="p">(</span><span class="n">Op</span><span class="p">.</span><span class="n">getOpcode</span><span class="p">())</span> <span class="p">{</span>
+ <span class="k">case</span> <span class="n">ISD</span><span class="o">::</span><span class="nl">FP_TO_SINT</span><span class="p">:</span> <span class="k">return</span> <span class="n">LowerFP_TO_SINT</span><span class="p">(</span><span class="n">Op</span><span class="p">,</span> <span class="n">DAG</span><span class="p">);</span>
+ <span class="p">...</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Finally, the <code class="docutils literal notranslate"><span class="pre">LowerFP_TO_SINT</span></code> method is implemented, using an FP register to
+convert the floating-point value to an integer.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="n">SDValue</span> <span class="nf">LowerFP_TO_SINT</span><span class="p">(</span><span class="n">SDValue</span> <span class="n">Op</span><span class="p">,</span> <span class="n">SelectionDAG</span> <span class="o">&</span><span class="n">DAG</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">Op</span><span class="p">.</span><span class="n">getValueType</span><span class="p">()</span> <span class="o">==</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">);</span>
+ <span class="n">Op</span> <span class="o">=</span> <span class="n">DAG</span><span class="p">.</span><span class="n">getNode</span><span class="p">(</span><span class="n">SPISD</span><span class="o">::</span><span class="n">FTOI</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">f32</span><span class="p">,</span> <span class="n">Op</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="mi">0</span><span class="p">));</span>
+ <span class="k">return</span> <span class="n">DAG</span><span class="p">.</span><span class="n">getNode</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">BITCAST</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">Op</span><span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="legal">
+<h4><a class="toc-backref" href="#id27">Legal</a><a class="headerlink" href="#legal" title="Permalink to this headline">¶</a></h4>
+<p>The <code class="docutils literal notranslate"><span class="pre">Legal</span></code> <code class="docutils literal notranslate"><span class="pre">LegalizeAction</span></code> enum value simply indicates that an operation
+<strong>is</strong> natively supported. <code class="docutils literal notranslate"><span class="pre">Legal</span></code> represents the default condition, so it
+is rarely used. In <code class="docutils literal notranslate"><span class="pre">SparcISelLowering.cpp</span></code>, the action for <code class="docutils literal notranslate"><span class="pre">CTPOP</span></code> (an
+operation to count the bits set in an integer) is natively supported only for
+SPARC v9. The following code enables the <code class="docutils literal notranslate"><span class="pre">Expand</span></code> conversion technique for
+non-v9 SPARC implementations.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">setOperationAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">CTPOP</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">Expand</span><span class="p">);</span>
+<span class="p">...</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">TM</span><span class="p">.</span><span class="n">getSubtarget</span><span class="o"><</span><span class="n">SparcSubtarget</span><span class="o">></span><span class="p">().</span><span class="n">isV9</span><span class="p">())</span>
+ <span class="n">setOperationAction</span><span class="p">(</span><span class="n">ISD</span><span class="o">::</span><span class="n">CTPOP</span><span class="p">,</span> <span class="n">MVT</span><span class="o">::</span><span class="n">i32</span><span class="p">,</span> <span class="n">Legal</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="calling-conventions">
+<h3><a class="toc-backref" href="#id28">Calling Conventions</a><a class="headerlink" href="#calling-conventions" title="Permalink to this headline">¶</a></h3>
+<p>To support target-specific calling conventions, <code class="docutils literal notranslate"><span class="pre">XXXGenCallingConv.td</span></code> uses
+interfaces (such as <code class="docutils literal notranslate"><span class="pre">CCIfType</span></code> and <code class="docutils literal notranslate"><span class="pre">CCAssignToReg</span></code>) that are defined in
+<code class="docutils literal notranslate"><span class="pre">lib/Target/TargetCallingConv.td</span></code>. TableGen can take the target descriptor
+file <code class="docutils literal notranslate"><span class="pre">XXXGenCallingConv.td</span></code> and generate the header file
+<code class="docutils literal notranslate"><span class="pre">XXXGenCallingConv.inc</span></code>, which is typically included in
+<code class="docutils literal notranslate"><span class="pre">XXXISelLowering.cpp</span></code>. You can use the interfaces in
+<code class="docutils literal notranslate"><span class="pre">TargetCallingConv.td</span></code> to specify:</p>
+<ul class="simple">
+<li>The order of parameter allocation.</li>
+<li>Where parameters and return values are placed (that is, on the stack or in
+registers).</li>
+<li>Which registers may be used.</li>
+<li>Whether the caller or callee unwinds the stack.</li>
+</ul>
+<p>The following example demonstrates the use of the <code class="docutils literal notranslate"><span class="pre">CCIfType</span></code> and
+<code class="docutils literal notranslate"><span class="pre">CCAssignToReg</span></code> interfaces. If the <code class="docutils literal notranslate"><span class="pre">CCIfType</span></code> predicate is true (that is,
+if the current argument is of type <code class="docutils literal notranslate"><span class="pre">f32</span></code> or <code class="docutils literal notranslate"><span class="pre">f64</span></code>), then the action is
+performed. In this case, the <code class="docutils literal notranslate"><span class="pre">CCAssignToReg</span></code> action assigns the argument
+value to the first available register: either <code class="docutils literal notranslate"><span class="pre">R0</span></code> or <code class="docutils literal notranslate"><span class="pre">R1</span></code>.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">SparcCallingConv.td</span></code> contains definitions for a target-specific return-value
+calling convention (<code class="docutils literal notranslate"><span class="pre">RetCC_Sparc32</span></code>) and a basic 32-bit C calling convention
+(<code class="docutils literal notranslate"><span class="pre">CC_Sparc32</span></code>). The definition of <code class="docutils literal notranslate"><span class="pre">RetCC_Sparc32</span></code> (shown below) indicates
+which registers are used for specified scalar return types. A single-precision
+float is returned to register <code class="docutils literal notranslate"><span class="pre">F0</span></code>, and a double-precision float goes to
+register <code class="docutils literal notranslate"><span class="pre">D0</span></code>. A 32-bit integer is returned in register <code class="docutils literal notranslate"><span class="pre">I0</span></code> or <code class="docutils literal notranslate"><span class="pre">I1</span></code>.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def RetCC_Sparc32 : CallingConv<[
+ CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
+ CCIfType<[f32], CCAssignToReg<[F0]>>,
+ CCIfType<[f64], CCAssignToReg<[D0]>>
+]>;
+</pre></div>
+</div>
+<p>The definition of <code class="docutils literal notranslate"><span class="pre">CC_Sparc32</span></code> in <code class="docutils literal notranslate"><span class="pre">SparcCallingConv.td</span></code> introduces
+<code class="docutils literal notranslate"><span class="pre">CCAssignToStack</span></code>, which assigns the value to a stack slot with the specified
+size and alignment. In the example below, the first parameter, 4, indicates
+the size of the slot, and the second parameter, also 4, indicates the stack
+alignment along 4-byte units. (Special cases: if size is zero, then the ABI
+size is used; if alignment is zero, then the ABI alignment is used.)</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def CC_Sparc32 : CallingConv<[
+ // All arguments get passed in integer registers if there is space.
+ CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>,
+ CCAssignToStack<4, 4>
+]>;
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">CCDelegateTo</span></code> is another commonly used interface, which tries to find a
+specified sub-calling convention, and, if a match is found, it is invoked. In
+the following example (in <code class="docutils literal notranslate"><span class="pre">X86CallingConv.td</span></code>), the definition of
+<code class="docutils literal notranslate"><span class="pre">RetCC_X86_32_C</span></code> ends with <code class="docutils literal notranslate"><span class="pre">CCDelegateTo</span></code>. After the current value is
+assigned to the register <code class="docutils literal notranslate"><span class="pre">ST0</span></code> or <code class="docutils literal notranslate"><span class="pre">ST1</span></code>, the <code class="docutils literal notranslate"><span class="pre">RetCC_X86Common</span></code> is
+invoked.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def RetCC_X86_32_C : CallingConv<[
+ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
+ CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
+ CCDelegateTo<RetCC_X86Common>
+]>;
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">CCIfCC</span></code> is an interface that attempts to match the given name to the current
+calling convention. If the name identifies the current calling convention,
+then a specified action is invoked. In the following example (in
+<code class="docutils literal notranslate"><span class="pre">X86CallingConv.td</span></code>), if the <code class="docutils literal notranslate"><span class="pre">Fast</span></code> calling convention is in use, then
+<code class="docutils literal notranslate"><span class="pre">RetCC_X86_32_Fast</span></code> is invoked. If the <code class="docutils literal notranslate"><span class="pre">SSECall</span></code> calling convention is in
+use, then <code class="docutils literal notranslate"><span class="pre">RetCC_X86_32_SSE</span></code> is invoked.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def RetCC_X86_32 : CallingConv<[
+ CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
+ CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>,
+ CCDelegateTo<RetCC_X86_32_C>
+]>;
+</pre></div>
+</div>
+<p>Other calling convention interfaces include:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">CCIf</span> <span class="pre"><predicate,</span> <span class="pre">action></span></code> â If the predicate matches, apply the action.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCIfInReg</span> <span class="pre"><action></span></code> â If the argument is marked with the â<code class="docutils literal notranslate"><span class="pre">inreg</span></code>â
+attribute, then apply the action.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCIfNest</span> <span class="pre"><action></span></code> â If the argument is marked with the â<code class="docutils literal notranslate"><span class="pre">nest</span></code>â
+attribute, then apply the action.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCIfNotVarArg</span> <span class="pre"><action></span></code> â If the current function does not take a
+variable number of arguments, apply the action.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCAssignToRegWithShadow</span> <span class="pre"><registerList,</span> <span class="pre">shadowList></span></code> â similar to
+<code class="docutils literal notranslate"><span class="pre">CCAssignToReg</span></code>, but with a shadow list of registers.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCPassByVal</span> <span class="pre"><size,</span> <span class="pre">align></span></code> â Assign value to a stack slot with the
+minimum specified size and alignment.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CCPromoteToType</span> <span class="pre"><type></span></code> â Promote the current value to the specified
+type.</li>
+<li><code class="docutils literal notranslate"><span class="pre">CallingConv</span> <span class="pre"><[actions]></span></code> â Define each calling convention that is
+supported.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="assembly-printer">
+<h2><a class="toc-backref" href="#id29">Assembly Printer</a><a class="headerlink" href="#assembly-printer" title="Permalink to this headline">¶</a></h2>
+<p>During the code emission stage, the code generator may utilize an LLVM pass to
+produce assembly output. To do this, you want to implement the code for a
+printer that converts LLVM IR to a GAS-format assembly language for your target
+machine, using the following steps:</p>
+<ul class="simple">
+<li>Define all the assembly strings for your target, adding them to the
+instructions defined in the <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.td</span></code> file. (See
+<a class="reference internal" href="#instruction-set"><span class="std std-ref">Instruction Set</span></a>.) TableGen will produce an output file
+(<code class="docutils literal notranslate"><span class="pre">XXXGenAsmWriter.inc</span></code>) with an implementation of the <code class="docutils literal notranslate"><span class="pre">printInstruction</span></code>
+method for the <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter</span></code> class.</li>
+<li>Write <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo.h</span></code>, which contains the bare-bones declaration of
+the <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo</span></code> class (a subclass of <code class="docutils literal notranslate"><span class="pre">TargetAsmInfo</span></code>).</li>
+<li>Write <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo.cpp</span></code>, which contains target-specific values for
+<code class="docutils literal notranslate"><span class="pre">TargetAsmInfo</span></code> properties and sometimes new implementations for methods.</li>
+<li>Write <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter.cpp</span></code>, which implements the <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> class that
+performs the LLVM-to-assembly conversion.</li>
+</ul>
+<p>The code in <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo.h</span></code> is usually a trivial declaration of the
+<code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo</span></code> class for use in <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo.cpp</span></code>. Similarly,
+<code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo.cpp</span></code> usually has a few declarations of <code class="docutils literal notranslate"><span class="pre">XXXTargetAsmInfo</span></code>
+replacement values that override the default values in <code class="docutils literal notranslate"><span class="pre">TargetAsmInfo.cpp</span></code>.
+For example in <code class="docutils literal notranslate"><span class="pre">SparcTargetAsmInfo.cpp</span></code>:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">SparcTargetAsmInfo</span><span class="o">::</span><span class="n">SparcTargetAsmInfo</span><span class="p">(</span><span class="k">const</span> <span class="n">SparcTargetMachine</span> <span class="o">&</span><span class="n">TM</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">Data16bitsDirective</span> <span class="o">=</span> <span class="s">"</span><span class="se">\t</span><span class="s">.half</span><span class="se">\t</span><span class="s">"</span><span class="p">;</span>
+ <span class="n">Data32bitsDirective</span> <span class="o">=</span> <span class="s">"</span><span class="se">\t</span><span class="s">.word</span><span class="se">\t</span><span class="s">"</span><span class="p">;</span>
+ <span class="n">Data64bitsDirective</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="c1">// .xword is only supported by V9.</span>
+ <span class="n">ZeroDirective</span> <span class="o">=</span> <span class="s">"</span><span class="se">\t</span><span class="s">.skip</span><span class="se">\t</span><span class="s">"</span><span class="p">;</span>
+ <span class="n">CommentString</span> <span class="o">=</span> <span class="s">"!"</span><span class="p">;</span>
+ <span class="n">ConstantPoolSection</span> <span class="o">=</span> <span class="s">"</span><span class="se">\t</span><span class="s">.section </span><span class="se">\"</span><span class="s">.rodata</span><span class="se">\"</span><span class="s">,#alloc</span><span class="se">\n</span><span class="s">"</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The X86 assembly printer implementation (<code class="docutils literal notranslate"><span class="pre">X86TargetAsmInfo</span></code>) is an example
+where the target specific <code class="docutils literal notranslate"><span class="pre">TargetAsmInfo</span></code> class uses an overridden methods:
+<code class="docutils literal notranslate"><span class="pre">ExpandInlineAsm</span></code>.</p>
+<p>A target-specific implementation of <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> is written in
+<code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter.cpp</span></code>, which implements the <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> class that converts
+the LLVM to printable assembly. The implementation must include the following
+headers that have declarations for the <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> and
+<code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> classes. The <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> is a subclass of
+<code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#include</span> <span class="cpf">"llvm/CodeGen/AsmPrinter.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/CodeGen/MachineFunctionPass.h"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>As a <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>, <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code> first calls <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> to set
+up the <code class="docutils literal notranslate"><span class="pre">AsmPrinter</span></code>. In <code class="docutils literal notranslate"><span class="pre">SparcAsmPrinter</span></code>, a <code class="docutils literal notranslate"><span class="pre">Mangler</span></code> object is
+instantiated to process variable names.</p>
+<p>In <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter.cpp</span></code>, the <code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code> method (declared in
+<code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>) must be implemented for <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter</span></code>. In
+<code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>, the <code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> method invokes
+<code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code>. Target-specific implementations of
+<code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code> differ, but generally do the following to process each
+machine function:</p>
+<ul class="simple">
+<li>Call <code class="docutils literal notranslate"><span class="pre">SetupMachineFunction</span></code> to perform initialization.</li>
+<li>Call <code class="docutils literal notranslate"><span class="pre">EmitConstantPool</span></code> to print out (to the output stream) constants which
+have been spilled to memory.</li>
+<li>Call <code class="docutils literal notranslate"><span class="pre">EmitJumpTableInfo</span></code> to print out jump tables used by the current
+function.</li>
+<li>Print out the label for the current function.</li>
+<li>Print out the code for the function, including basic block labels and the
+assembly for the instruction (using <code class="docutils literal notranslate"><span class="pre">printInstruction</span></code>)</li>
+</ul>
+<p>The <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter</span></code> implementation must also include the code generated by
+TableGen that is output in the <code class="docutils literal notranslate"><span class="pre">XXXGenAsmWriter.inc</span></code> file. The code in
+<code class="docutils literal notranslate"><span class="pre">XXXGenAsmWriter.inc</span></code> contains an implementation of the <code class="docutils literal notranslate"><span class="pre">printInstruction</span></code>
+method that may call these methods:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">printOperand</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">printMemOperand</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">printCCOperand</span></code> (for conditional statements)</li>
+<li><code class="docutils literal notranslate"><span class="pre">printDataDirective</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">printDeclare</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">printImplicitDef</span></code></li>
+<li><code class="docutils literal notranslate"><span class="pre">printInlineAsm</span></code></li>
+</ul>
+<p>The implementations of <code class="docutils literal notranslate"><span class="pre">printDeclare</span></code>, <code class="docutils literal notranslate"><span class="pre">printImplicitDef</span></code>,
+<code class="docutils literal notranslate"><span class="pre">printInlineAsm</span></code>, and <code class="docutils literal notranslate"><span class="pre">printLabel</span></code> in <code class="docutils literal notranslate"><span class="pre">AsmPrinter.cpp</span></code> are generally
+adequate for printing assembly and do not need to be overridden.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">printOperand</span></code> method is implemented with a long <code class="docutils literal notranslate"><span class="pre">switch</span></code>/<code class="docutils literal notranslate"><span class="pre">case</span></code>
+statement for the type of operand: register, immediate, basic block, external
+symbol, global address, constant pool index, or jump table index. For an
+instruction with a memory address operand, the <code class="docutils literal notranslate"><span class="pre">printMemOperand</span></code> method
+should be implemented to generate the proper output. Similarly,
+<code class="docutils literal notranslate"><span class="pre">printCCOperand</span></code> should be used to print a conditional operand.</p>
+<p><code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> should be overridden in <code class="docutils literal notranslate"><span class="pre">XXXAsmPrinter</span></code>, and it should be
+called to shut down the assembly printer. During <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code>, global
+variables and constants are printed to output.</p>
+</div>
+<div class="section" id="subtarget-support">
+<h2><a class="toc-backref" href="#id30">Subtarget Support</a><a class="headerlink" href="#subtarget-support" title="Permalink to this headline">¶</a></h2>
+<p>Subtarget support is used to inform the code generation process of instruction
+set variations for a given chip set. For example, the LLVM SPARC
+implementation provided covers three major versions of the SPARC microprocessor
+architecture: Version 8 (V8, which is a 32-bit architecture), Version 9 (V9, a
+64-bit architecture), and the UltraSPARC architecture. V8 has 16
+double-precision floating-point registers that are also usable as either 32
+single-precision or 8 quad-precision registers. V8 is also purely big-endian.
+V9 has 32 double-precision floating-point registers that are also usable as 16
+quad-precision registers, but cannot be used as single-precision registers.
+The UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
+extensions.</p>
+<p>If subtarget support is needed, you should implement a target-specific
+<code class="docutils literal notranslate"><span class="pre">XXXSubtarget</span></code> class for your architecture. This class should process the
+command-line options <code class="docutils literal notranslate"><span class="pre">-mcpu=</span></code> and <code class="docutils literal notranslate"><span class="pre">-mattr=</span></code>.</p>
+<p>TableGen uses definitions in the <code class="docutils literal notranslate"><span class="pre">Target.td</span></code> and <code class="docutils literal notranslate"><span class="pre">Sparc.td</span></code> files to
+generate code in <code class="docutils literal notranslate"><span class="pre">SparcGenSubtarget.inc</span></code>. In <code class="docutils literal notranslate"><span class="pre">Target.td</span></code>, shown below, the
+<code class="docutils literal notranslate"><span class="pre">SubtargetFeature</span></code> interface is defined. The first 4 string parameters of
+the <code class="docutils literal notranslate"><span class="pre">SubtargetFeature</span></code> interface are a feature name, an attribute set by the
+feature, the value of the attribute, and a description of the feature. (The
+fifth parameter is a list of features whose presence is implied, and its
+default value is an empty array.)</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class SubtargetFeature<string n, string a, string v, string d,
+ list<SubtargetFeature> i = []> {
+ string Name = n;
+ string Attribute = a;
+ string Value = v;
+ string Desc = d;
+ list<SubtargetFeature> Implies = i;
+}
+</pre></div>
+</div>
+<p>In the <code class="docutils literal notranslate"><span class="pre">Sparc.td</span></code> file, the <code class="docutils literal notranslate"><span class="pre">SubtargetFeature</span></code> is used to define the
+following features.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
+ "Enable SPARC-V9 instructions">;
+def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8",
+ "V8DeprecatedInsts", "true",
+ "Enable deprecated V8 instructions in V9 mode">;
+def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true",
+ "Enable UltraSPARC Visual Instruction Set extensions">;
+</pre></div>
+</div>
+<p>Elsewhere in <code class="docutils literal notranslate"><span class="pre">Sparc.td</span></code>, the <code class="docutils literal notranslate"><span class="pre">Proc</span></code> class is defined and then is used to
+define particular SPARC processor subtypes that may have the previously
+described features.</p>
+<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>class Proc<string Name, list<SubtargetFeature> Features>
+ : Processor<Name, NoItineraries, Features>;
+
+def : Proc<"generic", []>;
+def : Proc<"v8", []>;
+def : Proc<"supersparc", []>;
+def : Proc<"sparclite", []>;
+def : Proc<"f934", []>;
+def : Proc<"hypersparc", []>;
+def : Proc<"sparclite86x", []>;
+def : Proc<"sparclet", []>;
+def : Proc<"tsc701", []>;
+def : Proc<"v9", [FeatureV9]>;
+def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>;
+def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>;
+def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
+</pre></div>
+</div>
+<p>From <code class="docutils literal notranslate"><span class="pre">Target.td</span></code> and <code class="docutils literal notranslate"><span class="pre">Sparc.td</span></code> files, the resulting
+<code class="docutils literal notranslate"><span class="pre">SparcGenSubtarget.inc</span></code> specifies enum values to identify the features,
+arrays of constants to represent the CPU features and CPU subtypes, and the
+<code class="docutils literal notranslate"><span class="pre">ParseSubtargetFeatures</span></code> method that parses the features string that sets
+specified subtarget options. The generated <code class="docutils literal notranslate"><span class="pre">SparcGenSubtarget.inc</span></code> file
+should be included in the <code class="docutils literal notranslate"><span class="pre">SparcSubtarget.cpp</span></code>. The target-specific
+implementation of the <code class="docutils literal notranslate"><span class="pre">XXXSubtarget</span></code> method should follow this pseudocode:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">XXXSubtarget</span><span class="o">::</span><span class="n">XXXSubtarget</span><span class="p">(</span><span class="k">const</span> <span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">,</span> <span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="o">&</span><span class="n">FS</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// Set the default features</span>
+ <span class="c1">// Determine default and user specified characteristics of the CPU</span>
+ <span class="c1">// Call ParseSubtargetFeatures(FS, CPU) to parse the features string</span>
+ <span class="c1">// Perform any additional operations</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="jit-support">
+<h2><a class="toc-backref" href="#id31">JIT Support</a><a class="headerlink" href="#jit-support" title="Permalink to this headline">¶</a></h2>
+<p>The implementation of a target machine optionally includes a Just-In-Time (JIT)
+code generator that emits machine code and auxiliary structures as binary
+output that can be written directly to memory. To do this, implement JIT code
+generation by performing the following steps:</p>
+<ul class="simple">
+<li>Write an <code class="docutils literal notranslate"><span class="pre">XXXCodeEmitter.cpp</span></code> file that contains a machine function pass
+that transforms target-machine instructions into relocatable machine
+code.</li>
+<li>Write an <code class="docutils literal notranslate"><span class="pre">XXXJITInfo.cpp</span></code> file that implements the JIT interfaces for
+target-specific code-generation activities, such as emitting machine code and
+stubs.</li>
+<li>Modify <code class="docutils literal notranslate"><span class="pre">XXXTargetMachine</span></code> so that it provides a <code class="docutils literal notranslate"><span class="pre">TargetJITInfo</span></code> object
+through its <code class="docutils literal notranslate"><span class="pre">getJITInfo</span></code> method.</li>
+</ul>
+<p>There are several different approaches to writing the JIT support code. For
+instance, TableGen and target descriptor files may be used for creating a JIT
+code generator, but are not mandatory. For the Alpha and PowerPC target
+machines, TableGen is used to generate <code class="docutils literal notranslate"><span class="pre">XXXGenCodeEmitter.inc</span></code>, which
+contains the binary coding of machine instructions and the
+<code class="docutils literal notranslate"><span class="pre">getBinaryCodeForInstr</span></code> method to access those codes. Other JIT
+implementations do not.</p>
+<p>Both <code class="docutils literal notranslate"><span class="pre">XXXJITInfo.cpp</span></code> and <code class="docutils literal notranslate"><span class="pre">XXXCodeEmitter.cpp</span></code> must include the
+<code class="docutils literal notranslate"><span class="pre">llvm/CodeGen/MachineCodeEmitter.h</span></code> header file that defines the
+<code class="docutils literal notranslate"><span class="pre">MachineCodeEmitter</span></code> class containing code for several callback functions
+that write data (in bytes, words, strings, etc.) to the output stream.</p>
+<div class="section" id="machine-code-emitter">
+<h3><a class="toc-backref" href="#id32">Machine Code Emitter</a><a class="headerlink" href="#machine-code-emitter" title="Permalink to this headline">¶</a></h3>
+<p>In <code class="docutils literal notranslate"><span class="pre">XXXCodeEmitter.cpp</span></code>, a target-specific of the <code class="docutils literal notranslate"><span class="pre">Emitter</span></code> class is
+implemented as a function pass (subclass of <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>). The
+target-specific implementation of <code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code> (invoked by
+<code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> in <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>) iterates through the
+<code class="docutils literal notranslate"><span class="pre">MachineBasicBlock</span></code> calls <code class="docutils literal notranslate"><span class="pre">emitInstruction</span></code> to process each instruction and
+emit binary code. <code class="docutils literal notranslate"><span class="pre">emitInstruction</span></code> is largely implemented with case
+statements on the instruction types defined in <code class="docutils literal notranslate"><span class="pre">XXXInstrInfo.h</span></code>. For
+example, in <code class="docutils literal notranslate"><span class="pre">X86CodeEmitter.cpp</span></code>, the <code class="docutils literal notranslate"><span class="pre">emitInstruction</span></code> method is built
+around the following <code class="docutils literal notranslate"><span class="pre">switch</span></code>/<code class="docutils literal notranslate"><span class="pre">case</span></code> statements:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">switch</span> <span class="p">(</span><span class="n">Desc</span><span class="o">-></span><span class="n">TSFlags</span> <span class="o">&</span> <span class="n">X86</span><span class="o">::</span><span class="n">FormMask</span><span class="p">)</span> <span class="p">{</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">Pseudo</span><span class="p">:</span> <span class="c1">// for not yet implemented instructions</span>
+ <span class="p">...</span> <span class="c1">// or pseudo-instructions</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">RawFrm</span><span class="p">:</span> <span class="c1">// for instructions with a fixed opcode value</span>
+ <span class="p">...</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">AddRegFrm</span><span class="p">:</span> <span class="c1">// for instructions that have one register operand</span>
+ <span class="p">...</span> <span class="c1">// added to their opcode</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRMDestReg</span><span class="p">:</span><span class="c1">// for instructions that use the Mod/RM byte</span>
+ <span class="p">...</span> <span class="c1">// to specify a destination (register)</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRMDestMem</span><span class="p">:</span><span class="c1">// for instructions that use the Mod/RM byte</span>
+ <span class="p">...</span> <span class="c1">// to specify a destination (memory)</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRMSrcReg</span><span class="p">:</span> <span class="c1">// for instructions that use the Mod/RM byte</span>
+ <span class="p">...</span> <span class="c1">// to specify a source (register)</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRMSrcMem</span><span class="p">:</span> <span class="c1">// for instructions that use the Mod/RM byte</span>
+ <span class="p">...</span> <span class="c1">// to specify a source (memory)</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM0r</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM1r</span><span class="p">:</span> <span class="c1">// for instructions that operate on</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM2r</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM3r</span><span class="p">:</span> <span class="c1">// a REGISTER r/m operand and</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM4r</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM5r</span><span class="p">:</span> <span class="c1">// use the Mod/RM byte and a field</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM6r</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM7r</span><span class="p">:</span> <span class="c1">// to hold extended opcode data</span>
+ <span class="p">...</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM0m</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM1m</span><span class="p">:</span> <span class="c1">// for instructions that operate on</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM2m</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM3m</span><span class="p">:</span> <span class="c1">// a MEMORY r/m operand and</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM4m</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM5m</span><span class="p">:</span> <span class="c1">// use the Mod/RM byte and a field</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM6m</span><span class="p">:</span> <span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM7m</span><span class="p">:</span> <span class="c1">// to hold extended opcode data</span>
+ <span class="p">...</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRMInitReg</span><span class="p">:</span> <span class="c1">// for instructions whose source and</span>
+ <span class="p">...</span> <span class="c1">// destination are the same register</span>
+ <span class="k">break</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The implementations of these case statements often first emit the opcode and
+then get the operand(s). Then depending upon the operand, helper methods may
+be called to process the operand(s). For example, in <code class="docutils literal notranslate"><span class="pre">X86CodeEmitter.cpp</span></code>,
+for the <code class="docutils literal notranslate"><span class="pre">X86II::AddRegFrm</span></code> case, the first data emitted (by <code class="docutils literal notranslate"><span class="pre">emitByte</span></code>) is
+the opcode added to the register operand. Then an object representing the
+machine operand, <code class="docutils literal notranslate"><span class="pre">MO1</span></code>, is extracted. The helper methods such as
+<code class="docutils literal notranslate"><span class="pre">isImmediate</span></code>, <code class="docutils literal notranslate"><span class="pre">isGlobalAddress</span></code>, <code class="docutils literal notranslate"><span class="pre">isExternalSymbol</span></code>,
+<code class="docutils literal notranslate"><span class="pre">isConstantPoolIndex</span></code>, and <code class="docutils literal notranslate"><span class="pre">isJumpTableIndex</span></code> determine the operand type.
+(<code class="docutils literal notranslate"><span class="pre">X86CodeEmitter.cpp</span></code> also has private methods such as <code class="docutils literal notranslate"><span class="pre">emitConstant</span></code>,
+<code class="docutils literal notranslate"><span class="pre">emitGlobalAddress</span></code>, <code class="docutils literal notranslate"><span class="pre">emitExternalSymbolAddress</span></code>, <code class="docutils literal notranslate"><span class="pre">emitConstPoolAddress</span></code>,
+and <code class="docutils literal notranslate"><span class="pre">emitJumpTableAddress</span></code> that emit the data into the output stream.)</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">AddRegFrm</span><span class="p">:</span>
+ <span class="n">MCE</span><span class="p">.</span><span class="n">emitByte</span><span class="p">(</span><span class="n">BaseOpcode</span> <span class="o">+</span> <span class="n">getX86RegNum</span><span class="p">(</span><span class="n">MI</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="n">CurOp</span><span class="o">++</span><span class="p">).</span><span class="n">getReg</span><span class="p">()));</span>
+
+ <span class="k">if</span> <span class="p">(</span><span class="n">CurOp</span> <span class="o">!=</span> <span class="n">NumOps</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">const</span> <span class="n">MachineOperand</span> <span class="o">&</span><span class="n">MO1</span> <span class="o">=</span> <span class="n">MI</span><span class="p">.</span><span class="n">getOperand</span><span class="p">(</span><span class="n">CurOp</span><span class="o">++</span><span class="p">);</span>
+ <span class="kt">unsigned</span> <span class="n">Size</span> <span class="o">=</span> <span class="n">X86InstrInfo</span><span class="o">::</span><span class="n">sizeOfImm</span><span class="p">(</span><span class="n">Desc</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">isImmediate</span><span class="p">())</span>
+ <span class="n">emitConstant</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getImm</span><span class="p">(),</span> <span class="n">Size</span><span class="p">);</span>
+ <span class="k">else</span> <span class="p">{</span>
+ <span class="kt">unsigned</span> <span class="n">rt</span> <span class="o">=</span> <span class="n">Is64BitMode</span> <span class="o">?</span> <span class="n">X86</span><span class="o">::</span><span class="nl">reloc_pcrel_word</span>
+ <span class="p">:</span> <span class="p">(</span><span class="n">IsPIC</span> <span class="o">?</span> <span class="n">X86</span><span class="o">::</span><span class="nl">reloc_picrel_word</span> <span class="p">:</span> <span class="n">X86</span><span class="o">::</span><span class="n">reloc_absolute_word</span><span class="p">);</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">Opcode</span> <span class="o">==</span> <span class="n">X86</span><span class="o">::</span><span class="n">MOV64ri</span><span class="p">)</span>
+ <span class="n">rt</span> <span class="o">=</span> <span class="n">X86</span><span class="o">::</span><span class="n">reloc_absolute_dword</span><span class="p">;</span> <span class="c1">// FIXME: add X86II flag?</span>
+ <span class="k">if</span> <span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">isGlobalAddress</span><span class="p">())</span> <span class="p">{</span>
+ <span class="kt">bool</span> <span class="n">NeedStub</span> <span class="o">=</span> <span class="n">isa</span><span class="o"><</span><span class="n">Function</span><span class="o">></span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getGlobal</span><span class="p">());</span>
+ <span class="kt">bool</span> <span class="n">isLazy</span> <span class="o">=</span> <span class="n">gvNeedsLazyPtr</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getGlobal</span><span class="p">());</span>
+ <span class="n">emitGlobalAddress</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getGlobal</span><span class="p">(),</span> <span class="n">rt</span><span class="p">,</span> <span class="n">MO1</span><span class="p">.</span><span class="n">getOffset</span><span class="p">(),</span> <span class="mi">0</span><span class="p">,</span>
+ <span class="n">NeedStub</span><span class="p">,</span> <span class="n">isLazy</span><span class="p">);</span>
+ <span class="p">}</span> <span class="k">else</span> <span class="k">if</span> <span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">isExternalSymbol</span><span class="p">())</span>
+ <span class="n">emitExternalSymbolAddress</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getSymbolName</span><span class="p">(),</span> <span class="n">rt</span><span class="p">);</span>
+ <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">isConstantPoolIndex</span><span class="p">())</span>
+ <span class="n">emitConstPoolAddress</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getIndex</span><span class="p">(),</span> <span class="n">rt</span><span class="p">);</span>
+ <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">isJumpTableIndex</span><span class="p">())</span>
+ <span class="n">emitJumpTableAddress</span><span class="p">(</span><span class="n">MO1</span><span class="p">.</span><span class="n">getIndex</span><span class="p">(),</span> <span class="n">rt</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>In the previous example, <code class="docutils literal notranslate"><span class="pre">XXXCodeEmitter.cpp</span></code> uses the variable <code class="docutils literal notranslate"><span class="pre">rt</span></code>, which
+is a <code class="docutils literal notranslate"><span class="pre">RelocationType</span></code> enum that may be used to relocate addresses (for
+example, a global address with a PIC base offset). The <code class="docutils literal notranslate"><span class="pre">RelocationType</span></code> enum
+for that target is defined in the short target-specific <code class="docutils literal notranslate"><span class="pre">XXXRelocations.h</span></code>
+file. The <code class="docutils literal notranslate"><span class="pre">RelocationType</span></code> is used by the <code class="docutils literal notranslate"><span class="pre">relocate</span></code> method defined in
+<code class="docutils literal notranslate"><span class="pre">XXXJITInfo.cpp</span></code> to rewrite addresses for referenced global symbols.</p>
+<p>For example, <code class="docutils literal notranslate"><span class="pre">X86Relocations.h</span></code> specifies the following relocation types for
+the X86 addresses. In all four cases, the relocated value is added to the
+value already in memory. For <code class="docutils literal notranslate"><span class="pre">reloc_pcrel_word</span></code> and <code class="docutils literal notranslate"><span class="pre">reloc_picrel_word</span></code>,
+there is an additional initial adjustment.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">enum</span> <span class="n">RelocationType</span> <span class="p">{</span>
+ <span class="n">reloc_pcrel_word</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="c1">// add reloc value after adjusting for the PC loc</span>
+ <span class="n">reloc_picrel_word</span> <span class="o">=</span> <span class="mi">1</span><span class="p">,</span> <span class="c1">// add reloc value after adjusting for the PIC base</span>
+ <span class="n">reloc_absolute_word</span> <span class="o">=</span> <span class="mi">2</span><span class="p">,</span> <span class="c1">// absolute relocation; no additional adjustment</span>
+ <span class="n">reloc_absolute_dword</span> <span class="o">=</span> <span class="mi">3</span> <span class="c1">// absolute relocation; no additional adjustment</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="target-jit-info">
+<h3><a class="toc-backref" href="#id33">Target JIT Info</a><a class="headerlink" href="#target-jit-info" title="Permalink to this headline">¶</a></h3>
+<p><code class="docutils literal notranslate"><span class="pre">XXXJITInfo.cpp</span></code> implements the JIT interfaces for target-specific
+code-generation activities, such as emitting machine code and stubs. At
+minimum, a target-specific version of <code class="docutils literal notranslate"><span class="pre">XXXJITInfo</span></code> implements the following:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">getLazyResolverFunction</span></code> â Initializes the JIT, gives the target a
+function that is used for compilation.</li>
+<li><code class="docutils literal notranslate"><span class="pre">emitFunctionStub</span></code> â Returns a native function with a specified address
+for a callback function.</li>
+<li><code class="docutils literal notranslate"><span class="pre">relocate</span></code> â Changes the addresses of referenced globals, based on
+relocation types.</li>
+<li>Callback function that are wrappers to a function stub that is used when the
+real target is not initially known.</li>
+</ul>
+<p><code class="docutils literal notranslate"><span class="pre">getLazyResolverFunction</span></code> is generally trivial to implement. It makes the
+incoming parameter as the global <code class="docutils literal notranslate"><span class="pre">JITCompilerFunction</span></code> and returns the
+callback function that will be used a function wrapper. For the Alpha target
+(in <code class="docutils literal notranslate"><span class="pre">AlphaJITInfo.cpp</span></code>), the <code class="docutils literal notranslate"><span class="pre">getLazyResolverFunction</span></code> implementation is
+simply:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">TargetJITInfo</span><span class="o">::</span><span class="n">LazyResolverFn</span> <span class="n">AlphaJITInfo</span><span class="o">::</span><span class="n">getLazyResolverFunction</span><span class="p">(</span>
+ <span class="n">JITCompilerFn</span> <span class="n">F</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">JITCompilerFunction</span> <span class="o">=</span> <span class="n">F</span><span class="p">;</span>
+ <span class="k">return</span> <span class="n">AlphaCompilationCallback</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>For the X86 target, the <code class="docutils literal notranslate"><span class="pre">getLazyResolverFunction</span></code> implementation is a little
+more complicated, because it returns a different callback function for
+processors with SSE instructions and XMM registers.</p>
+<p>The callback function initially saves and later restores the callee register
+values, incoming arguments, and frame and return address. The callback
+function needs low-level access to the registers or stack, so it is typically
+implemented with assembler.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="HowToUseInstrMappings.html" title="How To Use Instruction Mappings"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="Proposals/VectorizationPlan.html" title="Vectorization Plan"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/WritingAnLLVMPass.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/WritingAnLLVMPass.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/WritingAnLLVMPass.html (added)
+++ www-releases/trunk/9.0.0/docs/WritingAnLLVMPass.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,1336 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Writing an LLVM Pass — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="How To Use Attributes" href="HowToUseAttributes.html" />
+ <link rel="prev" title="Garbage Collection with LLVM" href="GarbageCollection.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" role="navigation" aria-label="related navigation">
+ <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="HowToUseAttributes.html" title="How To Use Attributes"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="GarbageCollection.html" title="Garbage Collection with 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" role="main">
+
+ <div class="section" id="writing-an-llvm-pass">
+<h1>Writing an LLVM Pass<a class="headerlink" href="#writing-an-llvm-pass" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction-what-is-a-pass" id="id5">Introduction â What is a pass?</a></li>
+<li><a class="reference internal" href="#quick-start-writing-hello-world" id="id6">Quick Start â Writing hello world</a><ul>
+<li><a class="reference internal" href="#setting-up-the-build-environment" id="id7">Setting up the build environment</a></li>
+<li><a class="reference internal" href="#basic-code-required" id="id8">Basic code required</a></li>
+<li><a class="reference internal" href="#running-a-pass-with-opt" id="id9">Running a pass with <code class="docutils literal notranslate"><span class="pre">opt</span></code></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#pass-classes-and-requirements" id="id10">Pass classes and requirements</a><ul>
+<li><a class="reference internal" href="#the-immutablepass-class" id="id11">The <code class="docutils literal notranslate"><span class="pre">ImmutablePass</span></code> class</a></li>
+<li><a class="reference internal" href="#the-modulepass-class" id="id12">The <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-runonmodule-method" id="id13">The <code class="docutils literal notranslate"><span class="pre">runOnModule</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-callgraphsccpass-class" id="id14">The <code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-doinitialization-callgraph-method" id="id15">The <code class="docutils literal notranslate"><span class="pre">doInitialization(CallGraph</span> <span class="pre">&)</span></code> method</a></li>
+<li><a class="reference internal" href="#the-runonscc-method" id="id16">The <code class="docutils literal notranslate"><span class="pre">runOnSCC</span></code> method</a></li>
+<li><a class="reference internal" href="#the-dofinalization-callgraph-method" id="id17">The <code class="docutils literal notranslate"><span class="pre">doFinalization(CallGraph</span> <span class="pre">&)</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-functionpass-class" id="id18">The <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-doinitialization-module-method" id="id19">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Module</span> <span class="pre">&)</span></code> method</a></li>
+<li><a class="reference internal" href="#the-runonfunction-method" id="id20">The <code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> method</a></li>
+<li><a class="reference internal" href="#the-dofinalization-module-method" id="id21">The <code class="docutils literal notranslate"><span class="pre">doFinalization(Module</span> <span class="pre">&)</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-looppass-class" id="id22">The <code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-doinitialization-loop-lppassmanager-method" id="id23">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Loop</span> <span class="pre">*,</span> <span class="pre">LPPassManager</span> <span class="pre">&)</span></code> method</a></li>
+<li><a class="reference internal" href="#the-runonloop-method" id="id24">The <code class="docutils literal notranslate"><span class="pre">runOnLoop</span></code> method</a></li>
+<li><a class="reference internal" href="#the-dofinalization-method" id="id25">The <code class="docutils literal notranslate"><span class="pre">doFinalization()</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-regionpass-class" id="id26">The <code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-doinitialization-region-rgpassmanager-method" id="id27">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Region</span> <span class="pre">*,</span> <span class="pre">RGPassManager</span> <span class="pre">&)</span></code> method</a></li>
+<li><a class="reference internal" href="#the-runonregion-method" id="id28">The <code class="docutils literal notranslate"><span class="pre">runOnRegion</span></code> method</a></li>
+<li><a class="reference internal" href="#id2" id="id29">The <code class="docutils literal notranslate"><span class="pre">doFinalization()</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-basicblockpass-class" id="id30">The <code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-doinitialization-function-method" id="id31">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Function</span> <span class="pre">&)</span></code> method</a></li>
+<li><a class="reference internal" href="#the-runonbasicblock-method" id="id32">The <code class="docutils literal notranslate"><span class="pre">runOnBasicBlock</span></code> method</a></li>
+<li><a class="reference internal" href="#the-dofinalization-function-method" id="id33">The <code class="docutils literal notranslate"><span class="pre">doFinalization(Function</span> <span class="pre">&)</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-machinefunctionpass-class" id="id34">The <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> class</a><ul>
+<li><a class="reference internal" href="#the-runonmachinefunction-machinefunction-mf-method" id="id35">The <code class="docutils literal notranslate"><span class="pre">runOnMachineFunction(MachineFunction</span> <span class="pre">&MF)</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#pass-registration" id="id36">Pass registration</a><ul>
+<li><a class="reference internal" href="#the-print-method" id="id37">The <code class="docutils literal notranslate"><span class="pre">print</span></code> method</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#specifying-interactions-between-passes" id="id38">Specifying interactions between passes</a><ul>
+<li><a class="reference internal" href="#the-getanalysisusage-method" id="id39">The <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code> method</a></li>
+<li><a class="reference internal" href="#the-analysisusage-addrequired-and-analysisusage-addrequiredtransitive-methods" id="id40">The <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addRequired<></span></code> and <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addRequiredTransitive<></span></code> methods</a></li>
+<li><a class="reference internal" href="#the-analysisusage-addpreserved-method" id="id41">The <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addPreserved<></span></code> method</a></li>
+<li><a class="reference internal" href="#example-implementations-of-getanalysisusage" id="id42">Example implementations of <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code></a></li>
+<li><a class="reference internal" href="#the-getanalysis-and-getanalysisifavailable-methods" id="id43">The <code class="docutils literal notranslate"><span class="pre">getAnalysis<></span></code> and <code class="docutils literal notranslate"><span class="pre">getAnalysisIfAvailable<></span></code> methods</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#implementing-analysis-groups" id="id44">Implementing Analysis Groups</a><ul>
+<li><a class="reference internal" href="#analysis-group-concepts" id="id45">Analysis Group Concepts</a></li>
+<li><a class="reference internal" href="#using-registeranalysisgroup" id="id46">Using <code class="docutils literal notranslate"><span class="pre">RegisterAnalysisGroup</span></code></a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#pass-statistics" id="id47">Pass Statistics</a><ul>
+<li><a class="reference internal" href="#what-passmanager-does" id="id48">What PassManager does</a><ul>
+<li><a class="reference internal" href="#the-releasememory-method" id="id49">The <code class="docutils literal notranslate"><span class="pre">releaseMemory</span></code> method</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#registering-dynamically-loaded-passes" id="id50">Registering dynamically loaded passes</a><ul>
+<li><a class="reference internal" href="#using-existing-registries" id="id51">Using existing registries</a></li>
+<li><a class="reference internal" href="#creating-new-registries" id="id52">Creating new registries</a></li>
+<li><a class="reference internal" href="#using-gdb-with-dynamically-loaded-passes" id="id53">Using GDB with dynamically loaded passes</a><ul>
+<li><a class="reference internal" href="#setting-a-breakpoint-in-your-pass" id="id54">Setting a breakpoint in your pass</a></li>
+<li><a class="reference internal" href="#miscellaneous-problems" id="id55">Miscellaneous Problems</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#future-extensions-planned" id="id56">Future extensions planned</a><ul>
+<li><a class="reference internal" href="#multithreaded-llvm" id="id57">Multithreaded LLVM</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction-what-is-a-pass">
+<h2><a class="toc-backref" href="#id5">Introduction â What is a pass?</a><a class="headerlink" href="#introduction-what-is-a-pass" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM Pass Framework is an important part of the LLVM system, because LLVM
+passes are where most of the interesting parts of the compiler exist. Passes
+perform the transformations and optimizations that make up the compiler, they
+build the analysis results that are used by these transformations, and they
+are, above all, a structuring technique for compiler code.</p>
+<p>All LLVM passes are subclasses of the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1Pass.html">Pass</a> class, which implement
+functionality by overriding virtual methods inherited from <code class="docutils literal notranslate"><span class="pre">Pass</span></code>. Depending
+on how your pass works, you should inherit from the <a class="reference internal" href="#writing-an-llvm-pass-modulepass"><span class="std std-ref">ModulePass</span></a> , <a class="reference internal" href="#writing-an-llvm-pass-callgraphsccpass"><span class="std std-ref">CallGraphSCCPass</span></a>, <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a> , or <a class="reference internal" href="#writing-an-llvm-pass-looppass"><span class="std std-ref">LoopPass</span></a>, or <a class="reference internal" href="#writing-an-llvm-pass-regionpass"><span class="std std-ref">RegionPass</span></a>, or <a class="reference internal" href="#writing-an-llvm-pass-basicblockpass"><span class="std std-ref">BasicBlockPass</span></a> classes, which gives the system more
+information about what your pass does, and how it can be combined with other
+passes. One of the main features of the LLVM Pass Framework is that it
+schedules passes to run in an efficient way based on the constraints that your
+pass meets (which are indicated by which class they derive from).</p>
+<p>We start by showing you how to construct a pass, everything from setting up the
+code, to compiling, loading, and executing it. After the basics are down, more
+advanced features are discussed.</p>
+</div>
+<div class="section" id="quick-start-writing-hello-world">
+<h2><a class="toc-backref" href="#id6">Quick Start â Writing hello world</a><a class="headerlink" href="#quick-start-writing-hello-world" title="Permalink to this headline">¶</a></h2>
+<p>Here we describe how to write the âhello worldâ of passes. The âHelloâ pass is
+designed to simply print out the name of non-external functions that exist in
+the program being compiled. It does not modify the program at all, it just
+inspects it. The source code and files for this pass are available in the LLVM
+source tree in the <code class="docutils literal notranslate"><span class="pre">lib/Transforms/Hello</span></code> directory.</p>
+<div class="section" id="setting-up-the-build-environment">
+<span id="writing-an-llvm-pass-makefile"></span><h3><a class="toc-backref" href="#id7">Setting up the build environment</a><a class="headerlink" href="#setting-up-the-build-environment" title="Permalink to this headline">¶</a></h3>
+<p>First, configure and build LLVM. Next, you need to create a new directory
+somewhere in the LLVM source base. For this example, weâll assume that you
+made <code class="docutils literal notranslate"><span class="pre">lib/Transforms/Hello</span></code>. Finally, you must set up a build script
+that will compile the source code for the new pass. To do this,
+copy the following into <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code>:</p>
+<div class="highlight-cmake notranslate"><div class="highlight"><pre><span></span><span class="nb">add_llvm_library</span><span class="p">(</span> <span class="s">LLVMHello</span> <span class="s">MODULE</span>
+ <span class="s">Hello.cpp</span>
+
+ <span class="s">PLUGIN_TOOL</span>
+ <span class="s">opt</span>
+ <span class="p">)</span>
+</pre></div>
+</div>
+<p>and the following line into <code class="docutils literal notranslate"><span class="pre">lib/Transforms/CMakeLists.txt</span></code>:</p>
+<div class="highlight-cmake notranslate"><div class="highlight"><pre><span></span><span class="nb">add_subdirectory</span><span class="p">(</span><span class="s">Hello</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>(Note that there is already a directory named <code class="docutils literal notranslate"><span class="pre">Hello</span></code> with a sample âHelloâ
+pass; you may play with it â in which case you donât need to modify any
+<code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> files â or, if you want to create everything from scratch,
+use another name.)</p>
+<p>This build script specifies that <code class="docutils literal notranslate"><span class="pre">Hello.cpp</span></code> file in the current directory
+is to be compiled and linked into a shared object <code class="docutils literal notranslate"><span class="pre">$(LEVEL)/lib/LLVMHello.so</span></code> that
+can be dynamically loaded by the <strong class="program">opt</strong> tool via its <a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-load"><code class="xref std std-option docutils literal notranslate"><span class="pre">-load</span></code></a>
+option. If your operating system uses a suffix other than <code class="docutils literal notranslate"><span class="pre">.so</span></code> (such as
+Windows or macOS), the appropriate extension will be used.</p>
+<p>Now that we have the build scripts set up, we just need to write the code for
+the pass itself.</p>
+</div>
+<div class="section" id="basic-code-required">
+<span id="writing-an-llvm-pass-basiccode"></span><h3><a class="toc-backref" href="#id8">Basic code required</a><a class="headerlink" href="#basic-code-required" title="Permalink to this headline">¶</a></h3>
+<p>Now that we have a way to compile our new pass, we just have to write it.
+Start out with:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#include</span> <span class="cpf">"llvm/Pass.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/IR/Function.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/Support/raw_ostream.h"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>Which are needed because we are writing a <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1Pass.html">Pass</a>, we are operating on
+<a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1Function.html">Function</a>s, and we will
+be doing some printing.</p>
+<p>Next we have:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">using</span> <span class="k">namespace</span> <span class="n">llvm</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>⦠which is required because the functions from the include files live in the
+llvm namespace.</p>
+<p>Next we have:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">namespace</span> <span class="p">{</span>
+</pre></div>
+</div>
+<p>⦠which starts out an anonymous namespace. Anonymous namespaces are to C++
+what the â<code class="docutils literal notranslate"><span class="pre">static</span></code>â keyword is to C (at global scope). It makes the things
+declared inside of the anonymous namespace visible only to the current file.
+If youâre not familiar with them, consult a decent C++ book for more
+information.</p>
+<p>Next, we declare our pass itself:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="nl">Hello</span> <span class="p">:</span> <span class="k">public</span> <span class="n">FunctionPass</span> <span class="p">{</span>
+</pre></div>
+</div>
+<p>This declares a â<code class="docutils literal notranslate"><span class="pre">Hello</span></code>â class that is a subclass of <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a>. The different builtin pass subclasses
+are described in detail <a class="reference internal" href="#writing-an-llvm-pass-pass-classes"><span class="std std-ref">later</span></a>, but
+for now, know that <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> operates on a function at a time.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="kt">char</span> <span class="n">ID</span><span class="p">;</span>
+<span class="n">Hello</span><span class="p">()</span> <span class="o">:</span> <span class="n">FunctionPass</span><span class="p">(</span><span class="n">ID</span><span class="p">)</span> <span class="p">{}</span>
+</pre></div>
+</div>
+<p>This declares pass identifier used by LLVM to identify pass. This allows LLVM
+to avoid using expensive C++ runtime information.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span> <span class="kt">bool</span> <span class="nf">runOnFunction</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">)</span> <span class="k">override</span> <span class="p">{</span>
+ <span class="n">errs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"Hello: "</span><span class="p">;</span>
+ <span class="n">errs</span><span class="p">().</span><span class="n">write_escaped</span><span class="p">(</span><span class="n">F</span><span class="p">.</span><span class="n">getName</span><span class="p">())</span> <span class="o"><<</span> <span class="sc">'\n'</span><span class="p">;</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+ <span class="p">}</span>
+<span class="p">};</span> <span class="c1">// end of struct Hello</span>
+<span class="p">}</span> <span class="c1">// end of anonymous namespace</span>
+</pre></div>
+</div>
+<p>We declare a <a class="reference internal" href="#writing-an-llvm-pass-runonfunction"><span class="std std-ref">runOnFunction</span></a> method,
+which overrides an abstract virtual method inherited from <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a>. This is where we are supposed to do our
+thing, so we just print out our message with the name of each function.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">char</span> <span class="n">Hello</span><span class="o">::</span><span class="n">ID</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>We initialize pass ID here. LLVM uses IDâs address to identify a pass, so
+initialization value is not important.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="n">RegisterPass</span><span class="o"><</span><span class="n">Hello</span><span class="o">></span> <span class="n">X</span><span class="p">(</span><span class="s">"hello"</span><span class="p">,</span> <span class="s">"Hello World Pass"</span><span class="p">,</span>
+ <span class="nb">false</span> <span class="cm">/* Only looks at CFG */</span><span class="p">,</span>
+ <span class="nb">false</span> <span class="cm">/* Analysis Pass */</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>Lastly, we <a class="reference internal" href="#writing-an-llvm-pass-registration"><span class="std std-ref">register our class</span></a>
+<code class="docutils literal notranslate"><span class="pre">Hello</span></code>, giving it a command line argument â<code class="docutils literal notranslate"><span class="pre">hello</span></code>â, and a name âHello
+World Passâ. The last two arguments describe its behavior: if a pass walks CFG
+without modifying it then the third argument is set to <code class="docutils literal notranslate"><span class="pre">true</span></code>; if a pass is
+an analysis pass, for example dominator tree pass, then <code class="docutils literal notranslate"><span class="pre">true</span></code> is supplied as
+the fourth argument.</p>
+<p>If we want to register the pass as a step of an existing pipeline, some extension
+points are provided, e.g. <code class="docutils literal notranslate"><span class="pre">PassManagerBuilder::EP_EarlyAsPossible</span></code> to apply our
+pass before any optimization, or <code class="docutils literal notranslate"><span class="pre">PassManagerBuilder::EP_FullLinkTimeOptimizationLast</span></code>
+to apply it after Link Time Optimizations.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="n">llvm</span><span class="o">::</span><span class="n">RegisterStandardPasses</span> <span class="n">Y</span><span class="p">(</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">PassManagerBuilder</span><span class="o">::</span><span class="n">EP_EarlyAsPossible</span><span class="p">,</span>
+ <span class="p">[](</span><span class="k">const</span> <span class="n">llvm</span><span class="o">::</span><span class="n">PassManagerBuilder</span> <span class="o">&</span><span class="n">Builder</span><span class="p">,</span>
+ <span class="n">llvm</span><span class="o">::</span><span class="n">legacy</span><span class="o">::</span><span class="n">PassManagerBase</span> <span class="o">&</span><span class="n">PM</span><span class="p">)</span> <span class="p">{</span> <span class="n">PM</span><span class="p">.</span><span class="n">add</span><span class="p">(</span><span class="k">new</span> <span class="n">Hello</span><span class="p">());</span> <span class="p">});</span>
+</pre></div>
+</div>
+<p>As a whole, the <code class="docutils literal notranslate"><span class="pre">.cpp</span></code> file looks like:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#include</span> <span class="cpf">"llvm/Pass.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/IR/Function.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/Support/raw_ostream.h"</span><span class="cp"></span>
+
+<span class="cp">#include</span> <span class="cpf">"llvm/IR/LegacyPassManager.h"</span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf">"llvm/Transforms/IPO/PassManagerBuilder.h"</span><span class="cp"></span>
+
+<span class="k">using</span> <span class="k">namespace</span> <span class="n">llvm</span><span class="p">;</span>
+
+<span class="k">namespace</span> <span class="p">{</span>
+<span class="k">struct</span> <span class="nl">Hello</span> <span class="p">:</span> <span class="k">public</span> <span class="n">FunctionPass</span> <span class="p">{</span>
+ <span class="k">static</span> <span class="kt">char</span> <span class="n">ID</span><span class="p">;</span>
+ <span class="n">Hello</span><span class="p">()</span> <span class="o">:</span> <span class="n">FunctionPass</span><span class="p">(</span><span class="n">ID</span><span class="p">)</span> <span class="p">{}</span>
+
+ <span class="kt">bool</span> <span class="n">runOnFunction</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">)</span> <span class="k">override</span> <span class="p">{</span>
+ <span class="n">errs</span><span class="p">()</span> <span class="o"><<</span> <span class="s">"Hello: "</span><span class="p">;</span>
+ <span class="n">errs</span><span class="p">().</span><span class="n">write_escaped</span><span class="p">(</span><span class="n">F</span><span class="p">.</span><span class="n">getName</span><span class="p">())</span> <span class="o"><<</span> <span class="sc">'\n'</span><span class="p">;</span>
+ <span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
+ <span class="p">}</span>
+<span class="p">};</span> <span class="c1">// end of struct Hello</span>
+<span class="p">}</span> <span class="c1">// end of anonymous namespace</span>
+
+<span class="kt">char</span> <span class="n">Hello</span><span class="o">::</span><span class="n">ID</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="k">static</span> <span class="n">RegisterPass</span><span class="o"><</span><span class="n">Hello</span><span class="o">></span> <span class="n">X</span><span class="p">(</span><span class="s">"hello"</span><span class="p">,</span> <span class="s">"Hello World Pass"</span><span class="p">,</span>
+ <span class="nb">false</span> <span class="cm">/* Only looks at CFG */</span><span class="p">,</span>
+ <span class="nb">false</span> <span class="cm">/* Analysis Pass */</span><span class="p">);</span>
+
+<span class="k">static</span> <span class="n">RegisterStandardPasses</span> <span class="nf">Y</span><span class="p">(</span>
+ <span class="n">PassManagerBuilder</span><span class="o">::</span><span class="n">EP_EarlyAsPossible</span><span class="p">,</span>
+ <span class="p">[](</span><span class="k">const</span> <span class="n">PassManagerBuilder</span> <span class="o">&</span><span class="n">Builder</span><span class="p">,</span>
+ <span class="n">legacy</span><span class="o">::</span><span class="n">PassManagerBase</span> <span class="o">&</span><span class="n">PM</span><span class="p">)</span> <span class="p">{</span> <span class="n">PM</span><span class="p">.</span><span class="n">add</span><span class="p">(</span><span class="k">new</span> <span class="n">Hello</span><span class="p">());</span> <span class="p">});</span>
+</pre></div>
+</div>
+<p>Now that itâs all together, compile the file with a simple â<code class="docutils literal notranslate"><span class="pre">gmake</span></code>â command
+from the top level of your build directory and you should get a new file
+â<code class="docutils literal notranslate"><span class="pre">lib/LLVMHello.so</span></code>â. Note that everything in this file is
+contained in an anonymous namespace â this reflects the fact that passes
+are self contained units that do not need external interfaces (although they
+can have them) to be useful.</p>
+</div>
+<div class="section" id="running-a-pass-with-opt">
+<h3><a class="toc-backref" href="#id9">Running a pass with <code class="docutils literal notranslate"><span class="pre">opt</span></code></a><a class="headerlink" href="#running-a-pass-with-opt" title="Permalink to this headline">¶</a></h3>
+<p>Now that you have a brand new shiny shared object file, we can use the
+<strong class="program">opt</strong> command to run an LLVM program through your pass. Because you
+registered your pass with <code class="docutils literal notranslate"><span class="pre">RegisterPass</span></code>, you will be able to use the
+<strong class="program">opt</strong> tool to access it, once loaded.</p>
+<p>To test it, follow the example at the end of the <a class="reference internal" href="GettingStarted.html"><span class="doc">Getting Started with the LLVM System</span></a> to
+compile âHello Worldâ to LLVM. We can now run the bitcode file (hello.bc) for
+the program through our transformation like this (or course, any bitcode file
+will work):</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -hello < hello.bc > /dev/null
+<span class="go">Hello: __main</span>
+<span class="go">Hello: puts</span>
+<span class="go">Hello: main</span>
+</pre></div>
+</div>
+<p>The <a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-load"><code class="xref std std-option docutils literal notranslate"><span class="pre">-load</span></code></a> option specifies that <strong class="program">opt</strong> should load your pass
+as a shared object, which makes â<code class="docutils literal notranslate"><span class="pre">-hello</span></code>â a valid command line argument
+(which is one reason you need to <a class="reference internal" href="#writing-an-llvm-pass-registration"><span class="std std-ref">register your pass</span></a>). Because the Hello pass does not modify
+the program in any interesting way, we just throw away the result of
+<strong class="program">opt</strong> (sending it to <code class="docutils literal notranslate"><span class="pre">/dev/null</span></code>).</p>
+<p>To see what happened to the other string you registered, try running
+<strong class="program">opt</strong> with the <a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-help"><code class="xref std std-option docutils literal notranslate"><span class="pre">-help</span></code></a> option:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -help
+<span class="go">OVERVIEW: llvm .bc -> .bc modular optimizer and analysis printer</span>
+
+<span class="go">USAGE: opt [subcommand] [options] <input bitcode file></span>
+
+<span class="go">OPTIONS:</span>
+<span class="go"> Optimizations available:</span>
+<span class="go">...</span>
+<span class="go"> -guard-widening - Widen guards</span>
+<span class="go"> -gvn - Global Value Numbering</span>
+<span class="go"> -gvn-hoist - Early GVN Hoisting of Expressions</span>
+<span class="go"> -hello - Hello World Pass</span>
+<span class="go"> -indvars - Induction Variable Simplification</span>
+<span class="go"> -inferattrs - Infer set function attributes</span>
+<span class="go">...</span>
+</pre></div>
+</div>
+<p>The pass name gets added as the information string for your pass, giving some
+documentation to users of <strong class="program">opt</strong>. Now that you have a working pass,
+you would go ahead and make it do the cool transformations you want. Once you
+get it all working and tested, it may become useful to find out how fast your
+pass is. The <a class="reference internal" href="#writing-an-llvm-pass-passmanager"><span class="std std-ref">PassManager</span></a> provides a
+nice command line option (<a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-time-passes"><code class="xref std std-option docutils literal notranslate"><span class="pre">-time-passes</span></code></a>) that allows you to get
+information about the execution time of your pass along with the other passes
+you queue up. For example:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -hello -time-passes < hello.bc > /dev/null
+<span class="go">Hello: __main</span>
+<span class="go">Hello: puts</span>
+<span class="go">Hello: main</span>
+<span class="go">===-------------------------------------------------------------------------===</span>
+<span class="go"> ... Pass execution timing report ...</span>
+<span class="go">===-------------------------------------------------------------------------===</span>
+<span class="go"> Total Execution Time: 0.0007 seconds (0.0005 wall clock)</span>
+
+<span class="go"> ---User Time--- --User+System-- ---Wall Time--- --- Name ---</span>
+<span class="go"> 0.0004 ( 55.3%) 0.0004 ( 55.3%) 0.0004 ( 75.7%) Bitcode Writer</span>
+<span class="go"> 0.0003 ( 44.7%) 0.0003 ( 44.7%) 0.0001 ( 13.6%) Hello World Pass</span>
+<span class="go"> 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0001 ( 10.7%) Module Verifier</span>
+<span class="go"> 0.0007 (100.0%) 0.0007 (100.0%) 0.0005 (100.0%) Total</span>
+</pre></div>
+</div>
+<p>As you can see, our implementation above is pretty fast. The additional
+passes listed are automatically inserted by the <strong class="program">opt</strong> tool to verify
+that the LLVM emitted by your pass is still valid and well formed LLVM, which
+hasnât been broken somehow.</p>
+<p>Now that you have seen the basics of the mechanics behind passes, we can talk
+about some more details of how they work and how to use them.</p>
+</div>
+</div>
+<div class="section" id="pass-classes-and-requirements">
+<span id="writing-an-llvm-pass-pass-classes"></span><h2><a class="toc-backref" href="#id10">Pass classes and requirements</a><a class="headerlink" href="#pass-classes-and-requirements" title="Permalink to this headline">¶</a></h2>
+<p>One of the first things that you should do when designing a new pass is to
+decide what class you should subclass for your pass. The <a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello World</span></a> example uses the <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a> class for its implementation, but we did
+not discuss why or when this should occur. Here we talk about the classes
+available, from the most general to the most specific.</p>
+<p>When choosing a superclass for your <code class="docutils literal notranslate"><span class="pre">Pass</span></code>, you should choose the <strong>most
+specific</strong> class possible, while still being able to meet the requirements
+listed. This gives the LLVM Pass Infrastructure information necessary to
+optimize how passes are run, so that the resultant compiler isnât unnecessarily
+slow.</p>
+<div class="section" id="the-immutablepass-class">
+<h3><a class="toc-backref" href="#id11">The <code class="docutils literal notranslate"><span class="pre">ImmutablePass</span></code> class</a><a class="headerlink" href="#the-immutablepass-class" title="Permalink to this headline">¶</a></h3>
+<p>The most plain and boring type of pass is the â<a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1ImmutablePass.html">ImmutablePass</a>â class. This pass
+type is used for passes that do not have to be run, do not change state, and
+never need to be updated. This is not a normal type of transformation or
+analysis, but can provide information about the current compiler configuration.</p>
+<p>Although this pass class is very infrequently used, it is important for
+providing information about the current target machine being compiled for, and
+other static information that can affect the various transformations.</p>
+<p><code class="docutils literal notranslate"><span class="pre">ImmutablePass</span></code>es never invalidate other transformations, are never
+invalidated, and are never ârunâ.</p>
+</div>
+<div class="section" id="the-modulepass-class">
+<span id="writing-an-llvm-pass-modulepass"></span><h3><a class="toc-backref" href="#id12">The <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> class</a><a class="headerlink" href="#the-modulepass-class" title="Permalink to this headline">¶</a></h3>
+<p>The <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass</a> class
+is the most general of all superclasses that you can use. Deriving from
+<code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> indicates that your pass uses the entire program as a unit,
+referring to function bodies in no predictable order, or adding and removing
+functions. Because nothing is known about the behavior of <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code>
+subclasses, no optimization can be done for their execution.</p>
+<p>A module pass can use function level passes (e.g. dominators) using the
+<code class="docutils literal notranslate"><span class="pre">getAnalysis</span></code> interface <code class="docutils literal notranslate"><span class="pre">getAnalysis<DominatorTree>(llvm::Function</span> <span class="pre">*)</span></code> to
+provide the function to retrieve analysis result for, if the function pass does
+not require any module or immutable passes. Note that this can only be done
+for functions for which the analysis ran, e.g. in the case of dominators you
+should only ask for the <code class="docutils literal notranslate"><span class="pre">DominatorTree</span></code> for function definitions, not
+declarations.</p>
+<p>To write a correct <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> subclass, derive from <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> and
+overload the <code class="docutils literal notranslate"><span class="pre">runOnModule</span></code> method with the following signature:</p>
+<div class="section" id="the-runonmodule-method">
+<h4><a class="toc-backref" href="#id13">The <code class="docutils literal notranslate"><span class="pre">runOnModule</span></code> method</a><a class="headerlink" href="#the-runonmodule-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnModule</span><span class="p">(</span><span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnModule</span></code> method performs the interesting work of the pass. It
+should return <code class="docutils literal notranslate"><span class="pre">true</span></code> if the module was modified by the transformation and
+<code class="docutils literal notranslate"><span class="pre">false</span></code> otherwise.</p>
+</div>
+</div>
+<div class="section" id="the-callgraphsccpass-class">
+<span id="writing-an-llvm-pass-callgraphsccpass"></span><h3><a class="toc-backref" href="#id14">The <code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code> class</a><a class="headerlink" href="#the-callgraphsccpass-class" title="Permalink to this headline">¶</a></h3>
+<p>The <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1CallGraphSCCPass.html">CallGraphSCCPass</a> is used by
+passes that need to traverse the program bottom-up on the call graph (callees
+before callers). Deriving from <code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code> provides some mechanics
+for building and traversing the <code class="docutils literal notranslate"><span class="pre">CallGraph</span></code>, but also allows the system to
+optimize execution of <code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code>es. If your pass meets the
+requirements outlined below, and doesnât meet the requirements of a
+<a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a> or <a class="reference internal" href="#writing-an-llvm-pass-basicblockpass"><span class="std std-ref">BasicBlockPass</span></a>, you should derive from
+<code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code>.</p>
+<p><code class="docutils literal notranslate"><span class="pre">TODO</span></code>: explain briefly what SCC, Tarjanâs algo, and B-U mean.</p>
+<p>To be explicit, CallGraphSCCPass subclasses are:</p>
+<ol class="arabic simple">
+<li>⦠<em>not allowed</em> to inspect or modify any <code class="docutils literal notranslate"><span class="pre">Function</span></code>s other than those
+in the current SCC and the direct callers and direct callees of the SCC.</li>
+<li>⦠<em>required</em> to preserve the current <code class="docutils literal notranslate"><span class="pre">CallGraph</span></code> object, updating it to
+reflect any changes made to the program.</li>
+<li>⦠<em>not allowed</em> to add or remove SCCâs from the current Module, though
+they may change the contents of an SCC.</li>
+<li>⦠<em>allowed</em> to add or remove global variables from the current Module.</li>
+<li>⦠<em>allowed</em> to maintain state across invocations of <a class="reference internal" href="#writing-an-llvm-pass-runonscc"><span class="std std-ref">runOnSCC</span></a> (including global data).</li>
+</ol>
+<p>Implementing a <code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code> is slightly tricky in some cases because it
+has to handle SCCs with more than one node in it. All of the virtual methods
+described below should return <code class="docutils literal notranslate"><span class="pre">true</span></code> if they modified the program, or
+<code class="docutils literal notranslate"><span class="pre">false</span></code> if they didnât.</p>
+<div class="section" id="the-doinitialization-callgraph-method">
+<h4><a class="toc-backref" href="#id15">The <code class="docutils literal notranslate"><span class="pre">doInitialization(CallGraph</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-doinitialization-callgraph-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doInitialization</span><span class="p">(</span><span class="n">CallGraph</span> <span class="o">&</span><span class="n">CG</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is allowed to do most of the things that
+<code class="docutils literal notranslate"><span class="pre">CallGraphSCCPass</span></code>es are not allowed to do. They can add and remove
+functions, get pointers to functions, etc. The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is
+designed to do simple initialization type of stuff that does not depend on the
+SCCs being processed. The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method call is not scheduled to
+overlap with any other pass executions (thus it should be very fast).</p>
+</div>
+<div class="section" id="the-runonscc-method">
+<span id="writing-an-llvm-pass-runonscc"></span><h4><a class="toc-backref" href="#id16">The <code class="docutils literal notranslate"><span class="pre">runOnSCC</span></code> method</a><a class="headerlink" href="#the-runonscc-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnSCC</span><span class="p">(</span><span class="n">CallGraphSCC</span> <span class="o">&</span><span class="n">SCC</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnSCC</span></code> method performs the interesting work of the pass, and should
+return <code class="docutils literal notranslate"><span class="pre">true</span></code> if the module was modified by the transformation, <code class="docutils literal notranslate"><span class="pre">false</span></code>
+otherwise.</p>
+</div>
+<div class="section" id="the-dofinalization-callgraph-method">
+<h4><a class="toc-backref" href="#id17">The <code class="docutils literal notranslate"><span class="pre">doFinalization(CallGraph</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-dofinalization-callgraph-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doFinalization</span><span class="p">(</span><span class="n">CallGraph</span> <span class="o">&</span><span class="n">CG</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> method is an infrequently used method that is called
+when the pass framework has finished calling <a class="reference internal" href="#writing-an-llvm-pass-runonscc"><span class="std std-ref">runOnSCC</span></a> for every SCC in the program being compiled.</p>
+</div>
+</div>
+<div class="section" id="the-functionpass-class">
+<span id="writing-an-llvm-pass-functionpass"></span><h3><a class="toc-backref" href="#id18">The <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> class</a><a class="headerlink" href="#the-functionpass-class" title="Permalink to this headline">¶</a></h3>
+<p>In contrast to <code class="docutils literal notranslate"><span class="pre">ModulePass</span></code> subclasses, <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1Pass.html">FunctionPass</a> subclasses do have a
+predictable, local behavior that can be expected by the system. All
+<code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> execute on each function in the program independent of all of
+the other functions in the program. <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>es do not require that
+they are executed in a particular order, and <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>es do not modify
+external functions.</p>
+<p>To be explicit, <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> subclasses are not allowed to:</p>
+<ol class="arabic simple">
+<li>Inspect or modify a <code class="docutils literal notranslate"><span class="pre">Function</span></code> other than the one currently being processed.</li>
+<li>Add or remove <code class="docutils literal notranslate"><span class="pre">Function</span></code>s from the current <code class="docutils literal notranslate"><span class="pre">Module</span></code>.</li>
+<li>Add or remove global variables from the current <code class="docutils literal notranslate"><span class="pre">Module</span></code>.</li>
+<li>Maintain state across invocations of <a class="reference internal" href="#writing-an-llvm-pass-runonfunction"><span class="std std-ref">runOnFunction</span></a> (including global data).</li>
+</ol>
+<p>Implementing a <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> is usually straightforward (See the <a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello
+World</span></a> pass for example).
+<code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>es may overload three virtual methods to do their work. All
+of these methods should return <code class="docutils literal notranslate"><span class="pre">true</span></code> if they modified the program, or
+<code class="docutils literal notranslate"><span class="pre">false</span></code> if they didnât.</p>
+<div class="section" id="the-doinitialization-module-method">
+<span id="writing-an-llvm-pass-doinitialization-mod"></span><h4><a class="toc-backref" href="#id19">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Module</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-doinitialization-module-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doInitialization</span><span class="p">(</span><span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is allowed to do most of the things that
+<code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>es are not allowed to do. They can add and remove functions,
+get pointers to functions, etc. The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is designed to
+do simple initialization type of stuff that does not depend on the functions
+being processed. The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method call is not scheduled to
+overlap with any other pass executions (thus it should be very fast).</p>
+<p>A good example of how this method should be used is the <a class="reference external" href="http://llvm.org/doxygen/LowerAllocations_8cpp-source.html">LowerAllocations</a> pass. This pass
+converts <code class="docutils literal notranslate"><span class="pre">malloc</span></code> and <code class="docutils literal notranslate"><span class="pre">free</span></code> instructions into platform dependent
+<code class="docutils literal notranslate"><span class="pre">malloc()</span></code> and <code class="docutils literal notranslate"><span class="pre">free()</span></code> function calls. It uses the <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code>
+method to get a reference to the <code class="docutils literal notranslate"><span class="pre">malloc</span></code> and <code class="docutils literal notranslate"><span class="pre">free</span></code> functions that it
+needs, adding prototypes to the module if necessary.</p>
+</div>
+<div class="section" id="the-runonfunction-method">
+<span id="writing-an-llvm-pass-runonfunction"></span><h4><a class="toc-backref" href="#id20">The <code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> method</a><a class="headerlink" href="#the-runonfunction-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnFunction</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> method must be implemented by your subclass to do the
+transformation or analysis work of your pass. As usual, a <code class="docutils literal notranslate"><span class="pre">true</span></code> value
+should be returned if the function is modified.</p>
+</div>
+<div class="section" id="the-dofinalization-module-method">
+<span id="writing-an-llvm-pass-dofinalization-mod"></span><h4><a class="toc-backref" href="#id21">The <code class="docutils literal notranslate"><span class="pre">doFinalization(Module</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-dofinalization-module-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doFinalization</span><span class="p">(</span><span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> method is an infrequently used method that is called
+when the pass framework has finished calling <a class="reference internal" href="#writing-an-llvm-pass-runonfunction"><span class="std std-ref">runOnFunction</span></a> for every function in the program being
+compiled.</p>
+</div>
+</div>
+<div class="section" id="the-looppass-class">
+<span id="writing-an-llvm-pass-looppass"></span><h3><a class="toc-backref" href="#id22">The <code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> class</a><a class="headerlink" href="#the-looppass-class" title="Permalink to this headline">¶</a></h3>
+<p>All <code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> execute on each loop in the function independent of all of the
+other loops in the function. <code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> processes loops in loop nest order
+such that outer most loop is processed last.</p>
+<p><code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> subclasses are allowed to update loop nest using <code class="docutils literal notranslate"><span class="pre">LPPassManager</span></code>
+interface. Implementing a loop pass is usually straightforward.
+<code class="docutils literal notranslate"><span class="pre">LoopPass</span></code>es may overload three virtual methods to do their work. All
+these methods should return <code class="docutils literal notranslate"><span class="pre">true</span></code> if they modified the program, or <code class="docutils literal notranslate"><span class="pre">false</span></code>
+if they didnât.</p>
+<p>A <code class="docutils literal notranslate"><span class="pre">LoopPass</span></code> subclass which is intended to run as part of the main loop pass
+pipeline needs to preserve all of the same <em>function</em> analyses that the other
+loop passes in its pipeline require. To make that easier,
+a <code class="docutils literal notranslate"><span class="pre">getLoopAnalysisUsage</span></code> function is provided by <code class="docutils literal notranslate"><span class="pre">LoopUtils.h</span></code>. It can be
+called within the subclassâs <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code> override to get consistent
+and correct behavior. Analogously, <code class="docutils literal notranslate"><span class="pre">INITIALIZE_PASS_DEPENDENCY(LoopPass)</span></code>
+will initialize this set of function analyses.</p>
+<div class="section" id="the-doinitialization-loop-lppassmanager-method">
+<h4><a class="toc-backref" href="#id23">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Loop</span> <span class="pre">*,</span> <span class="pre">LPPassManager</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-doinitialization-loop-lppassmanager-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doInitialization</span><span class="p">(</span><span class="n">Loop</span> <span class="o">*</span><span class="p">,</span> <span class="n">LPPassManager</span> <span class="o">&</span><span class="n">LPM</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is designed to do simple initialization type of
+stuff that does not depend on the functions being processed. The
+<code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method call is not scheduled to overlap with any other
+pass executions (thus it should be very fast). <code class="docutils literal notranslate"><span class="pre">LPPassManager</span></code> interface
+should be used to access <code class="docutils literal notranslate"><span class="pre">Function</span></code> or <code class="docutils literal notranslate"><span class="pre">Module</span></code> level analysis information.</p>
+</div>
+<div class="section" id="the-runonloop-method">
+<span id="writing-an-llvm-pass-runonloop"></span><h4><a class="toc-backref" href="#id24">The <code class="docutils literal notranslate"><span class="pre">runOnLoop</span></code> method</a><a class="headerlink" href="#the-runonloop-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnLoop</span><span class="p">(</span><span class="n">Loop</span> <span class="o">*</span><span class="p">,</span> <span class="n">LPPassManager</span> <span class="o">&</span><span class="n">LPM</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnLoop</span></code> method must be implemented by your subclass to do the
+transformation or analysis work of your pass. As usual, a <code class="docutils literal notranslate"><span class="pre">true</span></code> value
+should be returned if the function is modified. <code class="docutils literal notranslate"><span class="pre">LPPassManager</span></code> interface
+should be used to update loop nest.</p>
+</div>
+<div class="section" id="the-dofinalization-method">
+<h4><a class="toc-backref" href="#id25">The <code class="docutils literal notranslate"><span class="pre">doFinalization()</span></code> method</a><a class="headerlink" href="#the-dofinalization-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doFinalization</span><span class="p">();</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> method is an infrequently used method that is called
+when the pass framework has finished calling <a class="reference internal" href="#writing-an-llvm-pass-runonloop"><span class="std std-ref">runOnLoop</span></a> for every loop in the program being compiled.</p>
+</div>
+</div>
+<div class="section" id="the-regionpass-class">
+<span id="writing-an-llvm-pass-regionpass"></span><h3><a class="toc-backref" href="#id26">The <code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> class</a><a class="headerlink" href="#the-regionpass-class" title="Permalink to this headline">¶</a></h3>
+<p><code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> is similar to <a class="reference internal" href="#writing-an-llvm-pass-looppass"><span class="std std-ref">LoopPass</span></a>,
+but executes on each single entry single exit region in the function.
+<code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> processes regions in nested order such that the outer most
+region is processed last.</p>
+<p><code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> subclasses are allowed to update the region tree by using the
+<code class="docutils literal notranslate"><span class="pre">RGPassManager</span></code> interface. You may overload three virtual methods of
+<code class="docutils literal notranslate"><span class="pre">RegionPass</span></code> to implement your own region pass. All these methods should
+return <code class="docutils literal notranslate"><span class="pre">true</span></code> if they modified the program, or <code class="docutils literal notranslate"><span class="pre">false</span></code> if they did not.</p>
+<div class="section" id="the-doinitialization-region-rgpassmanager-method">
+<h4><a class="toc-backref" href="#id27">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Region</span> <span class="pre">*,</span> <span class="pre">RGPassManager</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-doinitialization-region-rgpassmanager-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doInitialization</span><span class="p">(</span><span class="n">Region</span> <span class="o">*</span><span class="p">,</span> <span class="n">RGPassManager</span> <span class="o">&</span><span class="n">RGM</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is designed to do simple initialization type of
+stuff that does not depend on the functions being processed. The
+<code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method call is not scheduled to overlap with any other
+pass executions (thus it should be very fast). <code class="docutils literal notranslate"><span class="pre">RPPassManager</span></code> interface
+should be used to access <code class="docutils literal notranslate"><span class="pre">Function</span></code> or <code class="docutils literal notranslate"><span class="pre">Module</span></code> level analysis information.</p>
+</div>
+<div class="section" id="the-runonregion-method">
+<span id="writing-an-llvm-pass-runonregion"></span><h4><a class="toc-backref" href="#id28">The <code class="docutils literal notranslate"><span class="pre">runOnRegion</span></code> method</a><a class="headerlink" href="#the-runonregion-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnRegion</span><span class="p">(</span><span class="n">Region</span> <span class="o">*</span><span class="p">,</span> <span class="n">RGPassManager</span> <span class="o">&</span><span class="n">RGM</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnRegion</span></code> method must be implemented by your subclass to do the
+transformation or analysis work of your pass. As usual, a true value should be
+returned if the region is modified. <code class="docutils literal notranslate"><span class="pre">RGPassManager</span></code> interface should be used to
+update region tree.</p>
+</div>
+<div class="section" id="id2">
+<h4><a class="toc-backref" href="#id29">The <code class="docutils literal notranslate"><span class="pre">doFinalization()</span></code> method</a><a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doFinalization</span><span class="p">();</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> method is an infrequently used method that is called
+when the pass framework has finished calling <a class="reference internal" href="#writing-an-llvm-pass-runonregion"><span class="std std-ref">runOnRegion</span></a> for every region in the program being
+compiled.</p>
+</div>
+</div>
+<div class="section" id="the-basicblockpass-class">
+<span id="writing-an-llvm-pass-basicblockpass"></span><h3><a class="toc-backref" href="#id30">The <code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code> class</a><a class="headerlink" href="#the-basicblockpass-class" title="Permalink to this headline">¶</a></h3>
+<p><code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code>es are just like <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPassâs</span></a> , except that they must limit their scope
+of inspection and modification to a single basic block at a time. As such,
+they are <strong>not</strong> allowed to do any of the following:</p>
+<ol class="arabic simple">
+<li>Modify or inspect any basic blocks outside of the current one.</li>
+<li>Maintain state across invocations of <a class="reference internal" href="#writing-an-llvm-pass-runonbasicblock"><span class="std std-ref">runOnBasicBlock</span></a>.</li>
+<li>Modify the control flow graph (by altering terminator instructions)</li>
+<li>Any of the things forbidden for <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPasses</span></a>.</li>
+</ol>
+<p><code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code>es are useful for traditional local and âpeepholeâ
+optimizations. They may override the same <a class="reference internal" href="#writing-an-llvm-pass-doinitialization-mod"><span class="std std-ref">doInitialization(Module &)</span></a> and <a class="reference internal" href="#writing-an-llvm-pass-dofinalization-mod"><span class="std std-ref">doFinalization(Module &)</span></a> methods that <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPassâs</span></a> have, but also have the following virtual
+methods that may also be implemented:</p>
+<div class="section" id="the-doinitialization-function-method">
+<h4><a class="toc-backref" href="#id31">The <code class="docutils literal notranslate"><span class="pre">doInitialization(Function</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-doinitialization-function-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doInitialization</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is allowed to do most of the things that
+<code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code>es are not allowed to do, but that <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>es
+can. The <code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method is designed to do simple initialization
+that does not depend on the <code class="docutils literal notranslate"><span class="pre">BasicBlock</span></code>s being processed. The
+<code class="docutils literal notranslate"><span class="pre">doInitialization</span></code> method call is not scheduled to overlap with any other
+pass executions (thus it should be very fast).</p>
+</div>
+<div class="section" id="the-runonbasicblock-method">
+<span id="writing-an-llvm-pass-runonbasicblock"></span><h4><a class="toc-backref" href="#id32">The <code class="docutils literal notranslate"><span class="pre">runOnBasicBlock</span></code> method</a><a class="headerlink" href="#the-runonbasicblock-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnBasicBlock</span><span class="p">(</span><span class="n">BasicBlock</span> <span class="o">&</span><span class="n">BB</span><span class="p">)</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>Override this function to do the work of the <code class="docutils literal notranslate"><span class="pre">BasicBlockPass</span></code>. This function
+is not allowed to inspect or modify basic blocks other than the parameter, and
+are not allowed to modify the CFG. A <code class="docutils literal notranslate"><span class="pre">true</span></code> value must be returned if the
+basic block is modified.</p>
+</div>
+<div class="section" id="the-dofinalization-function-method">
+<h4><a class="toc-backref" href="#id33">The <code class="docutils literal notranslate"><span class="pre">doFinalization(Function</span> <span class="pre">&)</span></code> method</a><a class="headerlink" href="#the-dofinalization-function-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">doFinalization</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">doFinalization</span></code> method is an infrequently used method that is called
+when the pass framework has finished calling <a class="reference internal" href="#writing-an-llvm-pass-runonbasicblock"><span class="std std-ref">runOnBasicBlock</span></a> for every <code class="docutils literal notranslate"><span class="pre">BasicBlock</span></code> in the program
+being compiled. This can be used to perform per-function finalization.</p>
+</div>
+</div>
+<div class="section" id="the-machinefunctionpass-class">
+<h3><a class="toc-backref" href="#id34">The <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> class</a><a class="headerlink" href="#the-machinefunctionpass-class" title="Permalink to this headline">¶</a></h3>
+<p>A <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> is a part of the LLVM code generator that executes on
+the machine-dependent representation of each LLVM function in the program.</p>
+<p>Code generator passes are registered and initialized specially by
+<code class="docutils literal notranslate"><span class="pre">TargetMachine::addPassesToEmitFile</span></code> and similar routines, so they cannot
+generally be run from the <strong class="program">opt</strong> or <strong class="program">bugpoint</strong> commands.</p>
+<p>A <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> is also a <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code>, so all the restrictions
+that apply to a <code class="docutils literal notranslate"><span class="pre">FunctionPass</span></code> also apply to it. <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>es
+also have additional restrictions. In particular, <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>es
+are not allowed to do any of the following:</p>
+<ol class="arabic simple">
+<li>Modify or create any LLVM IR <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>s, <code class="docutils literal notranslate"><span class="pre">BasicBlock</span></code>s,
+<code class="docutils literal notranslate"><span class="pre">Argument</span></code>s, <code class="docutils literal notranslate"><span class="pre">Function</span></code>s, <code class="docutils literal notranslate"><span class="pre">GlobalVariable</span></code>s,
+<code class="docutils literal notranslate"><span class="pre">GlobalAlias</span></code>es, or <code class="docutils literal notranslate"><span class="pre">Module</span></code>s.</li>
+<li>Modify a <code class="docutils literal notranslate"><span class="pre">MachineFunction</span></code> other than the one currently being processed.</li>
+<li>Maintain state across invocations of <a class="reference internal" href="#writing-an-llvm-pass-runonmachinefunction"><span class="std std-ref">runOnMachineFunction</span></a> (including global data).</li>
+</ol>
+<div class="section" id="the-runonmachinefunction-machinefunction-mf-method">
+<span id="writing-an-llvm-pass-runonmachinefunction"></span><h4><a class="toc-backref" href="#id35">The <code class="docutils literal notranslate"><span class="pre">runOnMachineFunction(MachineFunction</span> <span class="pre">&MF)</span></code> method</a><a class="headerlink" href="#the-runonmachinefunction-machinefunction-mf-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">bool</span> <span class="nf">runOnMachineFunction</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="o">=</span> <span class="mi">0</span><span class="p">;</span>
+</pre></div>
+</div>
+<p><code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code> can be considered the main entry point of a
+<code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>; that is, you should override this method to do the
+work of your <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">runOnMachineFunction</span></code> method is called on every <code class="docutils literal notranslate"><span class="pre">MachineFunction</span></code> in a
+<code class="docutils literal notranslate"><span class="pre">Module</span></code>, so that the <code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code> may perform optimizations on
+the machine-dependent representation of the function. If you want to get at
+the LLVM <code class="docutils literal notranslate"><span class="pre">Function</span></code> for the <code class="docutils literal notranslate"><span class="pre">MachineFunction</span></code> youâre working on, use
+<code class="docutils literal notranslate"><span class="pre">MachineFunction</span></code>âs <code class="docutils literal notranslate"><span class="pre">getFunction()</span></code> accessor method â but remember, you
+may not modify the LLVM <code class="docutils literal notranslate"><span class="pre">Function</span></code> or its contents from a
+<code class="docutils literal notranslate"><span class="pre">MachineFunctionPass</span></code>.</p>
+</div>
+</div>
+<div class="section" id="pass-registration">
+<span id="writing-an-llvm-pass-registration"></span><h3><a class="toc-backref" href="#id36">Pass registration</a><a class="headerlink" href="#pass-registration" title="Permalink to this headline">¶</a></h3>
+<p>In the <a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello World</span></a> example pass we
+illustrated how pass registration works, and discussed some of the reasons that
+it is used and what it does. Here we discuss how and why passes are
+registered.</p>
+<p>As we saw above, passes are registered with the <code class="docutils literal notranslate"><span class="pre">RegisterPass</span></code> template. The
+template parameter is the name of the pass that is to be used on the command
+line to specify that the pass should be added to a program (for example, with
+<strong class="program">opt</strong> or <strong class="program">bugpoint</strong>). The first argument is the name of the
+pass, which is to be used for the <a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-help"><code class="xref std std-option docutils literal notranslate"><span class="pre">-help</span></code></a> output of programs, as well
+as for debug output generated by the <cite>âdebug-pass</cite> option.</p>
+<p>If you want your pass to be easily dumpable, you should implement the virtual
+print method:</p>
+<div class="section" id="the-print-method">
+<h4><a class="toc-backref" href="#id37">The <code class="docutils literal notranslate"><span class="pre">print</span></code> method</a><a class="headerlink" href="#the-print-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">void</span> <span class="nf">print</span><span class="p">(</span><span class="n">llvm</span><span class="o">::</span><span class="n">raw_ostream</span> <span class="o">&</span><span class="n">O</span><span class="p">,</span> <span class="k">const</span> <span class="n">Module</span> <span class="o">*</span><span class="n">M</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">print</span></code> method must be implemented by âanalysesâ in order to print a
+human readable version of the analysis results. This is useful for debugging
+an analysis itself, as well as for other people to figure out how an analysis
+works. Use the opt <code class="docutils literal notranslate"><span class="pre">-analyze</span></code> argument to invoke this method.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">llvm::raw_ostream</span></code> parameter specifies the stream to write the results
+on, and the <code class="docutils literal notranslate"><span class="pre">Module</span></code> parameter gives a pointer to the top level module of the
+program that has been analyzed. Note however that this pointer may be <code class="docutils literal notranslate"><span class="pre">NULL</span></code>
+in certain circumstances (such as calling the <code class="docutils literal notranslate"><span class="pre">Pass::dump()</span></code> from a
+debugger), so it should only be used to enhance debug output, it should not be
+depended on.</p>
+</div>
+</div>
+<div class="section" id="specifying-interactions-between-passes">
+<span id="writing-an-llvm-pass-interaction"></span><h3><a class="toc-backref" href="#id38">Specifying interactions between passes</a><a class="headerlink" href="#specifying-interactions-between-passes" title="Permalink to this headline">¶</a></h3>
+<p>One of the main responsibilities of the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> is to make sure that
+passes interact with each other correctly. Because <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> tries to
+<a class="reference internal" href="#writing-an-llvm-pass-passmanager"><span class="std std-ref">optimize the execution of passes</span></a> it
+must know how the passes interact with each other and what dependencies exist
+between the various passes. To track this, each pass can declare the set of
+passes that are required to be executed before the current pass, and the passes
+which are invalidated by the current pass.</p>
+<p>Typically this functionality is used to require that analysis results are
+computed before your pass is run. Running arbitrary transformation passes can
+invalidate the computed analysis results, which is what the invalidation set
+specifies. If a pass does not implement the <a class="reference internal" href="#writing-an-llvm-pass-getanalysisusage"><span class="std std-ref">getAnalysisUsage</span></a> method, it defaults to not having any
+prerequisite passes, and invalidating <strong>all</strong> other passes.</p>
+<div class="section" id="the-getanalysisusage-method">
+<span id="writing-an-llvm-pass-getanalysisusage"></span><h4><a class="toc-backref" href="#id39">The <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code> method</a><a class="headerlink" href="#the-getanalysisusage-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">void</span> <span class="nf">getAnalysisUsage</span><span class="p">(</span><span class="n">AnalysisUsage</span> <span class="o">&</span><span class="n">Info</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>By implementing the <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code> method, the required and invalidated
+sets may be specified for your transformation. The implementation should fill
+in the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AnalysisUsage.html">AnalysisUsage</a> object with
+information about which passes are required and not invalidated. To do this, a
+pass may call any of the following methods on the <code class="docutils literal notranslate"><span class="pre">AnalysisUsage</span></code> object:</p>
+</div>
+<div class="section" id="the-analysisusage-addrequired-and-analysisusage-addrequiredtransitive-methods">
+<h4><a class="toc-backref" href="#id40">The <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addRequired<></span></code> and <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addRequiredTransitive<></span></code> methods</a><a class="headerlink" href="#the-analysisusage-addrequired-and-analysisusage-addrequiredtransitive-methods" title="Permalink to this headline">¶</a></h4>
+<p>If your pass requires a previous pass to be executed (an analysis for example),
+it can use one of these methods to arrange for it to be run before your pass.
+LLVM has many different types of analyses and passes that can be required,
+spanning the range from <code class="docutils literal notranslate"><span class="pre">DominatorSet</span></code> to <code class="docutils literal notranslate"><span class="pre">BreakCriticalEdges</span></code>. Requiring
+<code class="docutils literal notranslate"><span class="pre">BreakCriticalEdges</span></code>, for example, guarantees that there will be no critical
+edges in the CFG when your pass has been run.</p>
+<p>Some analyses chain to other analyses to do their job. For example, an
+<cite>AliasAnalysis <AliasAnalysis></cite> implementation is required to <a class="reference internal" href="AliasAnalysis.html#aliasanalysis-chaining"><span class="std std-ref">chain</span></a> to other alias analysis passes. In cases where
+analyses chain, the <code class="docutils literal notranslate"><span class="pre">addRequiredTransitive</span></code> method should be used instead of
+the <code class="docutils literal notranslate"><span class="pre">addRequired</span></code> method. This informs the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> that the
+transitively required pass should be alive as long as the requiring pass is.</p>
+</div>
+<div class="section" id="the-analysisusage-addpreserved-method">
+<h4><a class="toc-backref" href="#id41">The <code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addPreserved<></span></code> method</a><a class="headerlink" href="#the-analysisusage-addpreserved-method" title="Permalink to this headline">¶</a></h4>
+<p>One of the jobs of the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> is to optimize how and when analyses are
+run. In particular, it attempts to avoid recomputing data unless it needs to.
+For this reason, passes are allowed to declare that they preserve (i.e., they
+donât invalidate) an existing analysis if itâs available. For example, a
+simple constant folding pass would not modify the CFG, so it canât possibly
+affect the results of dominator analysis. By default, all passes are assumed
+to invalidate all others.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">AnalysisUsage</span></code> class provides several methods which are useful in
+certain circumstances that are related to <code class="docutils literal notranslate"><span class="pre">addPreserved</span></code>. In particular, the
+<code class="docutils literal notranslate"><span class="pre">setPreservesAll</span></code> method can be called to indicate that the pass does not
+modify the LLVM program at all (which is true for analyses), and the
+<code class="docutils literal notranslate"><span class="pre">setPreservesCFG</span></code> method can be used by transformations that change
+instructions in the program but do not modify the CFG or terminator
+instructions (note that this property is implicitly set for
+<a class="reference internal" href="#writing-an-llvm-pass-basicblockpass"><span class="std std-ref">BasicBlockPass</span></a>es).</p>
+<p><code class="docutils literal notranslate"><span class="pre">addPreserved</span></code> is particularly useful for transformations like
+<code class="docutils literal notranslate"><span class="pre">BreakCriticalEdges</span></code>. This pass knows how to update a small set of loop and
+dominator related analyses if they exist, so it can preserve them, despite the
+fact that it hacks on the CFG.</p>
+</div>
+<div class="section" id="example-implementations-of-getanalysisusage">
+<h4><a class="toc-backref" href="#id42">Example implementations of <code class="docutils literal notranslate"><span class="pre">getAnalysisUsage</span></code></a><a class="headerlink" href="#example-implementations-of-getanalysisusage" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="c1">// This example modifies the program, but does not modify the CFG</span>
+<span class="kt">void</span> <span class="n">LICM</span><span class="o">::</span><span class="n">getAnalysisUsage</span><span class="p">(</span><span class="n">AnalysisUsage</span> <span class="o">&</span><span class="n">AU</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
+ <span class="n">AU</span><span class="p">.</span><span class="n">setPreservesCFG</span><span class="p">();</span>
+ <span class="n">AU</span><span class="p">.</span><span class="n">addRequired</span><span class="o"><</span><span class="n">LoopInfoWrapperPass</span><span class="o">></span><span class="p">();</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="the-getanalysis-and-getanalysisifavailable-methods">
+<span id="writing-an-llvm-pass-getanalysis"></span><h4><a class="toc-backref" href="#id43">The <code class="docutils literal notranslate"><span class="pre">getAnalysis<></span></code> and <code class="docutils literal notranslate"><span class="pre">getAnalysisIfAvailable<></span></code> methods</a><a class="headerlink" href="#the-getanalysis-and-getanalysisifavailable-methods" title="Permalink to this headline">¶</a></h4>
+<p>The <code class="docutils literal notranslate"><span class="pre">Pass::getAnalysis<></span></code> method is automatically inherited by your class,
+providing you with access to the passes that you declared that you required
+with the <a class="reference internal" href="#writing-an-llvm-pass-getanalysisusage"><span class="std std-ref">getAnalysisUsage</span></a>
+method. It takes a single template argument that specifies which pass class
+you want, and returns a reference to that pass. For example:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">bool</span> <span class="n">LICM</span><span class="o">::</span><span class="n">runOnFunction</span><span class="p">(</span><span class="n">Function</span> <span class="o">&</span><span class="n">F</span><span class="p">)</span> <span class="p">{</span>
+ <span class="n">LoopInfo</span> <span class="o">&</span><span class="n">LI</span> <span class="o">=</span> <span class="n">getAnalysis</span><span class="o"><</span><span class="n">LoopInfoWrapperPass</span><span class="o">></span><span class="p">().</span><span class="n">getLoopInfo</span><span class="p">();</span>
+ <span class="c1">//...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This method call returns a reference to the pass desired. You may get a
+runtime assertion failure if you attempt to get an analysis that you did not
+declare as required in your <a class="reference internal" href="#writing-an-llvm-pass-getanalysisusage"><span class="std std-ref">getAnalysisUsage</span></a> implementation. This method can be
+called by your <code class="docutils literal notranslate"><span class="pre">run*</span></code> method implementation, or by any other local method
+invoked by your <code class="docutils literal notranslate"><span class="pre">run*</span></code> method.</p>
+<p>A module level pass can use function level analysis info using this interface.
+For example:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="kt">bool</span> <span class="n">ModuleLevelPass</span><span class="o">::</span><span class="n">runOnModule</span><span class="p">(</span><span class="n">Module</span> <span class="o">&</span><span class="n">M</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">//...</span>
+ <span class="n">DominatorTree</span> <span class="o">&</span><span class="n">DT</span> <span class="o">=</span> <span class="n">getAnalysis</span><span class="o"><</span><span class="n">DominatorTree</span><span class="o">></span><span class="p">(</span><span class="n">Func</span><span class="p">);</span>
+ <span class="c1">//...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In above example, <code class="docutils literal notranslate"><span class="pre">runOnFunction</span></code> for <code class="docutils literal notranslate"><span class="pre">DominatorTree</span></code> is called by pass
+manager before returning a reference to the desired pass.</p>
+<p>If your pass is capable of updating analyses if they exist (e.g.,
+<code class="docutils literal notranslate"><span class="pre">BreakCriticalEdges</span></code>, as described above), you can use the
+<code class="docutils literal notranslate"><span class="pre">getAnalysisIfAvailable</span></code> method, which returns a pointer to the analysis if
+it is active. For example:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">DominatorSet</span> <span class="o">*</span><span class="n">DS</span> <span class="o">=</span> <span class="n">getAnalysisIfAvailable</span><span class="o"><</span><span class="n">DominatorSet</span><span class="o">></span><span class="p">())</span> <span class="p">{</span>
+ <span class="c1">// A DominatorSet is active. This code will update it.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="implementing-analysis-groups">
+<h3><a class="toc-backref" href="#id44">Implementing Analysis Groups</a><a class="headerlink" href="#implementing-analysis-groups" title="Permalink to this headline">¶</a></h3>
+<p>Now that we understand the basics of how passes are defined, how they are used,
+and how they are required from other passes, itâs time to get a little bit
+fancier. All of the pass relationships that we have seen so far are very
+simple: one pass depends on one other specific pass to be run before it can
+run. For many applications, this is great, for others, more flexibility is
+required.</p>
+<p>In particular, some analyses are defined such that there is a single simple
+interface to the analysis results, but multiple ways of calculating them.
+Consider alias analysis for example. The most trivial alias analysis returns
+âmay aliasâ for any alias query. The most sophisticated analysis a
+flow-sensitive, context-sensitive interprocedural analysis that can take a
+significant amount of time to execute (and obviously, there is a lot of room
+between these two extremes for other implementations). To cleanly support
+situations like this, the LLVM Pass Infrastructure supports the notion of
+Analysis Groups.</p>
+<div class="section" id="analysis-group-concepts">
+<h4><a class="toc-backref" href="#id45">Analysis Group Concepts</a><a class="headerlink" href="#analysis-group-concepts" title="Permalink to this headline">¶</a></h4>
+<p>An Analysis Group is a single simple interface that may be implemented by
+multiple different passes. Analysis Groups can be given human readable names
+just like passes, but unlike passes, they need not derive from the <code class="docutils literal notranslate"><span class="pre">Pass</span></code>
+class. An analysis group may have one or more implementations, one of which is
+the âdefaultâ implementation.</p>
+<p>Analysis groups are used by client passes just like other passes are: the
+<code class="docutils literal notranslate"><span class="pre">AnalysisUsage::addRequired()</span></code> and <code class="docutils literal notranslate"><span class="pre">Pass::getAnalysis()</span></code> methods. In order
+to resolve this requirement, the <a class="reference internal" href="#writing-an-llvm-pass-passmanager"><span class="std std-ref">PassManager</span></a> scans the available passes to see if any
+implementations of the analysis group are available. If none is available, the
+default implementation is created for the pass to use. All standard rules for
+<a class="reference internal" href="#writing-an-llvm-pass-interaction"><span class="std std-ref">interaction between passes</span></a> still
+apply.</p>
+<p>Although <a class="reference internal" href="#writing-an-llvm-pass-registration"><span class="std std-ref">Pass Registration</span></a> is
+optional for normal passes, all analysis group implementations must be
+registered, and must use the <a class="reference internal" href="#writing-an-llvm-pass-registeranalysisgroup"><span class="std std-ref">INITIALIZE_AG_PASS</span></a> template to join the
+implementation pool. Also, a default implementation of the interface <strong>must</strong>
+be registered with <a class="reference internal" href="#writing-an-llvm-pass-registeranalysisgroup"><span class="std std-ref">RegisterAnalysisGroup</span></a>.</p>
+<p>As a concrete example of an Analysis Group in action, consider the
+<a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>
+analysis group. The default implementation of the alias analysis interface
+(the <a class="reference external" href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">basicaa</a> pass)
+just does a few simple checks that donât require significant analysis to
+compute (such as: two different globals can never alias each other, etc).
+Passes that use the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> interface (for
+example the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1GVN.html">gvn</a> pass), do not
+care which implementation of alias analysis is actually provided, they just use
+the designated interface.</p>
+<p>From the userâs perspective, commands work just like normal. Issuing the
+command <code class="docutils literal notranslate"><span class="pre">opt</span> <span class="pre">-gvn</span> <span class="pre">...</span></code> will cause the <code class="docutils literal notranslate"><span class="pre">basicaa</span></code> class to be instantiated
+and added to the pass sequence. Issuing the command <code class="docutils literal notranslate"><span class="pre">opt</span> <span class="pre">-somefancyaa</span> <span class="pre">-gvn</span>
+<span class="pre">...</span></code> will cause the <code class="docutils literal notranslate"><span class="pre">gvn</span></code> pass to use the <code class="docutils literal notranslate"><span class="pre">somefancyaa</span></code> alias analysis
+(which doesnât actually exist, itâs just a hypothetical example) instead.</p>
+</div>
+<div class="section" id="using-registeranalysisgroup">
+<span id="writing-an-llvm-pass-registeranalysisgroup"></span><h4><a class="toc-backref" href="#id46">Using <code class="docutils literal notranslate"><span class="pre">RegisterAnalysisGroup</span></code></a><a class="headerlink" href="#using-registeranalysisgroup" title="Permalink to this headline">¶</a></h4>
+<p>The <code class="docutils literal notranslate"><span class="pre">RegisterAnalysisGroup</span></code> template is used to register the analysis group
+itself, while the <code class="docutils literal notranslate"><span class="pre">INITIALIZE_AG_PASS</span></code> is used to add pass implementations to
+the analysis group. First, an analysis group should be registered, with a
+human readable name provided for it. Unlike registration of passes, there is
+no command line argument to be specified for the Analysis Group Interface
+itself, because it is âabstractâ:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="n">RegisterAnalysisGroup</span><span class="o"><</span><span class="n">AliasAnalysis</span><span class="o">></span> <span class="n">A</span><span class="p">(</span><span class="s">"Alias Analysis"</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>Once the analysis is registered, passes can declare that they are valid
+implementations of the interface by using the following code:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">namespace</span> <span class="p">{</span>
+ <span class="c1">// Declare that we implement the AliasAnalysis interface</span>
+ <span class="n">INITIALIZE_AG_PASS</span><span class="p">(</span><span class="n">FancyAA</span><span class="p">,</span> <span class="n">AliasAnalysis</span> <span class="p">,</span> <span class="s">"somefancyaa"</span><span class="p">,</span>
+ <span class="s">"A more complex alias analysis implementation"</span><span class="p">,</span>
+ <span class="nb">false</span><span class="p">,</span> <span class="c1">// Is CFG Only?</span>
+ <span class="nb">true</span><span class="p">,</span> <span class="c1">// Is Analysis?</span>
+ <span class="nb">false</span><span class="p">);</span> <span class="c1">// Is default Analysis Group implementation?</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>This just shows a class <code class="docutils literal notranslate"><span class="pre">FancyAA</span></code> that uses the <code class="docutils literal notranslate"><span class="pre">INITIALIZE_AG_PASS</span></code> macro
+both to register and to âjoinâ the <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> analysis group.
+Every implementation of an analysis group should join using this macro.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">namespace</span> <span class="p">{</span>
+ <span class="c1">// Declare that we implement the AliasAnalysis interface</span>
+ <span class="n">INITIALIZE_AG_PASS</span><span class="p">(</span><span class="n">BasicAA</span><span class="p">,</span> <span class="n">AliasAnalysis</span><span class="p">,</span> <span class="s">"basicaa"</span><span class="p">,</span>
+ <span class="s">"Basic Alias Analysis (default AA impl)"</span><span class="p">,</span>
+ <span class="nb">false</span><span class="p">,</span> <span class="c1">// Is CFG Only?</span>
+ <span class="nb">true</span><span class="p">,</span> <span class="c1">// Is Analysis?</span>
+ <span class="nb">true</span><span class="p">);</span> <span class="c1">// Is default Analysis Group implementation?</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Here we show how the default implementation is specified (using the final
+argument to the <code class="docutils literal notranslate"><span class="pre">INITIALIZE_AG_PASS</span></code> template). There must be exactly one
+default implementation available at all times for an Analysis Group to be used.
+Only default implementation can derive from <code class="docutils literal notranslate"><span class="pre">ImmutablePass</span></code>. Here we declare
+that the <a class="reference external" href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a> pass is the default
+implementation for the interface.</p>
+</div>
+</div>
+</div>
+<div class="section" id="pass-statistics">
+<h2><a class="toc-backref" href="#id47">Pass Statistics</a><a class="headerlink" href="#pass-statistics" title="Permalink to this headline">¶</a></h2>
+<p>The <a class="reference external" href="http://llvm.org/doxygen/Statistic_8h_source.html">Statistic</a> class is
+designed to be an easy way to expose various success metrics from passes.
+These statistics are printed at the end of a run, when the <a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-stats"><code class="xref std std-option docutils literal notranslate"><span class="pre">-stats</span></code></a>
+command line option is enabled on the command line. See the <a class="reference internal" href="ProgrammersManual.html#statistic"><span class="std std-ref">Statistics
+section</span></a> in the Programmerâs Manual for details.</p>
+<div class="section" id="what-passmanager-does">
+<span id="writing-an-llvm-pass-passmanager"></span><h3><a class="toc-backref" href="#id48">What PassManager does</a><a class="headerlink" href="#what-passmanager-does" title="Permalink to this headline">¶</a></h3>
+<p>The <a class="reference external" href="http://llvm.org/doxygen/PassManager_8h_source.html">PassManager</a> <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1PassManager.html">class</a> takes a list of
+passes, ensures their <a class="reference internal" href="#writing-an-llvm-pass-interaction"><span class="std std-ref">prerequisites</span></a>
+are set up correctly, and then schedules passes to run efficiently. All of the
+LLVM tools that run passes use the PassManager for execution of these passes.</p>
+<p>The PassManager does two main things to try to reduce the execution time of a
+series of passes:</p>
+<ol class="arabic">
+<li><p class="first"><strong>Share analysis results.</strong> The <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> attempts to avoid
+recomputing analysis results as much as possible. This means keeping track
+of which analyses are available already, which analyses get invalidated, and
+which analyses are needed to be run for a pass. An important part of work
+is that the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> tracks the exact lifetime of all analysis
+results, allowing it to <a class="reference internal" href="#writing-an-llvm-pass-releasememory"><span class="std std-ref">free memory</span></a> allocated to holding analysis results
+as soon as they are no longer needed.</p>
+</li>
+<li><p class="first"><strong>Pipeline the execution of passes on the program.</strong> The <code class="docutils literal notranslate"><span class="pre">PassManager</span></code>
+attempts to get better cache and memory usage behavior out of a series of
+passes by pipelining the passes together. This means that, given a series
+of consecutive <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a>, it
+will execute all of the <a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPass</span></a> on the first function, then all of the
+<a class="reference internal" href="#writing-an-llvm-pass-functionpass"><span class="std std-ref">FunctionPasses</span></a> on the second
+function, etc⦠until the entire program has been run through the passes.</p>
+<p>This improves the cache behavior of the compiler, because it is only
+touching the LLVM program representation for a single function at a time,
+instead of traversing the entire program. It reduces the memory consumption
+of compiler, because, for example, only one <a class="reference external" href="http://llvm.org/doxygen/classllvm_1_1DominatorSet.html">DominatorSet</a> needs to be
+calculated at a time. This also makes it possible to implement some
+<a class="reference internal" href="#writing-an-llvm-pass-smp"><span class="std std-ref">interesting enhancements</span></a> in the future.</p>
+</li>
+</ol>
+<p>The effectiveness of the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> is influenced directly by how much
+information it has about the behaviors of the passes it is scheduling. For
+example, the âpreservedâ set is intentionally conservative in the face of an
+unimplemented <a class="reference internal" href="#writing-an-llvm-pass-getanalysisusage"><span class="std std-ref">getAnalysisUsage</span></a>
+method. Not implementing when it should be implemented will have the effect of
+not allowing any analysis results to live across the execution of your pass.</p>
+<p>The <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> class exposes a <code class="docutils literal notranslate"><span class="pre">--debug-pass</span></code> command line options that
+is useful for debugging pass execution, seeing how things work, and diagnosing
+when you should be preserving more analyses than you currently are. (To get
+information about all of the variants of the <code class="docutils literal notranslate"><span class="pre">--debug-pass</span></code> option, just type
+â<code class="docutils literal notranslate"><span class="pre">opt</span> <span class="pre">-help-hidden</span></code>â).</p>
+<p>By using the âdebug-pass=Structure option, for example, we can see how our
+<a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello World</span></a> pass interacts with other
+passes. Lets try it out with the gvn and licm passes:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -gvn -licm --debug-pass<span class="o">=</span>Structure < hello.bc > /dev/null
+<span class="go">ModulePass Manager</span>
+<span class="go"> FunctionPass Manager</span>
+<span class="go"> Dominator Tree Construction</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Memory Dependence Analysis</span>
+<span class="go"> Global Value Numbering</span>
+<span class="go"> Natural Loop Information</span>
+<span class="go"> Canonicalize natural loops</span>
+<span class="go"> Loop-Closed SSA Form Pass</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Scalar Evolution Analysis</span>
+<span class="go"> Loop Pass Manager</span>
+<span class="go"> Loop Invariant Code Motion</span>
+<span class="go"> Module Verifier</span>
+<span class="go"> Bitcode Writer</span>
+</pre></div>
+</div>
+<p>This output shows us when passes are constructed.
+Here we see that GVN uses dominator tree information to do its job. The LICM pass
+uses natural loop information, which uses dominator tree as well.</p>
+<p>After the LICM pass, the module verifier runs (which is automatically added by
+the <strong class="program">opt</strong> tool), which uses the dominator tree to check that the
+resultant LLVM code is well formed. Note that the dominator tree is computed
+once, and shared by three passes.</p>
+<p>Lets see how this changes when we run the <a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello World</span></a> pass in between the two passes:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -gvn -hello -licm --debug-pass<span class="o">=</span>Structure < hello.bc > /dev/null
+<span class="go">ModulePass Manager</span>
+<span class="go"> FunctionPass Manager</span>
+<span class="go"> Dominator Tree Construction</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Memory Dependence Analysis</span>
+<span class="go"> Global Value Numbering</span>
+<span class="go"> Hello World Pass</span>
+<span class="go"> Dominator Tree Construction</span>
+<span class="go"> Natural Loop Information</span>
+<span class="go"> Canonicalize natural loops</span>
+<span class="go"> Loop-Closed SSA Form Pass</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Scalar Evolution Analysis</span>
+<span class="go"> Loop Pass Manager</span>
+<span class="go"> Loop Invariant Code Motion</span>
+<span class="go"> Module Verifier</span>
+<span class="go"> Bitcode Writer</span>
+<span class="go">Hello: __main</span>
+<span class="go">Hello: puts</span>
+<span class="go">Hello: main</span>
+</pre></div>
+</div>
+<p>Here we see that the <a class="reference internal" href="#writing-an-llvm-pass-basiccode"><span class="std std-ref">Hello World</span></a> pass
+has killed the Dominator Tree pass, even though it doesnât modify the code at
+all! To fix this, we need to add the following <a class="reference internal" href="#writing-an-llvm-pass-getanalysisusage"><span class="std std-ref">getAnalysisUsage</span></a> method to our pass:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="c1">// We don't modify the program, so we preserve all analyses</span>
+<span class="kt">void</span> <span class="nf">getAnalysisUsage</span><span class="p">(</span><span class="n">AnalysisUsage</span> <span class="o">&</span><span class="n">AU</span><span class="p">)</span> <span class="k">const</span> <span class="k">override</span> <span class="p">{</span>
+ <span class="n">AU</span><span class="p">.</span><span class="n">setPreservesAll</span><span class="p">();</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Now when we run our pass, we get this output:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> opt -load lib/LLVMHello.so -gvn -hello -licm --debug-pass<span class="o">=</span>Structure < hello.bc > /dev/null
+<span class="go">Pass Arguments: -gvn -hello -licm</span>
+<span class="go">ModulePass Manager</span>
+<span class="go"> FunctionPass Manager</span>
+<span class="go"> Dominator Tree Construction</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Memory Dependence Analysis</span>
+<span class="go"> Global Value Numbering</span>
+<span class="go"> Hello World Pass</span>
+<span class="go"> Natural Loop Information</span>
+<span class="go"> Canonicalize natural loops</span>
+<span class="go"> Loop-Closed SSA Form Pass</span>
+<span class="go"> Basic Alias Analysis (stateless AA impl)</span>
+<span class="go"> Function Alias Analysis Results</span>
+<span class="go"> Scalar Evolution Analysis</span>
+<span class="go"> Loop Pass Manager</span>
+<span class="go"> Loop Invariant Code Motion</span>
+<span class="go"> Module Verifier</span>
+<span class="go"> Bitcode Writer</span>
+<span class="go">Hello: __main</span>
+<span class="go">Hello: puts</span>
+<span class="go">Hello: main</span>
+</pre></div>
+</div>
+<p>Which shows that we donât accidentally invalidate dominator information
+anymore, and therefore do not have to compute it twice.</p>
+<div class="section" id="the-releasememory-method">
+<span id="writing-an-llvm-pass-releasememory"></span><h4><a class="toc-backref" href="#id49">The <code class="docutils literal notranslate"><span class="pre">releaseMemory</span></code> method</a><a class="headerlink" href="#the-releasememory-method" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">virtual</span> <span class="kt">void</span> <span class="nf">releaseMemory</span><span class="p">();</span>
+</pre></div>
+</div>
+<p>The <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> automatically determines when to compute analysis results,
+and how long to keep them around for. Because the lifetime of the pass object
+itself is effectively the entire duration of the compilation process, we need
+some way to free analysis results when they are no longer useful. The
+<code class="docutils literal notranslate"><span class="pre">releaseMemory</span></code> virtual method is the way to do this.</p>
+<p>If you are writing an analysis or any other pass that retains a significant
+amount of state (for use by another pass which ârequiresâ your pass and uses
+the <a class="reference internal" href="#writing-an-llvm-pass-getanalysis"><span class="std std-ref">getAnalysis</span></a> method) you should
+implement <code class="docutils literal notranslate"><span class="pre">releaseMemory</span></code> to, well, release the memory allocated to maintain
+this internal state. This method is called after the <code class="docutils literal notranslate"><span class="pre">run*</span></code> method for the
+class, before the next call of <code class="docutils literal notranslate"><span class="pre">run*</span></code> in your pass.</p>
+</div>
+</div>
+</div>
+<div class="section" id="registering-dynamically-loaded-passes">
+<h2><a class="toc-backref" href="#id50">Registering dynamically loaded passes</a><a class="headerlink" href="#registering-dynamically-loaded-passes" title="Permalink to this headline">¶</a></h2>
+<p><em>Size matters</em> when constructing production quality tools using LLVM, both for
+the purposes of distribution, and for regulating the resident code size when
+running on the target system. Therefore, it becomes desirable to selectively
+use some passes, while omitting others and maintain the flexibility to change
+configurations later on. You want to be able to do all this, and, provide
+feedback to the user. This is where pass registration comes into play.</p>
+<p>The fundamental mechanisms for pass registration are the
+<code class="docutils literal notranslate"><span class="pre">MachinePassRegistry</span></code> class and subclasses of <code class="docutils literal notranslate"><span class="pre">MachinePassRegistryNode</span></code>.</p>
+<p>An instance of <code class="docutils literal notranslate"><span class="pre">MachinePassRegistry</span></code> is used to maintain a list of
+<code class="docutils literal notranslate"><span class="pre">MachinePassRegistryNode</span></code> objects. This instance maintains the list and
+communicates additions and deletions to the command line interface.</p>
+<p>An instance of <code class="docutils literal notranslate"><span class="pre">MachinePassRegistryNode</span></code> subclass is used to maintain
+information provided about a particular pass. This information includes the
+command line name, the command help string and the address of the function used
+to create an instance of the pass. A global static constructor of one of these
+instances <em>registers</em> with a corresponding <code class="docutils literal notranslate"><span class="pre">MachinePassRegistry</span></code>, the static
+destructor <em>unregisters</em>. Thus a pass that is statically linked in the tool
+will be registered at start up. A dynamically loaded pass will register on
+load and unregister at unload.</p>
+<div class="section" id="using-existing-registries">
+<h3><a class="toc-backref" href="#id51">Using existing registries</a><a class="headerlink" href="#using-existing-registries" title="Permalink to this headline">¶</a></h3>
+<p>There are predefined registries to track instruction scheduling
+(<code class="docutils literal notranslate"><span class="pre">RegisterScheduler</span></code>) and register allocation (<code class="docutils literal notranslate"><span class="pre">RegisterRegAlloc</span></code>) machine
+passes. Here we will describe how to <em>register</em> a register allocator machine
+pass.</p>
+<p>Implement your register allocator machine pass. In your register allocator
+<code class="docutils literal notranslate"><span class="pre">.cpp</span></code> file add the following include:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="cp">#include</span> <span class="cpf">"llvm/CodeGen/RegAllocRegistry.h"</span><span class="cp"></span>
+</pre></div>
+</div>
+<p>Also in your register allocator <code class="docutils literal notranslate"><span class="pre">.cpp</span></code> file, define a creator function in the
+form:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">FunctionPass</span> <span class="o">*</span><span class="nf">createMyRegisterAllocator</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="k">new</span> <span class="n">MyRegisterAllocator</span><span class="p">();</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Note that the signature of this function should match the type of
+<code class="docutils literal notranslate"><span class="pre">RegisterRegAlloc::FunctionPassCtor</span></code>. In the same file add the âinstallingâ
+declaration, in the form:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span> <span class="n">RegisterRegAlloc</span> <span class="nf">myRegAlloc</span><span class="p">(</span><span class="s">"myregalloc"</span><span class="p">,</span>
+ <span class="s">"my register allocator help string"</span><span class="p">,</span>
+ <span class="n">createMyRegisterAllocator</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>Note the two spaces prior to the help string produces a tidy result on the
+<a class="reference internal" href="CommandGuide/opt.html#cmdoption-opt-help"><code class="xref std std-option docutils literal notranslate"><span class="pre">-help</span></code></a> query.</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> llc -help
+<span class="go"> ...</span>
+<span class="go"> -regalloc - Register allocator to use (default=linearscan)</span>
+<span class="go"> =linearscan - linear scan register allocator</span>
+<span class="go"> =local - local register allocator</span>
+<span class="go"> =simple - simple register allocator</span>
+<span class="go"> =myregalloc - my register allocator help string</span>
+<span class="go"> ...</span>
+</pre></div>
+</div>
+<p>And thatâs it. The user is now free to use <code class="docutils literal notranslate"><span class="pre">-regalloc=myregalloc</span></code> as an
+option. Registering instruction schedulers is similar except use the
+<code class="docutils literal notranslate"><span class="pre">RegisterScheduler</span></code> class. Note that the
+<code class="docutils literal notranslate"><span class="pre">RegisterScheduler::FunctionPassCtor</span></code> is significantly different from
+<code class="docutils literal notranslate"><span class="pre">RegisterRegAlloc::FunctionPassCtor</span></code>.</p>
+<p>To force the load/linking of your register allocator into the
+<strong class="program">llc</strong>/<strong class="program">lli</strong> tools, add your creator functionâs global
+declaration to <code class="docutils literal notranslate"><span class="pre">Passes.h</span></code> and add a âpseudoâ call line to
+<code class="docutils literal notranslate"><span class="pre">llvm/Codegen/LinkAllCodegenComponents.h</span></code>.</p>
+</div>
+<div class="section" id="creating-new-registries">
+<h3><a class="toc-backref" href="#id52">Creating new registries</a><a class="headerlink" href="#creating-new-registries" title="Permalink to this headline">¶</a></h3>
+<p>The easiest way to get started is to clone one of the existing registries; we
+recommend <code class="docutils literal notranslate"><span class="pre">llvm/CodeGen/RegAllocRegistry.h</span></code>. The key things to modify are
+the class name and the <code class="docutils literal notranslate"><span class="pre">FunctionPassCtor</span></code> type.</p>
+<p>Then you need to declare the registry. Example: if your pass registry is
+<code class="docutils literal notranslate"><span class="pre">RegisterMyPasses</span></code> then define:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">MachinePassRegistry</span> <span class="n">RegisterMyPasses</span><span class="o">::</span><span class="n">Registry</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>And finally, declare the command line option for your passes. Example:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="n">cl</span><span class="o">::</span><span class="n">opt</span><span class="o"><</span><span class="n">RegisterMyPasses</span><span class="o">::</span><span class="n">FunctionPassCtor</span><span class="p">,</span> <span class="nb">false</span><span class="p">,</span>
+ <span class="n">RegisterPassParser</span><span class="o"><</span><span class="n">RegisterMyPasses</span><span class="o">></span> <span class="o">></span>
+<span class="n">MyPassOpt</span><span class="p">(</span><span class="s">"mypass"</span><span class="p">,</span>
+ <span class="n">cl</span><span class="o">::</span><span class="n">init</span><span class="p">(</span><span class="o">&</span><span class="n">createDefaultMyPass</span><span class="p">),</span>
+ <span class="n">cl</span><span class="o">::</span><span class="n">desc</span><span class="p">(</span><span class="s">"my pass option help"</span><span class="p">));</span>
+</pre></div>
+</div>
+<p>Here the command option is â<code class="docutils literal notranslate"><span class="pre">mypass</span></code>â, with <code class="docutils literal notranslate"><span class="pre">createDefaultMyPass</span></code> as the
+default creator.</p>
+</div>
+<div class="section" id="using-gdb-with-dynamically-loaded-passes">
+<h3><a class="toc-backref" href="#id53">Using GDB with dynamically loaded passes</a><a class="headerlink" href="#using-gdb-with-dynamically-loaded-passes" title="Permalink to this headline">¶</a></h3>
+<p>Unfortunately, using GDB with dynamically loaded passes is not as easy as it
+should be. First of all, you canât set a breakpoint in a shared object that
+has not been loaded yet, and second of all there are problems with inlined
+functions in shared objects. Here are some suggestions to debugging your pass
+with GDB.</p>
+<p>For sake of discussion, Iâm going to assume that you are debugging a
+transformation invoked by <strong class="program">opt</strong>, although nothing described here
+depends on that.</p>
+<div class="section" id="setting-a-breakpoint-in-your-pass">
+<h4><a class="toc-backref" href="#id54">Setting a breakpoint in your pass</a><a class="headerlink" href="#setting-a-breakpoint-in-your-pass" title="Permalink to this headline">¶</a></h4>
+<p>First thing you do is start gdb on the opt process:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> gdb opt
+<span class="go">GNU gdb 5.0</span>
+<span class="go">Copyright 2000 Free Software Foundation, Inc.</span>
+<span class="go">GDB is free software, covered by the GNU General Public License, and you are</span>
+<span class="go">welcome to change it and/or distribute copies of it under certain conditions.</span>
+<span class="go">Type "show copying" to see the conditions.</span>
+<span class="go">There is absolutely no warranty for GDB. Type "show warranty" for details.</span>
+<span class="go">This GDB was configured as "sparc-sun-solaris2.6"...</span>
+<span class="go">(gdb)</span>
+</pre></div>
+</div>
+<p>Note that <strong class="program">opt</strong> has a lot of debugging information in it, so it takes
+time to load. Be patient. Since we cannot set a breakpoint in our pass yet
+(the shared object isnât loaded until runtime), we must execute the process,
+and have it stop before it invokes our pass, but after it has loaded the shared
+object. The most foolproof way of doing this is to set a breakpoint in
+<code class="docutils literal notranslate"><span class="pre">PassManager::run</span></code> and then run the process with the arguments you want:</p>
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$</span> <span class="o">(</span>gdb<span class="o">)</span> <span class="nb">break</span> llvm::PassManager::run
+<span class="go">Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.</span>
+<span class="go">(gdb) run test.bc -load $(LLVMTOP)/llvm/Debug+Asserts/lib/[libname].so -[passoption]</span>
+<span class="go">Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug+Asserts/lib/[libname].so -[passoption]</span>
+<span class="go">Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70</span>
+<span class="go">70 bool PassManager::run(Module &M) { return PM->run(M); }</span>
+<span class="go">(gdb)</span>
+</pre></div>
+</div>
+<p>Once the <strong class="program">opt</strong> stops in the <code class="docutils literal notranslate"><span class="pre">PassManager::run</span></code> method you are now
+free to set breakpoints in your pass so that you can trace through execution or
+do other standard debugging stuff.</p>
+</div>
+<div class="section" id="miscellaneous-problems">
+<h4><a class="toc-backref" href="#id55">Miscellaneous Problems</a><a class="headerlink" href="#miscellaneous-problems" title="Permalink to this headline">¶</a></h4>
+<p>Once you have the basics down, there are a couple of problems that GDB has,
+some with solutions, some without.</p>
+<ul class="simple">
+<li>Inline functions have bogus stack information. In general, GDB does a pretty
+good job getting stack traces and stepping through inline functions. When a
+pass is dynamically loaded however, it somehow completely loses this
+capability. The only solution I know of is to de-inline a function (move it
+from the body of a class to a <code class="docutils literal notranslate"><span class="pre">.cpp</span></code> file).</li>
+<li>Restarting the program breaks breakpoints. After following the information
+above, you have succeeded in getting some breakpoints planted in your pass.
+Next thing you know, you restart the program (i.e., you type â<code class="docutils literal notranslate"><span class="pre">run</span></code>â again),
+and you start getting errors about breakpoints being unsettable. The only
+way I have found to âfixâ this problem is to delete the breakpoints that are
+already set in your pass, run the program, and re-set the breakpoints once
+execution stops in <code class="docutils literal notranslate"><span class="pre">PassManager::run</span></code>.</li>
+</ul>
+<p>Hopefully these tips will help with common case debugging situations. If youâd
+like to contribute some tips of your own, just contact <a class="reference external" href="mailto:sabre%40nondot.org">Chris</a>.</p>
+</div>
+</div>
+<div class="section" id="future-extensions-planned">
+<h3><a class="toc-backref" href="#id56">Future extensions planned</a><a class="headerlink" href="#future-extensions-planned" title="Permalink to this headline">¶</a></h3>
+<p>Although the LLVM Pass Infrastructure is very capable as it stands, and does
+some nifty stuff, there are things weâd like to add in the future. Here is
+where we are going:</p>
+<div class="section" id="multithreaded-llvm">
+<span id="writing-an-llvm-pass-smp"></span><h4><a class="toc-backref" href="#id57">Multithreaded LLVM</a><a class="headerlink" href="#multithreaded-llvm" title="Permalink to this headline">¶</a></h4>
+<p>Multiple CPU machines are becoming more common and compilation can never be
+fast enough: obviously we should allow for a multithreaded compiler. Because
+of the semantics defined for passes above (specifically they cannot maintain
+state across invocations of their <code class="docutils literal notranslate"><span class="pre">run*</span></code> methods), a nice clean way to
+implement a multithreaded compiler would be for the <code class="docutils literal notranslate"><span class="pre">PassManager</span></code> class to
+create multiple instances of each pass object, and allow the separate instances
+to be hacking on different parts of the program at the same time.</p>
+<p>This implementation would prevent each of the passes from having to implement
+multithreaded constructs, requiring only the LLVM core to have locking in a few
+places (for global resources). Although this is a simple extension, we simply
+havenât had time (or multiprocessor machines, thus a reason) to implement this.
+Despite that, we have kept the LLVM passes SMP ready, and you should too.</p>
+</div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="HowToUseAttributes.html" title="How To Use Attributes"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="GarbageCollection.html" title="Garbage Collection with 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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/XRay.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/XRay.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/XRay.html (added)
+++ www-releases/trunk/9.0.0/docs/XRay.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,435 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>XRay Instrumentation — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Debugging with XRay" href="XRayExample.html" />
+ <link rel="prev" title="Global Instruction Selection" href="GlobalISel.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" role="navigation" aria-label="related navigation">
+ <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="XRayExample.html" title="Debugging with XRay"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="GlobalISel.html" title="Global Instruction Selection"
+ 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" role="main">
+
+ <div class="section" id="xray-instrumentation">
+<h1>XRay Instrumentation<a class="headerlink" href="#xray-instrumentation" title="Permalink to this headline">¶</a></h1>
+<table class="docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field-odd field"><th class="field-name">Version:</th><td class="field-body">1 as of 2016-11-08</td>
+</tr>
+</tbody>
+</table>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id2">Introduction</a></li>
+<li><a class="reference internal" href="#xray-in-llvm" id="id3">XRay in LLVM</a></li>
+<li><a class="reference internal" href="#using-xray" id="id4">Using XRay</a><ul>
+<li><a class="reference internal" href="#instrumenting-your-c-c-objective-c-application" id="id5">Instrumenting your C/C++/Objective-C Application</a></li>
+<li><a class="reference internal" href="#llvm-function-attribute" id="id6">LLVM Function Attribute</a></li>
+<li><a class="reference internal" href="#special-case-file" id="id7">Special Case File</a></li>
+<li><a class="reference internal" href="#xray-runtime-library" id="id8">XRay Runtime Library</a></li>
+<li><a class="reference internal" href="#basic-mode" id="id9">Basic Mode</a></li>
+<li><a class="reference internal" href="#flight-data-recorder-mode" id="id10">Flight Data Recorder Mode</a></li>
+<li><a class="reference internal" href="#trace-analysis-tools" id="id11">Trace Analysis Tools</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#future-work" id="id12">Future Work</a><ul>
+<li><a class="reference internal" href="#id1" id="id13">Trace Analysis Tools</a></li>
+<li><a class="reference internal" href="#more-platforms" id="id14">More Platforms</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id2">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>XRay is a function call tracing system which combines compiler-inserted
+instrumentation points and a runtime library that can dynamically enable and
+disable the instrumentation.</p>
+<p>More high level information about XRay can be found in the <a class="reference external" href="http://research.google.com/pubs/pub45287.html">XRay whitepaper</a>.</p>
+<p>This document describes how to use XRay as implemented in LLVM.</p>
+</div>
+<div class="section" id="xray-in-llvm">
+<h2><a class="toc-backref" href="#id3">XRay in LLVM</a><a class="headerlink" href="#xray-in-llvm" title="Permalink to this headline">¶</a></h2>
+<p>XRay consists of three main parts:</p>
+<ul>
+<li><p class="first">Compiler-inserted instrumentation points.</p>
+</li>
+<li><p class="first">A runtime library for enabling/disabling tracing at runtime.</p>
+</li>
+<li><p class="first">A suite of tools for analysing the traces.</p>
+<p><strong>NOTE:</strong> As of July 25, 2018 , XRay is only available for the following
+architectures running Linux: x86_64, arm7 (no thumb), aarch64, powerpc64le,
+mips, mipsel, mips64, mips64el, NetBSD: x86_64, FreeBSD: x86_64 and
+OpenBSD: x86_64.</p>
+</li>
+</ul>
+<p>The compiler-inserted instrumentation points come in the form of nop-sleds in
+the final generated binary, and an ELF section named <code class="docutils literal notranslate"><span class="pre">xray_instr_map</span></code> which
+contains entries pointing to these instrumentation points. The runtime library
+relies on being able to access the entries of the <code class="docutils literal notranslate"><span class="pre">xray_instr_map</span></code>, and
+overwrite the instrumentation points at runtime.</p>
+</div>
+<div class="section" id="using-xray">
+<h2><a class="toc-backref" href="#id4">Using XRay</a><a class="headerlink" href="#using-xray" title="Permalink to this headline">¶</a></h2>
+<p>You can use XRay in a couple of ways:</p>
+<ul class="simple">
+<li>Instrumenting your C/C++/Objective-C/Objective-C++ application.</li>
+<li>Generating LLVM IR with the correct function attributes.</li>
+</ul>
+<p>The rest of this section covers these main ways and later on how to customise
+what XRay does in an XRay-instrumented binary.</p>
+<div class="section" id="instrumenting-your-c-c-objective-c-application">
+<h3><a class="toc-backref" href="#id5">Instrumenting your C/C++/Objective-C Application</a><a class="headerlink" href="#instrumenting-your-c-c-objective-c-application" title="Permalink to this headline">¶</a></h3>
+<p>The easiest way of getting XRay instrumentation for your application is by
+enabling the <code class="docutils literal notranslate"><span class="pre">-fxray-instrument</span></code> flag in your clang invocation.</p>
+<p>For example:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">clang</span> <span class="o">-</span><span class="n">fxray</span><span class="o">-</span><span class="n">instrument</span> <span class="o">...</span>
+</pre></div>
+</div>
+<p>By default, functions that have at least 200 instructions will get XRay
+instrumentation points. You can tweak that number through the
+<code class="docutils literal notranslate"><span class="pre">-fxray-instruction-threshold=</span></code> flag:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">clang</span> <span class="o">-</span><span class="n">fxray</span><span class="o">-</span><span class="n">instrument</span> <span class="o">-</span><span class="n">fxray</span><span class="o">-</span><span class="n">instruction</span><span class="o">-</span><span class="n">threshold</span><span class="o">=</span><span class="mi">1</span> <span class="o">...</span>
+</pre></div>
+</div>
+<p>You can also specifically instrument functions in your binary to either always
+or never be instrumented using source-level attributes. You can do it using the
+GCC-style attributes or C++11-style attributes.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="p">[[</span><span class="n">clang</span><span class="o">::</span><span class="n">xray_always_instrument</span><span class="p">]]</span> <span class="kt">void</span> <span class="n">always_instrumented</span><span class="p">();</span>
+
+<span class="p">[[</span><span class="n">clang</span><span class="o">::</span><span class="n">xray_never_instrument</span><span class="p">]]</span> <span class="kt">void</span> <span class="n">never_instrumented</span><span class="p">();</span>
+
+<span class="kt">void</span> <span class="nf">alt_always_instrumented</span><span class="p">()</span> <span class="n">__attribute__</span><span class="p">((</span><span class="n">xray_always_instrument</span><span class="p">));</span>
+
+<span class="kt">void</span> <span class="nf">alt_never_instrumented</span><span class="p">()</span> <span class="n">__attribute__</span><span class="p">((</span><span class="n">xray_never_instrument</span><span class="p">));</span>
+</pre></div>
+</div>
+<p>When linking a binary, you can either manually link in the <a class="reference internal" href="#xray-runtime-library">XRay Runtime
+Library</a> or use <code class="docutils literal notranslate"><span class="pre">clang</span></code> to link it in automatically with the
+<code class="docutils literal notranslate"><span class="pre">-fxray-instrument</span></code> flag. Alternatively, you can statically link-in the XRay
+runtime library from compiler-rt â those archive files will take the name of
+<cite>libclang_rt.xray-{arch}</cite> where <cite>{arch}</cite> is the mnemonic supported by clang
+(x86_64, arm7, etc.).</p>
+</div>
+<div class="section" id="llvm-function-attribute">
+<h3><a class="toc-backref" href="#id6">LLVM Function Attribute</a><a class="headerlink" href="#llvm-function-attribute" title="Permalink to this headline">¶</a></h3>
+<p>If youâre using LLVM IR directly, you can add the <code class="docutils literal notranslate"><span class="pre">function-instrument</span></code>
+string attribute to your functions, to get the similar effect that the
+C/C++/Objective-C source-level attributes would get:</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i32</span> <span class="vg">@always_instrument</span><span class="p">()</span> <span class="k">uwtable</span> <span class="s">"function-instrument"</span><span class="p">=</span><span class="s">"xray-always"</span> <span class="p">{</span>
+ <span class="c">; ...</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="k">i32</span> <span class="vg">@never_instrument</span><span class="p">()</span> <span class="k">uwtable</span> <span class="s">"function-instrument"</span><span class="p">=</span><span class="s">"xray-never"</span> <span class="p">{</span>
+ <span class="c">; ...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>You can also set the <code class="docutils literal notranslate"><span class="pre">xray-instruction-threshold</span></code> attribute and provide a
+numeric string value for how many instructions should be in the function before
+it gets instrumented.</p>
+<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i32</span> <span class="vg">@maybe_instrument</span><span class="p">()</span> <span class="k">uwtable</span> <span class="s">"xray-instruction-threshold"</span><span class="p">=</span><span class="s">"2"</span> <span class="p">{</span>
+ <span class="c">; ...</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="special-case-file">
+<h3><a class="toc-backref" href="#id7">Special Case File</a><a class="headerlink" href="#special-case-file" title="Permalink to this headline">¶</a></h3>
+<p>Attributes can be imbued through the use of special case files instead of
+adding them to the original source files. You can use this to mark certain
+functions and classes to be never, always, or instrumented with first-argument
+logging from a file. The fileâs format is described below:</p>
+<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span><span class="c1"># Comments are supported</span>
+<span class="o">[</span>always<span class="o">]</span>
+fun:always_instrument
+fun:log_arg1<span class="o">=</span>arg1 <span class="c1"># Log the first argument for the function</span>
+
+<span class="o">[</span>never<span class="o">]</span>
+fun:never_instrument
+</pre></div>
+</div>
+<p>These files can be provided through the <code class="docutils literal notranslate"><span class="pre">-fxray-attr-list=</span></code> flag to clang.
+You may have multiple files loaded through multiple instances of the flag.</p>
+</div>
+<div class="section" id="xray-runtime-library">
+<h3><a class="toc-backref" href="#id8">XRay Runtime Library</a><a class="headerlink" href="#xray-runtime-library" title="Permalink to this headline">¶</a></h3>
+<p>The XRay Runtime Library is part of the compiler-rt project, which implements
+the runtime components that perform the patching and unpatching of inserted
+instrumentation points. When you use <code class="docutils literal notranslate"><span class="pre">clang</span></code> to link your binaries and the
+<code class="docutils literal notranslate"><span class="pre">-fxray-instrument</span></code> flag, it will automatically link in the XRay runtime.</p>
+<p>The default implementation of the XRay runtime will enable XRay instrumentation
+before <code class="docutils literal notranslate"><span class="pre">main</span></code> starts, which works for applications that have a short
+lifetime. This implementation also records all function entry and exit events
+which may result in a lot of records in the resulting trace.</p>
+<p>Also by default the filename of the XRay trace is <code class="docutils literal notranslate"><span class="pre">xray-log.XXXXXX</span></code> where the
+<code class="docutils literal notranslate"><span class="pre">XXXXXX</span></code> part is randomly generated.</p>
+<p>These options can be controlled through the <code class="docutils literal notranslate"><span class="pre">XRAY_OPTIONS</span></code> environment
+variable, where we list down the options and their defaults below.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="25%" />
+<col width="23%" />
+<col width="20%" />
+<col width="32%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Option</th>
+<th class="head">Type</th>
+<th class="head">Default</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>patch_premain</td>
+<td><code class="docutils literal notranslate"><span class="pre">bool</span></code></td>
+<td><code class="docutils literal notranslate"><span class="pre">false</span></code></td>
+<td>Whether to patch
+instrumentation points
+before main.</td>
+</tr>
+<tr class="row-odd"><td>xray_mode</td>
+<td><code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">char*</span></code></td>
+<td><code class="docutils literal notranslate"><span class="pre">""</span></code></td>
+<td>Default mode to
+install and initialize
+before <code class="docutils literal notranslate"><span class="pre">main</span></code>.</td>
+</tr>
+<tr class="row-even"><td>xray_logfile_base</td>
+<td><code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">char*</span></code></td>
+<td><code class="docutils literal notranslate"><span class="pre">xray-log.</span></code></td>
+<td>Filename base for the
+XRay logfile.</td>
+</tr>
+<tr class="row-odd"><td>verbosity</td>
+<td><code class="docutils literal notranslate"><span class="pre">int</span></code></td>
+<td><code class="docutils literal notranslate"><span class="pre">0</span></code></td>
+<td>Runtime verbosity
+level.</td>
+</tr>
+</tbody>
+</table>
+<p>If you choose to not use the default logging implementation that comes with the
+XRay runtime and/or control when/how the XRay instrumentation runs, you may use
+the XRay APIs directly for doing so. To do this, youâll need to include the
+<code class="docutils literal notranslate"><span class="pre">xray_log_interface.h</span></code> from the compiler-rt <code class="docutils literal notranslate"><span class="pre">xray</span></code> directory. The important API
+functions we list below:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">__xray_log_register_mode(...)</span></code>: Register a logging implementation against
+a string Mode identifier. The implementation is an instance of
+<code class="docutils literal notranslate"><span class="pre">XRayLogImpl</span></code> defined in <code class="docutils literal notranslate"><span class="pre">xray/xray_log_interface.h</span></code>.</li>
+<li><code class="docutils literal notranslate"><span class="pre">__xray_log_select_mode(...)</span></code>: Select the mode to install, associated with
+a string Mode identifier. Only implementations registered with
+<code class="docutils literal notranslate"><span class="pre">__xray_log_register_mode(...)</span></code> can be chosen with this function.</li>
+<li><code class="docutils literal notranslate"><span class="pre">__xray_log_init_mode(...)</span></code>: This function allows for initializing and
+re-initializing an installed logging implementation. See
+<code class="docutils literal notranslate"><span class="pre">xray/xray_log_interface.h</span></code> for details, part of the XRay compiler-rt
+installation.</li>
+</ul>
+<p>Once a logging implementation has been initialized, it can be âstoppedâ by
+finalizing the implementation through the <code class="docutils literal notranslate"><span class="pre">__xray_log_finalize()</span></code> function.
+The finalization routine is the opposite of the initialization. When finalized,
+an implementationâs data can be cleared out through the
+<code class="docutils literal notranslate"><span class="pre">__xray_log_flushLog()</span></code> function. For implementations that support in-memory
+processing, these should register an iterator function to provide access to the
+data via the <code class="docutils literal notranslate"><span class="pre">__xray_log_set_buffer_iterator(...)</span></code> which allows code calling
+the <code class="docutils literal notranslate"><span class="pre">__xray_log_process_buffers(...)</span></code> function to deal with the data in
+memory.</p>
+<p>All of this is better explained in the <code class="docutils literal notranslate"><span class="pre">xray/xray_log_interface.h</span></code> header.</p>
+</div>
+<div class="section" id="basic-mode">
+<h3><a class="toc-backref" href="#id9">Basic Mode</a><a class="headerlink" href="#basic-mode" title="Permalink to this headline">¶</a></h3>
+<p>XRay supports a basic logging mode which will trace the applicationâs
+execution, and periodically append to a single log. This mode can be
+installed/enabled by setting <code class="docutils literal notranslate"><span class="pre">xray_mode=xray-basic</span></code> in the <code class="docutils literal notranslate"><span class="pre">XRAY_OPTIONS</span></code>
+environment variable. Combined with <code class="docutils literal notranslate"><span class="pre">patch_premain=true</span></code> this can allow for
+tracing applications from start to end.</p>
+<p>Like all the other modes installed through <code class="docutils literal notranslate"><span class="pre">__xray_log_select_mode(...)</span></code>, the
+implementation can be configured through the <code class="docutils literal notranslate"><span class="pre">__xray_log_init_mode(...)</span></code>
+function, providing the mode string and the flag options. Basic-mode specific
+defaults can be provided in the <code class="docutils literal notranslate"><span class="pre">XRAY_BASIC_OPTIONS</span></code> environment variable.</p>
+</div>
+<div class="section" id="flight-data-recorder-mode">
+<h3><a class="toc-backref" href="#id10">Flight Data Recorder Mode</a><a class="headerlink" href="#flight-data-recorder-mode" title="Permalink to this headline">¶</a></h3>
+<p>XRay supports a logging mode which allows the application to only capture a
+fixed amount of memoryâs worth of events. Flight Data Recorder (FDR) mode works
+very much like a planeâs âblack boxâ which keeps recording data to memory in a
+fixed-size circular queue of buffers, and have the data available
+programmatically until the buffers are finalized and flushed. To use FDR mode
+on your application, you may set the <code class="docutils literal notranslate"><span class="pre">xray_mode</span></code> variable to <code class="docutils literal notranslate"><span class="pre">xray-fdr</span></code> in
+the <code class="docutils literal notranslate"><span class="pre">XRAY_OPTIONS</span></code> environment variable. Additional options to the FDR mode
+implementation can be provided in the <code class="docutils literal notranslate"><span class="pre">XRAY_FDR_OPTIONS</span></code> environment
+variable. Programmatic configuration can be done by calling
+<code class="docutils literal notranslate"><span class="pre">__xray_log_init_mode("xray-fdr",</span> <span class="pre"><configuration</span> <span class="pre">string>)</span></code> once it has been
+selected/installed.</p>
+<p>When the buffers are flushed to disk, the result is a binary trace format
+described by <a class="reference external" href="XRayFDRFormat.html">XRay FDR format</a></p>
+<p>When FDR mode is on, it will keep writing and recycling memory buffers until
+the logging implementation is finalized â at which point it can be flushed and
+re-initialised later. To do this programmatically, we follow the workflow
+provided below:</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="c1">// Patch the sleds, if we haven't yet.</span>
+<span class="k">auto</span> <span class="n">patch_status</span> <span class="o">=</span> <span class="n">__xray_patch</span><span class="p">();</span>
+
+<span class="c1">// Maybe handle the patch_status errors.</span>
+
+<span class="c1">// When we want to flush the log, we need to finalize it first, to give</span>
+<span class="c1">// threads a chance to return buffers to the queue.</span>
+<span class="k">auto</span> <span class="n">finalize_status</span> <span class="o">=</span> <span class="n">__xray_log_finalize</span><span class="p">();</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">finalize_status</span> <span class="o">!=</span> <span class="n">XRAY_LOG_FINALIZED</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// maybe retry, or bail out.</span>
+<span class="p">}</span>
+
+<span class="c1">// At this point, we are sure that the log is finalized, so we may try</span>
+<span class="c1">// flushing the log.</span>
+<span class="k">auto</span> <span class="n">flush_status</span> <span class="o">=</span> <span class="n">__xray_log_flushLog</span><span class="p">();</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">flush_status</span> <span class="o">!=</span> <span class="n">XRAY_LOG_FLUSHED</span><span class="p">)</span> <span class="p">{</span>
+ <span class="c1">// maybe retry, or bail out.</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The default settings for the FDR mode implementation will create logs named
+similarly to the basic log implementation, but will have a different log
+format. All the trace analysis tools (and the trace reading library) will
+support all versions of the FDR mode format as we add more functionality and
+record types in the future.</p>
+<blockquote>
+<div><strong>NOTE:</strong> We do not promise perpetual support for when we update the log
+versions we support going forward. Deprecation of the formats will be
+announced and discussed on the developers mailing list.</div></blockquote>
+</div>
+<div class="section" id="trace-analysis-tools">
+<h3><a class="toc-backref" href="#id11">Trace Analysis Tools</a><a class="headerlink" href="#trace-analysis-tools" title="Permalink to this headline">¶</a></h3>
+<p>We currently have the beginnings of a trace analysis tool in LLVM, which can be
+found in the <code class="docutils literal notranslate"><span class="pre">tools/llvm-xray</span></code> directory. The <code class="docutils literal notranslate"><span class="pre">llvm-xray</span></code> tool currently
+supports the following subcommands:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">extract</span></code>: Extract the instrumentation map from a binary, and return it as
+YAML.</li>
+<li><code class="docutils literal notranslate"><span class="pre">account</span></code>: Performs basic function call accounting statistics with various
+options for sorting, and output formats (supports CSV, YAML, and
+console-friendly TEXT).</li>
+<li><code class="docutils literal notranslate"><span class="pre">convert</span></code>: Converts an XRay log file from one format to another. We can
+convert from binary XRay traces (both basic and FDR mode) to YAML,
+<a class="reference external" href="https://github.com/brendangregg/FlameGraph">flame-graph</a> friendly text
+formats, as well as <cite>Chrome Trace Viewer (catapult)
+<https://github.com/catapult-project/catapult></cite> formats.</li>
+<li><code class="docutils literal notranslate"><span class="pre">graph</span></code>: Generates a DOT graph of the function call relationships between
+functions found in an XRay trace.</li>
+<li><code class="docutils literal notranslate"><span class="pre">stack</span></code>: Reconstructs function call stacks from a timeline of function
+calls in an XRay trace.</li>
+</ul>
+<p>These subcommands use various library components found as part of the XRay
+libraries, distributed with the LLVM distribution. These are:</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">llvm/XRay/Trace.h</span></code> : A trace reading library for conveniently loading
+an XRay trace of supported forms, into a convenient in-memory representation.
+All the analysis tools that deal with traces use this implementation.</li>
+<li><code class="docutils literal notranslate"><span class="pre">llvm/XRay/Graph.h</span></code> : A semi-generic graph type used by the graph
+subcommand to conveniently represent a function call graph with statistics
+associated with edges and vertices.</li>
+<li><code class="docutils literal notranslate"><span class="pre">llvm/XRay/InstrumentationMap.h</span></code>: A convenient tool for analyzing the
+instrumentation map in XRay-instrumented object files and binaries. The
+<code class="docutils literal notranslate"><span class="pre">extract</span></code> and <code class="docutils literal notranslate"><span class="pre">stack</span></code> subcommands uses this particular library.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="future-work">
+<h2><a class="toc-backref" href="#id12">Future Work</a><a class="headerlink" href="#future-work" title="Permalink to this headline">¶</a></h2>
+<p>There are a number of ongoing efforts for expanding the toolset building around
+the XRay instrumentation system.</p>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id13">Trace Analysis Tools</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<ul class="simple">
+<li>Work is in progress to integrate with or develop tools to visualize findings
+from an XRay trace. Particularly, the <code class="docutils literal notranslate"><span class="pre">stack</span></code> tool is being expanded to
+output formats that allow graphing and exploring the duration of time in each
+call stack.</li>
+<li>With a large instrumented binary, the size of generated XRay traces can
+quickly become unwieldy. We are working on integrating pruning techniques and
+heuristics for the analysis tools to sift through the traces and surface only
+relevant information.</li>
+</ul>
+</div>
+<div class="section" id="more-platforms">
+<h3><a class="toc-backref" href="#id14">More Platforms</a><a class="headerlink" href="#more-platforms" title="Permalink to this headline">¶</a></h3>
+<p>Weâre looking forward to contributions to port XRay to more architectures and
+operating systems.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="XRayExample.html" title="Debugging with XRay"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="GlobalISel.html" title="Global Instruction Selection"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/XRayExample.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/XRayExample.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/XRayExample.html (added)
+++ www-releases/trunk/9.0.0/docs/XRayExample.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,405 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Debugging with XRay — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="XRay Flight Data Recorder Trace Format" href="XRayFDRFormat.html" />
+ <link rel="prev" title="XRay Instrumentation" href="XRay.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" role="navigation" aria-label="related navigation">
+ <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="XRayFDRFormat.html" title="XRay Flight Data Recorder Trace Format"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="XRay.html" title="XRay Instrumentation"
+ 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" role="main">
+
+ <div class="section" id="debugging-with-xray">
+<h1>Debugging with XRay<a class="headerlink" href="#debugging-with-xray" title="Permalink to this headline">¶</a></h1>
+<p>This document shows an example of how you would go about analyzing applications
+built with XRay instrumentation. Here we will attempt to debug <code class="docutils literal notranslate"><span class="pre">llc</span></code>
+compiling some sample LLVM IR generated by Clang.</p>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#building-with-xray" id="id1">Building with XRay</a></li>
+<li><a class="reference internal" href="#getting-traces" id="id2">Getting Traces</a></li>
+<li><a class="reference internal" href="#the-llvm-xray-tool" id="id3">The <code class="docutils literal notranslate"><span class="pre">llvm-xray</span></code> Tool</a></li>
+<li><a class="reference internal" href="#controlling-fidelity" id="id4">Controlling Fidelity</a><ul>
+<li><a class="reference internal" href="#instruction-threshold" id="id5">Instruction Threshold</a></li>
+<li><a class="reference internal" href="#instrumentation-attributes" id="id6">Instrumentation Attributes</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#the-xray-stack-tool" id="id7">The XRay stack tool</a></li>
+<li><a class="reference internal" href="#flame-graph-generation" id="id8">Flame Graph Generation</a></li>
+<li><a class="reference internal" href="#chrome-trace-viewer-visualization" id="id9">Chrome Trace Viewer Visualization</a></li>
+<li><a class="reference internal" href="#further-exploration" id="id10">Further Exploration</a></li>
+<li><a class="reference internal" href="#next-steps" id="id11">Next Steps</a></li>
+</ul>
+</div>
+<div class="section" id="building-with-xray">
+<h2><a class="toc-backref" href="#id1">Building with XRay</a><a class="headerlink" href="#building-with-xray" title="Permalink to this headline">¶</a></h2>
+<p>To debug an application with XRay instrumentation, we need to build it with a
+Clang that supports the <code class="docutils literal notranslate"><span class="pre">-fxray-instrument</span></code> option. See <a class="reference external" href="XRay.html">XRay</a>
+for more technical details of how XRay works for background information.</p>
+<p>In our example, we need to add <code class="docutils literal notranslate"><span class="pre">-fxray-instrument</span></code> to the list of flags
+passed to Clang when building a binary. Note that we need to link with Clang as
+well to get the XRay runtime linked in appropriately. For building <code class="docutils literal notranslate"><span class="pre">llc</span></code> with
+XRay, we do something similar below for our LLVM build:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ mkdir -p llvm-build && cd llvm-build
+# Assume that the LLVM sources are at ../llvm
+$ cmake -GNinja ../llvm -DCMAKE_BUILD_TYPE=Release \
+ -DCMAKE_C_FLAGS_RELEASE="-fxray-instrument" -DCMAKE_CXX_FLAGS="-fxray-instrument" \
+# Once this finishes, we should build llc
+$ ninja llc
+</pre></div>
+</div>
+<p>To verify that we have an XRay instrumented binary, we can use <code class="docutils literal notranslate"><span class="pre">objdump</span></code> to
+look for the <code class="docutils literal notranslate"><span class="pre">xray_instr_map</span></code> section.</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ objdump -h -j xray_instr_map ./bin/llc
+./bin/llc: file format elf64-x86-64
+
+Sections:
+Idx Name Size VMA LMA File off Algn
+ 14 xray_instr_map 00002fc0 00000000041516c6 00000000041516c6 03d516c6 2**0
+ CONTENTS, ALLOC, LOAD, READONLY, DATA
+</pre></div>
+</div>
+</div>
+<div class="section" id="getting-traces">
+<h2><a class="toc-backref" href="#id2">Getting Traces</a><a class="headerlink" href="#getting-traces" title="Permalink to this headline">¶</a></h2>
+<p>By default, XRay does not write out the trace files or patch the application
+before main starts. If we run <code class="docutils literal notranslate"><span class="pre">llc</span></code> it should work like a normally built
+binary. If we want to get a full trace of the applicationâs operations (of the
+functions we do end up instrumenting with XRay) then we need to enable XRay
+at application start. To do this, XRay checks the <code class="docutils literal notranslate"><span class="pre">XRAY_OPTIONS</span></code> environment
+variable.</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span># The following doesn't create an XRay trace by default.
+$ ./bin/llc input.ll
+
+# We need to set the XRAY_OPTIONS to enable some features.
+$ XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./bin/llc input.ll
+==69819==XRay: Log file in 'xray-log.llc.m35qPB'
+</pre></div>
+</div>
+<p>At this point we now have an XRay trace we can start analysing.</p>
+</div>
+<div class="section" id="the-llvm-xray-tool">
+<h2><a class="toc-backref" href="#id3">The <code class="docutils literal notranslate"><span class="pre">llvm-xray</span></code> Tool</a><a class="headerlink" href="#the-llvm-xray-tool" title="Permalink to this headline">¶</a></h2>
+<p>Having a trace then allows us to do basic accounting of the functions that were
+instrumented, and how much time weâre spending in parts of the code. To make
+sense of this data, we use the <code class="docutils literal notranslate"><span class="pre">llvm-xray</span></code> tool which has a few subcommands
+to help us understand our trace.</p>
+<p>One of the things we can do is to get an accounting of the functions that have
+been instrumented. We can see an example accounting with <code class="docutils literal notranslate"><span class="pre">llvm-xray</span> <span class="pre">account</span></code>:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ llvm-xray account xray-log.llc.m35qPB -top=10 -sort=sum -sortorder=dsc -instr_map ./bin/llc
+Functions with latencies: 29
+ funcid count [ min, med, 90p, 99p, max] sum function
+ 187 360 [ 0.000000, 0.000001, 0.000014, 0.000032, 0.000075] 0.001596 LLLexer.cpp:446:0: llvm::LLLexer::LexIdentifier()
+ 85 130 [ 0.000000, 0.000000, 0.000018, 0.000023, 0.000156] 0.000799 X86ISelDAGToDAG.cpp:1984:0: (anonymous namespace)::X86DAGToDAGISel::Select(llvm::SDNode*)
+ 138 130 [ 0.000000, 0.000000, 0.000017, 0.000155, 0.000155] 0.000774 SelectionDAGISel.cpp:2963:0: llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int)
+ 188 103 [ 0.000000, 0.000000, 0.000003, 0.000123, 0.000214] 0.000737 LLParser.cpp:2692:0: llvm::LLParser::ParseValID(llvm::ValID&, llvm::LLParser::PerFunctionState*)
+ 88 1 [ 0.000562, 0.000562, 0.000562, 0.000562, 0.000562] 0.000562 X86ISelLowering.cpp:83:0: llvm::X86TargetLowering::X86TargetLowering(llvm::X86TargetMachine const&, llvm::X86Subtarget const&)
+ 125 102 [ 0.000001, 0.000003, 0.000010, 0.000017, 0.000049] 0.000471 Verifier.cpp:3714:0: (anonymous namespace)::Verifier::visitInstruction(llvm::Instruction&)
+ 90 8 [ 0.000023, 0.000035, 0.000106, 0.000106, 0.000106] 0.000342 X86ISelLowering.cpp:3363:0: llvm::X86TargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&, llvm::SmallVectorImpl<llvm::SDValue>&) const
+ 124 32 [ 0.000003, 0.000007, 0.000016, 0.000041, 0.000041] 0.000310 Verifier.cpp:1967:0: (anonymous namespace)::Verifier::visitFunction(llvm::Function const&)
+ 123 1 [ 0.000302, 0.000302, 0.000302, 0.000302, 0.000302] 0.000302 LLVMContextImpl.cpp:54:0: llvm::LLVMContextImpl::~LLVMContextImpl()
+ 139 46 [ 0.000000, 0.000002, 0.000006, 0.000008, 0.000019] 0.000138 TargetLowering.cpp:506:0: llvm::TargetLowering::SimplifyDemandedBits(llvm::SDValue, llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetLowering::TargetLoweringOpt&, unsigned int, bool) const
+</pre></div>
+</div>
+<p>This shows us that for our input file, <code class="docutils literal notranslate"><span class="pre">llc</span></code> spent the most cumulative time
+in the lexer (a total of 1 millisecond). If we wanted for example to work with
+this data in a spreadsheet, we can output the results as CSV using the
+<code class="docutils literal notranslate"><span class="pre">-format=csv</span></code> option to the command for further analysis.</p>
+<p>If we want to get a textual representation of the raw trace we can use the
+<code class="docutils literal notranslate"><span class="pre">llvm-xray</span> <span class="pre">convert</span></code> tool to get YAML output. The first few lines of that
+output for an example trace would look like the following:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ llvm-xray convert -f yaml -symbolize -instr_map=./bin/llc xray-log.llc.m35qPB
+---
+header:
+ version: 1
+ type: 0
+ constant-tsc: true
+ nonstop-tsc: true
+ cycle-frequency: 2601000000
+records:
+ - { type: 0, func-id: 110, function: __cxx_global_var_init.8, cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426023268520 }
+ - { type: 0, func-id: 110, function: __cxx_global_var_init.8, cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426023523052 }
+ - { type: 0, func-id: 164, function: __cxx_global_var_init, cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426029925386 }
+ - { type: 0, func-id: 164, function: __cxx_global_var_init, cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426030031128 }
+ - { type: 0, func-id: 142, function: '(anonymous namespace)::CommandLineParser::ParseCommandLineOptions(int, char const* const*, llvm::StringRef, llvm::raw_ostream*)', cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426046951388 }
+ - { type: 0, func-id: 142, function: '(anonymous namespace)::CommandLineParser::ParseCommandLineOptions(int, char const* const*, llvm::StringRef, llvm::raw_ostream*)', cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426047282020 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426047857332 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426047984152 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426048036584 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426048042292 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-enter, tsc: 5434426048055056 }
+ - { type: 0, func-id: 187, function: 'llvm::LLLexer::LexIdentifier()', cpu: 37, thread: 69819, kind: function-exit, tsc: 5434426048067316 }
+</pre></div>
+</div>
+</div>
+<div class="section" id="controlling-fidelity">
+<h2><a class="toc-backref" href="#id4">Controlling Fidelity</a><a class="headerlink" href="#controlling-fidelity" title="Permalink to this headline">¶</a></h2>
+<p>So far in our examples, we havenât been getting full coverage of the functions
+we have in the binary. To get that, we need to modify the compiler flags so
+that we can instrument more (if not all) the functions we have in the binary.
+We have two options for doing that, and we explore both of these below.</p>
+<div class="section" id="instruction-threshold">
+<h3><a class="toc-backref" href="#id5">Instruction Threshold</a><a class="headerlink" href="#instruction-threshold" title="Permalink to this headline">¶</a></h3>
+<p>The first âbluntâ way of doing this is by setting the minimum threshold for
+function bodies to 1. We can do that with the
+<code class="docutils literal notranslate"><span class="pre">-fxray-instruction-threshold=N</span></code> flag when building our binary. We rebuild
+<code class="docutils literal notranslate"><span class="pre">llc</span></code> with this option and observe the results:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ rm CMakeCache.txt
+$ cmake -GNinja ../llvm -DCMAKE_BUILD_TYPE=Release \
+ -DCMAKE_C_FLAGS_RELEASE="-fxray-instrument -fxray-instruction-threshold=1" \
+ -DCMAKE_CXX_FLAGS="-fxray-instrument -fxray-instruction-threshold=1"
+$ ninja llc
+$ XRAY_OPTIONS="patch_premain=true" ./bin/llc input.ll
+==69819==XRay: Log file in 'xray-log.llc.5rqxkU'
+
+$ llvm-xray account xray-log.llc.5rqxkU -top=10 -sort=sum -sortorder=dsc -instr_map ./bin/llc
+Functions with latencies: 36652
+ funcid count [ min, med, 90p, 99p, max] sum function
+ 75 1 [ 0.672368, 0.672368, 0.672368, 0.672368, 0.672368] 0.672368 llc.cpp:271:0: main
+ 78 1 [ 0.626455, 0.626455, 0.626455, 0.626455, 0.626455] 0.626455 llc.cpp:381:0: compileModule(char**, llvm::LLVMContext&)
+ 139617 1 [ 0.472618, 0.472618, 0.472618, 0.472618, 0.472618] 0.472618 LegacyPassManager.cpp:1723:0: llvm::legacy::PassManager::run(llvm::Module&)
+ 139610 1 [ 0.472618, 0.472618, 0.472618, 0.472618, 0.472618] 0.472618 LegacyPassManager.cpp:1681:0: llvm::legacy::PassManagerImpl::run(llvm::Module&)
+ 139612 1 [ 0.470948, 0.470948, 0.470948, 0.470948, 0.470948] 0.470948 LegacyPassManager.cpp:1564:0: (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&)
+ 139607 2 [ 0.147345, 0.315994, 0.315994, 0.315994, 0.315994] 0.463340 LegacyPassManager.cpp:1530:0: llvm::FPPassManager::runOnModule(llvm::Module&)
+ 139605 21 [ 0.000002, 0.000002, 0.102593, 0.213336, 0.213336] 0.463331 LegacyPassManager.cpp:1491:0: llvm::FPPassManager::runOnFunction(llvm::Function&)
+ 139563 26096 [ 0.000002, 0.000002, 0.000037, 0.000063, 0.000215] 0.225708 LegacyPassManager.cpp:1083:0: llvm::PMDataManager::findAnalysisPass(void const*, bool)
+ 108055 188 [ 0.000002, 0.000120, 0.001375, 0.004523, 0.062624] 0.159279 MachineFunctionPass.cpp:38:0: llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
+ 62635 22 [ 0.000041, 0.000046, 0.000050, 0.126744, 0.126744] 0.127715 X86TargetMachine.cpp:242:0: llvm::X86TargetMachine::getSubtargetImpl(llvm::Function const&) const
+</pre></div>
+</div>
+</div>
+<div class="section" id="instrumentation-attributes">
+<h3><a class="toc-backref" href="#id6">Instrumentation Attributes</a><a class="headerlink" href="#instrumentation-attributes" title="Permalink to this headline">¶</a></h3>
+<p>The other way is to use configuration files for selecting which functions
+should always be instrumented by the compiler. This gives us a way of ensuring
+that certain functions are either always or never instrumented by not having to
+add the attribute to the source.</p>
+<p>To use this feature, you can define one file for the functions to always
+instrument, and another for functions to never instrument. The format of these
+files are exactly the same as the SanitizerLists files that control similar
+things for the sanitizer implementations. For example:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># xray-attr-list.txt</span>
+<span class="c1"># always instrument functions that match the following filters:</span>
+<span class="p">[</span><span class="n">always</span><span class="p">]</span>
+<span class="n">fun</span><span class="p">:</span><span class="n">main</span>
+
+<span class="c1"># never instrument functions that match the following filters:</span>
+<span class="p">[</span><span class="n">never</span><span class="p">]</span>
+<span class="n">fun</span><span class="p">:</span><span class="n">__cxx_</span><span class="o">*</span>
+</pre></div>
+</div>
+<p>Given the file above we can re-build by providing it to the
+<code class="docutils literal notranslate"><span class="pre">-fxray-attr-list=</span></code> flag to clang. You can have multiple files, each defining
+different sets of attribute sets, to be combined into a single list by clang.</p>
+</div>
+</div>
+<div class="section" id="the-xray-stack-tool">
+<h2><a class="toc-backref" href="#id7">The XRay stack tool</a><a class="headerlink" href="#the-xray-stack-tool" title="Permalink to this headline">¶</a></h2>
+<p>Given a trace, and optionally an instrumentation map, the <code class="docutils literal notranslate"><span class="pre">llvm-xray</span> <span class="pre">stack</span></code>
+command can be used to analyze a call stack graph constructed from the function
+call timeline.</p>
+<p>The way to use the command is to output the top stacks by call count and time spent.</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ llvm-xray stack xray-log.llc.5rqxkU -instr_map ./bin/llc
+
+Unique Stacks: 3069
+Top 10 Stacks by leaf sum:
+
+Sum: 9633790
+lvl function count sum
+#0 main 1 58421550
+#1 compileModule(char**, llvm::LLVMContext&) 1 51440360
+#2 llvm::legacy::PassManagerImpl::run(llvm::Module&) 1 40535375
+#3 llvm::FPPassManager::runOnModule(llvm::Module&) 2 39337525
+#4 llvm::FPPassManager::runOnFunction(llvm::Function&) 6 39331465
+#5 llvm::PMDataManager::verifyPreservedAnalysis(llvm::Pass*) 399 16628590
+#6 llvm::PMTopLevelManager::findAnalysisPass(void const*) 4584 15155600
+#7 llvm::PMDataManager::findAnalysisPass(void const*, bool) 32088 9633790
+
+..etc..
+</pre></div>
+</div>
+<p>In the default mode, identical stacks on different threads are independently
+aggregated. In a multithreaded program, you may end up having identical call
+stacks fill your list of top calls.</p>
+<p>To address this, you may specify the <code class="docutils literal notranslate"><span class="pre">-aggregate-threads</span></code> or
+<code class="docutils literal notranslate"><span class="pre">-per-thread-stacks</span></code> flags. <code class="docutils literal notranslate"><span class="pre">-per-thread-stacks</span></code> treats the thread id as an
+implicit root in each call stack tree, while <code class="docutils literal notranslate"><span class="pre">-aggregate-threads</span></code> combines
+identical stacks from all threads.</p>
+</div>
+<div class="section" id="flame-graph-generation">
+<h2><a class="toc-backref" href="#id8">Flame Graph Generation</a><a class="headerlink" href="#flame-graph-generation" title="Permalink to this headline">¶</a></h2>
+<p>The <code class="docutils literal notranslate"><span class="pre">llvm-xray</span> <span class="pre">stack</span></code> tool may also be used to generate flamegraphs for
+visualizing your instrumented invocations. The tool does not generate the graphs
+themselves, but instead generates a format that can be used with Brendan Greggâs
+FlameGraph tool, currently available on <a class="reference external" href="https://github.com/brendangregg/FlameGraph">github</a>.</p>
+<p>To generate output for a flamegraph, a few more options are necessary.</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">-all-stacks</span></code> - Emits all of the stacks.</li>
+<li><code class="docutils literal notranslate"><span class="pre">-stack-format</span></code> - Choose the flamegraph output format âflameâ.</li>
+<li><code class="docutils literal notranslate"><span class="pre">-aggregation-type</span></code> - Choose the metric to graph.</li>
+</ul>
+<p>You may pipe the command output directly to the flamegraph tool to obtain an
+svg file.</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$llvm-xray stack xray-log.llc.5rqxkU -instr_map ./bin/llc -stack-format=flame -aggregation-type=time -all-stacks | \
+/path/to/FlameGraph/flamegraph.pl > flamegraph.svg
+</pre></div>
+</div>
+<p>If you open the svg in a browser, mouse events allow exploring the call stacks.</p>
+</div>
+<div class="section" id="chrome-trace-viewer-visualization">
+<h2><a class="toc-backref" href="#id9">Chrome Trace Viewer Visualization</a><a class="headerlink" href="#chrome-trace-viewer-visualization" title="Permalink to this headline">¶</a></h2>
+<p>We can also generate a trace which can be loaded by the Chrome Trace Viewer
+from the same generated trace:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ llvm-xray convert -symbolize -instr_map=./bin/llc \
+ -output-format=trace_event xray-log.llc.5rqxkU \
+ | gzip > llc-trace.txt.gz
+</pre></div>
+</div>
+<p>From a Chrome browser, navigating to <code class="docutils literal notranslate"><span class="pre">chrome:///tracing</span></code> allows us to load
+the <code class="docutils literal notranslate"><span class="pre">sample-trace.txt.gz</span></code> file to visualize the execution trace.</p>
+</div>
+<div class="section" id="further-exploration">
+<h2><a class="toc-backref" href="#id10">Further Exploration</a><a class="headerlink" href="#further-exploration" title="Permalink to this headline">¶</a></h2>
+<p>The <code class="docutils literal notranslate"><span class="pre">llvm-xray</span></code> tool has a few other subcommands that are in various stages
+of being developed. One interesting subcommand that can highlight a few
+interesting things is the <code class="docutils literal notranslate"><span class="pre">graph</span></code> subcommand. Given for example the following
+toy program that we build with XRay instrumentation, we can see how the
+generated graph may be a helpful indicator of where time is being spent for the
+application.</p>
+<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="c1">// sample.cc</span>
+<span class="cp">#include</span> <span class="cpf"><iostream></span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf"><thread></span><span class="cp"></span>
+
+<span class="p">[[</span><span class="n">clang</span><span class="o">::</span><span class="n">xray_always_instrument</span><span class="p">]]</span> <span class="kt">void</span> <span class="n">f</span><span class="p">()</span> <span class="p">{</span>
+ <span class="n">std</span><span class="o">::</span><span class="n">cerr</span> <span class="o"><<</span> <span class="sc">'.'</span><span class="p">;</span>
+<span class="p">}</span>
+
+<span class="p">[[</span><span class="n">clang</span><span class="o">::</span><span class="n">xray_always_instrument</span><span class="p">]]</span> <span class="kt">void</span> <span class="n">g</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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">1</span> <span class="o"><<</span> <span class="mi">10</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">std</span><span class="o">::</span><span class="n">cerr</span> <span class="o"><<</span> <span class="sc">'-'</span><span class="p">;</span>
+ <span class="p">}</span>
+<span class="p">}</span>
+
+<span class="kt">int</span> <span class="n">main</span><span class="p">(</span><span class="kt">int</span> <span class="n">argc</span><span class="p">,</span> <span class="kt">char</span><span class="o">*</span> <span class="n">argv</span><span class="p">[])</span> <span class="p">{</span>
+ <span class="n">std</span><span class="o">::</span><span class="kr">thread</span> <span class="n">t1</span><span class="p">([]</span> <span class="p">{</span>
+ <span class="k">for</span> <span class="p">(</span><span class="kt">int</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">1</span> <span class="o"><<</span> <span class="mi">10</span><span class="p">;</span> <span class="o">++</span><span class="n">i</span><span class="p">)</span>
+ <span class="n">f</span><span class="p">();</span>
+ <span class="p">});</span>
+ <span class="n">std</span><span class="o">::</span><span class="kr">thread</span> <span class="n">t2</span><span class="p">([]</span> <span class="p">{</span>
+ <span class="n">g</span><span class="p">();</span>
+ <span class="p">});</span>
+ <span class="n">t1</span><span class="p">.</span><span class="n">join</span><span class="p">();</span>
+ <span class="n">t2</span><span class="p">.</span><span class="n">join</span><span class="p">();</span>
+ <span class="n">std</span><span class="o">::</span><span class="n">cerr</span> <span class="o"><<</span> <span class="sc">'\n'</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>We then build the above with XRay instrumentation:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ clang++ -o sample -O3 sample.cc -std=c++11 -fxray-instrument -fxray-instruction-threshold=1
+$ XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic" ./sample
+</pre></div>
+</div>
+<p>We can then explore the graph rendering of the trace generated by this sample
+application. We assume you have the graphviz toosl available in your system,
+including both <code class="docutils literal notranslate"><span class="pre">unflatten</span></code> and <code class="docutils literal notranslate"><span class="pre">dot</span></code>. If you prefer rendering or exploring
+the graph using another tool, then that should be feasible as well. <code class="docutils literal notranslate"><span class="pre">llvm-xray</span>
+<span class="pre">graph</span></code> will create DOT format graphs which should be usable in most graph
+rendering applications. One example invocation of the <code class="docutils literal notranslate"><span class="pre">llvm-xray</span> <span class="pre">graph</span></code>
+command should yield some interesting insights to the workings of C++
+applications:</p>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ llvm-xray graph xray-log.sample.* -m sample -color-edges=sum -edge-label=sum \
+ | unflatten -f -l10 | dot -Tsvg -o sample.svg
+</pre></div>
+</div>
+</div>
+<div class="section" id="next-steps">
+<h2><a class="toc-backref" href="#id11">Next Steps</a><a class="headerlink" href="#next-steps" title="Permalink to this headline">¶</a></h2>
+<p>If you have some interesting analyses youâd like to implement as part of the
+llvm-xray tool, please feel free to propose them on the llvm-dev@ mailing list.
+The following are some ideas to inspire you in getting involved and potentially
+making things better.</p>
+<blockquote>
+<div><ul class="simple">
+<li>Implement a query/filtering library that allows for finding patterns in the
+XRay traces.</li>
+<li>Collecting function call stacks and how often theyâre encountered in the
+XRay trace.</li>
+</ul>
+</div></blockquote>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="XRayFDRFormat.html" title="XRay Flight Data Recorder Trace Format"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="XRay.html" title="XRay Instrumentation"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/9.0.0/docs/XRayFDRFormat.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/9.0.0/docs/XRayFDRFormat.html?rev=372328&view=auto
==============================================================================
--- www-releases/trunk/9.0.0/docs/XRayFDRFormat.html (added)
+++ www-releases/trunk/9.0.0/docs/XRayFDRFormat.html Thu Sep 19 07:32:46 2019
@@ -0,0 +1,656 @@
+
+
+<!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="X-UA-Compatible" content="IE=Edge" />
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>XRay Flight Data Recorder Trace Format — LLVM 9 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" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></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>
+ <script type="text/javascript" src="_static/language_data.js"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="The PDB File Format" href="PDB/index.html" />
+ <link rel="prev" title="Debugging with XRay" href="XRayExample.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" role="navigation" aria-label="related navigation">
+ <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="PDB/index.html" title="The PDB File Format"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="XRayExample.html" title="Debugging with XRay"
+ 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" role="main">
+
+ <div class="section" id="xray-flight-data-recorder-trace-format">
+<h1>XRay Flight Data Recorder Trace Format<a class="headerlink" href="#xray-flight-data-recorder-trace-format" title="Permalink to this headline">¶</a></h1>
+<table class="docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field-odd field"><th class="field-name">Version:</th><td class="field-body">1 as of 2017-07-20</td>
+</tr>
+</tbody>
+</table>
+<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="#general" id="id2">General</a></li>
+<li><a class="reference internal" href="#header-section" id="id3">Header Section</a></li>
+<li><a class="reference internal" href="#data-section" id="id4">Data Section</a><ul>
+<li><a class="reference internal" href="#function-records" id="id5">Function Records</a></li>
+<li><a class="reference internal" href="#metadata-records" id="id6">Metadata Records</a></li>
+<li><a class="reference internal" href="#newbuffer-records" id="id7">NewBuffer Records</a></li>
+<li><a class="reference internal" href="#wallclocktime-records" id="id8">WallClockTime Records</a></li>
+<li><a class="reference internal" href="#newcpuid-records" id="id9">NewCpuId Records</a></li>
+<li><a class="reference internal" href="#tscwrap-records" id="id10">TSCWrap Records</a></li>
+<li><a class="reference internal" href="#callargument-records" id="id11">CallArgument Records</a></li>
+<li><a class="reference internal" href="#customeventmarker-records" id="id12">CustomEventMarker Records</a></li>
+<li><a class="reference internal" href="#endofbuffer-records" id="id13">EndOfBuffer Records</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#format-grammar-and-invariants" id="id14">Format Grammar and Invariants</a><ul>
+<li><a class="reference internal" href="#function-record-order" id="id15">Function Record Order</a></li>
+</ul>
+</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>When gathering XRay traces in Flight Data Recorder mode, each thread of an
+application will claim buffers to fill with trace data, which at some point
+is finalized and flushed.</p>
+<p>A goal of the profiler is to minimize overhead, the flushed data directly
+corresponds to the buffer.</p>
+<p>This document describes the format of a trace file.</p>
+</div>
+<div class="section" id="general">
+<h2><a class="toc-backref" href="#id2">General</a><a class="headerlink" href="#general" title="Permalink to this headline">¶</a></h2>
+<p>Each trace file corresponds to a sequence of events in a particular thread.</p>
+<p>The file has a header followed by a sequence of discriminated record types.</p>
+<p>The endianness of byte fields matches the endianess of the platform which
+produced the trace file.</p>
+</div>
+<div class="section" id="header-section">
+<h2><a class="toc-backref" href="#id3">Header Section</a><a class="headerlink" href="#header-section" title="Permalink to this headline">¶</a></h2>
+<p>A trace file begins with a 32 byte header.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="25%" />
+<col width="22%" />
+<col width="53%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>version</td>
+<td><code class="docutils literal notranslate"><span class="pre">2</span></code></td>
+<td>Anticipates versioned readers. This
+document describes the format when
+version == 1</td>
+</tr>
+<tr class="row-odd"><td>type</td>
+<td><code class="docutils literal notranslate"><span class="pre">2</span></code></td>
+<td>An enumeration encoding the type of
+trace. Flight Data Recorder mode
+traces have type == 1</td>
+</tr>
+<tr class="row-even"><td>bitfield</td>
+<td><code class="docutils literal notranslate"><span class="pre">4</span></code></td>
+<td>Holds parameters that are not aligned
+to bytes. Further described below.</td>
+</tr>
+<tr class="row-odd"><td>cycle_frequency</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>The frequency in hertz of the CPU
+oscillator used to measure duration of
+events in ticks.</td>
+</tr>
+<tr class="row-even"><td>buffer_size</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>The size in bytes of the data portion
+of the trace following the header.</td>
+</tr>
+<tr class="row-odd"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>Reserved for future use.</td>
+</tr>
+</tbody>
+</table>
+<p>The bitfield parameter of the file header is composed of the following fields.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="25%" />
+<col width="21%" />
+<col width="54%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bits)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>constant_tsc</td>
+<td><code class="docutils literal notranslate"><span class="pre">1</span></code></td>
+<td>Whether the platformâs timestamp
+counter used to record ticks between
+events ticks at a constant frequency
+despite CPU frequency changes.
+0 == non-constant. 1 == constant.</td>
+</tr>
+<tr class="row-odd"><td>nonstop_tsc</td>
+<td><code class="docutils literal notranslate"><span class="pre">1</span></code></td>
+<td>Whether the tsc continues to count
+despite whether the CPU is in a low
+power state. 0 == stop. 1 == non-stop.</td>
+</tr>
+<tr class="row-even"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">30</span></code></td>
+<td>Not meaningful.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="data-section">
+<h2><a class="toc-backref" href="#id4">Data Section</a><a class="headerlink" href="#data-section" title="Permalink to this headline">¶</a></h2>
+<p>Following the header in a trace is a data section with size matching the
+buffer_size field in the header.</p>
+<p>The data section is a stream of elements of different types.</p>
+<p>There are a few categories of data in the sequence.</p>
+<ul class="simple">
+<li><code class="docutils literal notranslate"><span class="pre">Function</span> <span class="pre">Records</span></code>: Function Records contain the timing of entry into and
+exit from function execution. Function Records have 8 bytes each.</li>
+<li><code class="docutils literal notranslate"><span class="pre">Metadata</span> <span class="pre">Records</span></code>: Metadata records serve many purposes. Mostly, they
+capture information that may be too costly to record for each function, but
+that is required to contextualize the fine-grained timings. They also are used
+as markers for user-defined Event Data payloads. Metadata records have 16
+bytes each.</li>
+<li><code class="docutils literal notranslate"><span class="pre">Event</span> <span class="pre">Data</span></code>: Free form data may be associated with events that are traced
+by the binary and encode data defined by a handler function. Event data is
+always preceded with a marker record which indicates how large it is.</li>
+<li><code class="docutils literal notranslate"><span class="pre">Function</span> <span class="pre">Arguments</span></code>: The arguments to some functions are included in the
+trace. These are either pointer addresses or primitives that are read and
+logged independently of their types in a high level language. To the tracer,
+they are all numbers. Function Records that have attached arguments will
+indicate their presence on the function entry record. We only support logging
+contiguous function argument sequences starting with argument zero, which will
+be the âthisâ pointer for member function invocations. For example, we donât
+support logging the first and third argument.</li>
+</ul>
+<p>A reader of the memory format must maintain a state machine. The format makes no
+attempt to pad for alignment, and it is not seekable.</p>
+<div class="section" id="function-records">
+<h3><a class="toc-backref" href="#id5">Function Records</a><a class="headerlink" href="#function-records" title="Permalink to this headline">¶</a></h3>
+<p>Function Records have an 8 byte layout. This layout encodes information to
+reconstruct a call stack of instrumented function and their durations.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bits)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>discriminant</td>
+<td><code class="docutils literal notranslate"><span class="pre">1</span></code></td>
+<td>Indicates whether a reader should read a
+Function or Metadata record. Set to <code class="docutils literal notranslate"><span class="pre">0</span></code> for
+Function records.</td>
+</tr>
+<tr class="row-odd"><td>action</td>
+<td><code class="docutils literal notranslate"><span class="pre">3</span></code></td>
+<td>Specifies whether the function is being
+entered, exited, or is a non-standard entry
+or exit produced by optimizations.</td>
+</tr>
+<tr class="row-even"><td>function_id</td>
+<td><code class="docutils literal notranslate"><span class="pre">28</span></code></td>
+<td>A numeric ID for the function. Resolved to a
+name via the xray instrumentation map. The
+instrumentation map is built by xray at
+compile time into an object file and pairs
+the function ids to addresses. It is used for
+patching and as a lookup into the binaryâs
+symbols to obtain names.</td>
+</tr>
+<tr class="row-odd"><td>tsc_delta</td>
+<td><code class="docutils literal notranslate"><span class="pre">32</span></code></td>
+<td>The number of ticks of the timestamp counter
+since a previous record recorded a delta or
+other TSC resetting event.</td>
+</tr>
+</tbody>
+</table>
+<p>On little-endian machines, the bitfields are ordered from least significant bit
+bit to most significant bit. A reader can read an 8 bit value and apply the mask
+<code class="docutils literal notranslate"><span class="pre">0x01</span></code> for the discriminant. Similarly, they can read 32 bits and unsigned
+shift right by <code class="docutils literal notranslate"><span class="pre">0x04</span></code> to obtain the function_id field.</p>
+<p>On big-endian machine, the bitfields are written in order from most significant
+bit to least significant bit. A reader would read an 8 bit value and unsigned
+shift right by 7 bits for the discriminant. The function_id field could be
+obtained by reading a 32 bit value and applying the mask <code class="docutils literal notranslate"><span class="pre">0x0FFFFFFF</span></code>.</p>
+<p>Function action types are as follows.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Type</th>
+<th class="head">Number</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>Entry</td>
+<td><code class="docutils literal notranslate"><span class="pre">0</span></code></td>
+<td>Typical function entry.</td>
+</tr>
+<tr class="row-odd"><td>Exit</td>
+<td><code class="docutils literal notranslate"><span class="pre">1</span></code></td>
+<td>Typical function exit.</td>
+</tr>
+<tr class="row-even"><td>Tail_Exit</td>
+<td><code class="docutils literal notranslate"><span class="pre">2</span></code></td>
+<td>An exit from a function due to tail call
+optimization.</td>
+</tr>
+<tr class="row-odd"><td>Entry_Args</td>
+<td><code class="docutils literal notranslate"><span class="pre">3</span></code></td>
+<td>A function entry that records arguments.</td>
+</tr>
+</tbody>
+</table>
+<p>Entry_Args records do not contain the arguments themselves. Instead, metadata
+records for each of the logged args follow the function record in the stream.</p>
+</div>
+<div class="section" id="metadata-records">
+<h3><a class="toc-backref" href="#id6">Metadata Records</a><a class="headerlink" href="#metadata-records" title="Permalink to this headline">¶</a></h3>
+<p>Interspersed throughout the buffer are 16 byte Metadata records. For typically
+instrumented binaries, they will be sparser than Function records, and they
+provide a fuller picture of the binary execution state.</p>
+<p>Metadata record layout is partially record dependent, but they share a common
+structure.</p>
+<p>The same bit field rules described for function records apply to the first byte
+of MetadataRecords. Within this byte, little endian machines use lsb to msb
+ordering and big endian machines use msb to lsb ordering.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>discriminant</td>
+<td><code class="docutils literal notranslate"><span class="pre">1</span> <span class="pre">bit</span></code></td>
+<td>Indicates whether a reader should read a
+Function or Metadata record. Set to <code class="docutils literal notranslate"><span class="pre">1</span></code> for
+Metadata records.</td>
+</tr>
+<tr class="row-odd"><td>record_kind</td>
+<td><code class="docutils literal notranslate"><span class="pre">7</span> <span class="pre">bits</span></code></td>
+<td>The type of Metadata record.</td>
+</tr>
+<tr class="row-even"><td>data</td>
+<td><code class="docutils literal notranslate"><span class="pre">15</span> <span class="pre">bytes</span></code></td>
+<td>A data field used differently for each record
+type.</td>
+</tr>
+</tbody>
+</table>
+<p>Here is a table of the enumerated record kinds.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="23%" />
+<col width="77%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Number</th>
+<th class="head">Type</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>NewBuffer</td>
+</tr>
+<tr class="row-odd"><td>1</td>
+<td>EndOfBuffer</td>
+</tr>
+<tr class="row-even"><td>2</td>
+<td>NewCPUId</td>
+</tr>
+<tr class="row-odd"><td>3</td>
+<td>TSCWrap</td>
+</tr>
+<tr class="row-even"><td>4</td>
+<td>WallTimeMarker</td>
+</tr>
+<tr class="row-odd"><td>5</td>
+<td>CustomEventMarker</td>
+</tr>
+<tr class="row-even"><td>6</td>
+<td>CallArgument</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="newbuffer-records">
+<h3><a class="toc-backref" href="#id7">NewBuffer Records</a><a class="headerlink" href="#newbuffer-records" title="Permalink to this headline">¶</a></h3>
+<p>Each buffer begins with a NewBuffer record immediately after the header.
+It records the thread ID of the thread that the trace belongs to.</p>
+<p>Its data segment is as follows.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>thread_Id</td>
+<td><code class="docutils literal notranslate"><span class="pre">2</span></code></td>
+<td>Thread ID for buffer.</td>
+</tr>
+<tr class="row-odd"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">13</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="wallclocktime-records">
+<h3><a class="toc-backref" href="#id8">WallClockTime Records</a><a class="headerlink" href="#wallclocktime-records" title="Permalink to this headline">¶</a></h3>
+<p>Following the NewBuffer record, each buffer records an absolute time as a frame
+of reference for the durations recorded by timestamp counter deltas.</p>
+<p>Its data segment is as follows.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>seconds</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>Seconds on absolute timescale. The starting
+point is unspecified and depends on the
+implementation and platform configured by the
+tracer.</td>
+</tr>
+<tr class="row-odd"><td>microseconds</td>
+<td><code class="docutils literal notranslate"><span class="pre">4</span></code></td>
+<td>The microsecond component of the time.</td>
+</tr>
+<tr class="row-even"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">3</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="newcpuid-records">
+<h3><a class="toc-backref" href="#id9">NewCpuId Records</a><a class="headerlink" href="#newcpuid-records" title="Permalink to this headline">¶</a></h3>
+<p>Each function entry invokes a routine to determine what CPU is executing.
+Typically, this is done with readtscp, which reads the timestamp counter at the
+same time.</p>
+<p>If the tracing detects that the execution has switched CPUs or if this is the
+first instrumented entry point, the tracer will output a NewCpuId record.</p>
+<p>Its data segment is as follows.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>cpu_id</td>
+<td><code class="docutils literal notranslate"><span class="pre">2</span></code></td>
+<td>CPU Id.</td>
+</tr>
+<tr class="row-odd"><td>absolute_tsc</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>The absolute value of the timestamp counter.</td>
+</tr>
+<tr class="row-even"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">5</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="tscwrap-records">
+<h3><a class="toc-backref" href="#id10">TSCWrap Records</a><a class="headerlink" href="#tscwrap-records" title="Permalink to this headline">¶</a></h3>
+<p>Since each function record uses a 32 bit value to represent the number of ticks
+of the timestamp counter since the last reference, it is possible for this value
+to overflow, particularly for sparsely instrumented binaries.</p>
+<p>When this delta would not fit into a 32 bit representation, a reference absolute
+timestamp counter record is written in the form of a TSCWrap record.</p>
+<p>Its data segment is as follows.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>absolute_tsc</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>Timestamp counter value.</td>
+</tr>
+<tr class="row-odd"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">7</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="callargument-records">
+<h3><a class="toc-backref" href="#id11">CallArgument Records</a><a class="headerlink" href="#callargument-records" title="Permalink to this headline">¶</a></h3>
+<p>Immediately following an Entry_Args type function record, there may be one or
+more CallArgument records that contain the traced functionâs parameter values.</p>
+<p>The order of the CallArgument Record sequency corresponds one to one with the
+order of the function parameters.</p>
+<p>CallArgument data segment:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>argument</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>Numeric argument (may be pointer address).</td>
+</tr>
+<tr class="row-odd"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">7</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="customeventmarker-records">
+<h3><a class="toc-backref" href="#id12">CustomEventMarker Records</a><a class="headerlink" href="#customeventmarker-records" title="Permalink to this headline">¶</a></h3>
+<p>XRay provides the feature of logging custom events. This may be leveraged to
+record tracing info for RPCs or similarly trace data that is application
+specific.</p>
+<p>Custom Events themselves are an unstructured (application defined) segment of
+memory with arbitrary size within the buffer. They are preceded by
+CustomEventMarkers to indicate their presence and size.</p>
+<p>CustomEventMarker data segment:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="20%" />
+<col width="18%" />
+<col width="62%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Field</th>
+<th class="head">Size (bytes)</th>
+<th class="head">Description</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>event_size</td>
+<td><code class="docutils literal notranslate"><span class="pre">4</span></code></td>
+<td>Size of preceded event.</td>
+</tr>
+<tr class="row-odd"><td>absolute_tsc</td>
+<td><code class="docutils literal notranslate"><span class="pre">8</span></code></td>
+<td>A timestamp counter of the event.</td>
+</tr>
+<tr class="row-even"><td>reserved</td>
+<td><code class="docutils literal notranslate"><span class="pre">3</span></code></td>
+<td>Unused.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="endofbuffer-records">
+<h3><a class="toc-backref" href="#id13">EndOfBuffer Records</a><a class="headerlink" href="#endofbuffer-records" title="Permalink to this headline">¶</a></h3>
+<p>An EndOfBuffer record type indicates that there is no more trace data in this
+buffer. The reader is expected to seek past the remaining buffer_size expressed
+before the start of buffer and look for either another header or EOF.</p>
+</div>
+</div>
+<div class="section" id="format-grammar-and-invariants">
+<h2><a class="toc-backref" href="#id14">Format Grammar and Invariants</a><a class="headerlink" href="#format-grammar-and-invariants" title="Permalink to this headline">¶</a></h2>
+<p>Not all sequences of Metadata records and Function records are valid data. A
+sequence should be parsed as a state machine. The expectations for a valid
+format can be expressed as a context free grammar.</p>
+<p>This is an attempt to explain the format with statements in EBNF format.</p>
+<ul class="simple">
+<li>Format := Header ThreadBuffer* EOF</li>
+<li>ThreadBuffer := NewBuffer WallClockTime NewCPUId BodySequence* End</li>
+<li>BodySequence := NewCPUId | TSCWrap | Function | CustomEvent</li>
+<li>Function := (Function_Entry_Args CallArgument*) | Function_Other_Type</li>
+<li>CustomEvent := CustomEventMarker CustomEventUnstructuredMemory</li>
+<li>End := EndOfBuffer RemainingBufferSizeToSkip</li>
+</ul>
+<div class="section" id="function-record-order">
+<h3><a class="toc-backref" href="#id15">Function Record Order</a><a class="headerlink" href="#function-record-order" title="Permalink to this headline">¶</a></h3>
+<p>There are a few clarifications that may help understand what is expected of
+Function records.</p>
+<ul class="simple">
+<li>Functions with an Exit are expected to have a corresponding Entry or
+Entry_Args function record precede them in the trace.</li>
+<li>Tail_Exit Function records record the Function ID of the function whose return
+address the program counter will take. In other words, the final function that
+would be popped off of the call stack if tail call optimization was not used.</li>
+<li>Not all functions marked for instrumentation are necessarily in the trace. The
+tracer uses heuristics to preserve the trace for non-trivial functions.</li>
+<li>Not every entry must have a traced Exit or Tail Exit. The buffer may run out
+of space or the program may request for the tracer to finalize toreturn the
+buffer before an instrumented function exits.</li>
+</ul>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related" role="navigation" aria-label="related navigation">
+ <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="PDB/index.html" title="The PDB File Format"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="XRayExample.html" title="Debugging with XRay"
+ >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" role="contentinfo">
+ © Copyright 2003-2019, LLVM Project.
+ Last updated on 2019-09-19.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
More information about the llvm-commits
mailing list