[www-releases] r336152 - Add 6.0.1 docs
Tom Stellard via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 2 16:21:47 PDT 2018
Added: www-releases/trunk/6.0.1/docs/Projects.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/Projects.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/Projects.html (added)
+++ www-releases/trunk/6.0.1/docs/Projects.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,338 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Creating an LLVM Project — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="LLVMBuild Guide" href="LLVMBuild.html" />
+ <link rel="prev" title="LLVM Developer Policy" href="DeveloperPolicy.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="LLVMBuild.html" title="LLVMBuild Guide"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="DeveloperPolicy.html" title="LLVM Developer Policy"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="creating-an-llvm-project">
+<h1>Creating an LLVM Project<a class="headerlink" href="#creating-an-llvm-project" 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="#source-tree-layout" id="id2">Source Tree Layout</a></li>
+<li><a class="reference internal" href="#writing-llvm-style-makefiles" id="id3">Writing LLVM Style Makefiles</a><ul>
+<li><a class="reference internal" href="#required-variables" id="id4">Required Variables</a></li>
+<li><a class="reference internal" href="#variables-for-building-subdirectories" id="id5">Variables for Building Subdirectories</a></li>
+<li><a class="reference internal" href="#variables-for-building-libraries" id="id6">Variables for Building Libraries</a></li>
+<li><a class="reference internal" href="#variables-for-building-programs" id="id7">Variables for Building Programs</a></li>
+<li><a class="reference internal" href="#miscellaneous-variables" id="id8">Miscellaneous Variables</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#placement-of-object-code" id="id9">Placement of Object Code</a></li>
+<li><a class="reference internal" href="#further-help" id="id10">Further Help</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>The LLVM build system is designed to facilitate the building of third party
+projects that use LLVM header files, libraries, and tools. In order to use
+these facilities, a <tt class="docutils literal"><span class="pre">Makefile</span></tt> from a project must do the following things:</p>
+<ul class="simple">
+<li>Set <tt class="docutils literal"><span class="pre">make</span></tt> variables. There are several variables that a <tt class="docutils literal"><span class="pre">Makefile</span></tt> needs
+to set to use the LLVM build system:<ul>
+<li><tt class="docutils literal"><span class="pre">PROJECT_NAME</span></tt> - The name by which your project is known.</li>
+<li><tt class="docutils literal"><span class="pre">LLVM_SRC_ROOT</span></tt> - The root of the LLVM source tree.</li>
+<li><tt class="docutils literal"><span class="pre">LLVM_OBJ_ROOT</span></tt> - The root of the LLVM object tree.</li>
+<li><tt class="docutils literal"><span class="pre">PROJ_SRC_ROOT</span></tt> - The root of the project’s source tree.</li>
+<li><tt class="docutils literal"><span class="pre">PROJ_OBJ_ROOT</span></tt> - The root of the project’s object tree.</li>
+<li><tt class="docutils literal"><span class="pre">PROJ_INSTALL_ROOT</span></tt> - The root installation directory.</li>
+<li><tt class="docutils literal"><span class="pre">LEVEL</span></tt> - The relative path from the current directory to the
+project’s root <tt class="docutils literal"><span class="pre">($PROJ_OBJ_ROOT)</span></tt>.</li>
+</ul>
+</li>
+<li>Include <tt class="docutils literal"><span class="pre">Makefile.config</span></tt> from <tt class="docutils literal"><span class="pre">$(LLVM_OBJ_ROOT)</span></tt>.</li>
+<li>Include <tt class="docutils literal"><span class="pre">Makefile.rules</span></tt> from <tt class="docutils literal"><span class="pre">$(LLVM_SRC_ROOT)</span></tt>.</li>
+</ul>
+<p>There are two ways that you can set all of these variables:</p>
+<ul class="simple">
+<li>You can write your own <tt class="docutils literal"><span class="pre">Makefiles</span></tt> which hard-code these values.</li>
+<li>You can use the pre-made LLVM sample project. This sample project includes
+<tt class="docutils literal"><span class="pre">Makefiles</span></tt>, a configure script that can be used to configure the location
+of LLVM, and the ability to support multiple object directories from a single
+source directory.</li>
+</ul>
+<p>If you want to devise your own build system, studying other projects and LLVM
+<tt class="docutils literal"><span class="pre">Makefiles</span></tt> will probably provide enough information on how to write your own
+<tt class="docutils literal"><span class="pre">Makefiles</span></tt>.</p>
+</div>
+<div class="section" id="source-tree-layout">
+<h2><a class="toc-backref" href="#id2">Source Tree Layout</a><a class="headerlink" href="#source-tree-layout" title="Permalink to this headline">¶</a></h2>
+<p>In order to use the LLVM build system, you will want to organize your source
+code so that it can benefit from the build system’s features. Mainly, you want
+your source tree layout to look similar to the LLVM source tree layout.</p>
+<p>Underneath your top level directory, you should have the following directories:</p>
+<p><strong>lib</strong></p>
+<blockquote>
+<div><p>This subdirectory should contain all of your library source code. For each
+library that you build, you will have one directory in <strong>lib</strong> that will
+contain that library’s source code.</p>
+<p>Libraries can be object files, archives, or dynamic libraries. The <strong>lib</strong>
+directory is just a convenient place for libraries as it places them all in
+a directory from which they can be linked later.</p>
+</div></blockquote>
+<p><strong>include</strong></p>
+<blockquote>
+<div><p>This subdirectory should contain any header files that are global to your
+project. By global, we mean that they are used by more than one library or
+executable of your project.</p>
+<p>By placing your header files in <strong>include</strong>, they will be found
+automatically by the LLVM build system. For example, if you have a file
+<strong>include/jazz/note.h</strong>, then your source files can include it simply with
+<strong>#include “jazz/note.h”</strong>.</p>
+</div></blockquote>
+<p><strong>tools</strong></p>
+<blockquote>
+<div>This subdirectory should contain all of your source code for executables.
+For each program that you build, you will have one directory in <strong>tools</strong>
+that will contain that program’s source code.</div></blockquote>
+<p><strong>test</strong></p>
+<blockquote>
+<div><p>This subdirectory should contain tests that verify that your code works
+correctly. Automated tests are especially useful.</p>
+<p>Currently, the LLVM build system provides basic support for tests. The LLVM
+system provides the following:</p>
+</div></blockquote>
+<ul>
+<li><p class="first">LLVM contains regression tests in <tt class="docutils literal"><span class="pre">llvm/test</span></tt>. These tests are run by the
+<a class="reference internal" href="CommandGuide/lit.html"><em>Lit</em></a> testing tool. This test procedure uses <tt class="docutils literal"><span class="pre">RUN</span></tt>
+lines in the actual test case to determine how to run the test. See the
+<a class="reference internal" href="TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a> for more details.</p>
+</li>
+<li><p class="first">LLVM contains an optional package called <tt class="docutils literal"><span class="pre">llvm-test</span></tt>, which provides
+benchmarks and programs that are known to compile with the Clang front
+end. You can use these programs to test your code, gather statistical
+information, and compare it to the current LLVM performance statistics.</p>
+<p>Currently, there is no way to hook your tests directly into the <tt class="docutils literal"><span class="pre">llvm/test</span></tt>
+testing harness. You will simply need to find a way to use the source
+provided within that directory on your own.</p>
+</li>
+</ul>
+<p>Typically, you will want to build your <strong>lib</strong> directory first followed by your
+<strong>tools</strong> directory.</p>
+</div>
+<div class="section" id="writing-llvm-style-makefiles">
+<h2><a class="toc-backref" href="#id3">Writing LLVM Style Makefiles</a><a class="headerlink" href="#writing-llvm-style-makefiles" title="Permalink to this headline">¶</a></h2>
+<p>The LLVM build system provides a convenient way to build libraries and
+executables. Most of your project Makefiles will only need to define a few
+variables. Below is a list of the variables one can set and what they can
+do:</p>
+<div class="section" id="required-variables">
+<h3><a class="toc-backref" href="#id4">Required Variables</a><a class="headerlink" href="#required-variables" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">LEVEL</span></tt></p>
+<blockquote>
+<div>This variable is the relative path from this <tt class="docutils literal"><span class="pre">Makefile</span></tt> to the top
+directory of your project’s source code. For example, if your source code
+is in <tt class="docutils literal"><span class="pre">/tmp/src</span></tt>, then the <tt class="docutils literal"><span class="pre">Makefile</span></tt> in <tt class="docutils literal"><span class="pre">/tmp/src/jump/high</span></tt>
+would set <tt class="docutils literal"><span class="pre">LEVEL</span></tt> to <tt class="docutils literal"><span class="pre">"../.."</span></tt>.</div></blockquote>
+</div>
+<div class="section" id="variables-for-building-subdirectories">
+<h3><a class="toc-backref" href="#id5">Variables for Building Subdirectories</a><a class="headerlink" href="#variables-for-building-subdirectories" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">DIRS</span></tt></p>
+<blockquote>
+<div>This is a space separated list of subdirectories that should be built. They
+will be built, one at a time, in the order specified.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">PARALLEL_DIRS</span></tt></p>
+<blockquote>
+<div>This is a list of directories that can be built in parallel. These will be
+built after the directories in DIRS have been built.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">OPTIONAL_DIRS</span></tt></p>
+<blockquote>
+<div>This is a list of directories that can be built if they exist, but will not
+cause an error if they do not exist. They are built serially in the order
+in which they are listed.</div></blockquote>
+</div>
+<div class="section" id="variables-for-building-libraries">
+<h3><a class="toc-backref" href="#id6">Variables for Building Libraries</a><a class="headerlink" href="#variables-for-building-libraries" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">LIBRARYNAME</span></tt></p>
+<blockquote>
+<div>This variable contains the base name of the library that will be built. For
+example, to build a library named <tt class="docutils literal"><span class="pre">libsample.a</span></tt>, <tt class="docutils literal"><span class="pre">LIBRARYNAME</span></tt> should
+be set to <tt class="docutils literal"><span class="pre">sample</span></tt>.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">BUILD_ARCHIVE</span></tt></p>
+<blockquote>
+<div>By default, a library is a <tt class="docutils literal"><span class="pre">.o</span></tt> file that is linked directly into a
+program. To build an archive (also known as a static library), set the
+<tt class="docutils literal"><span class="pre">BUILD_ARCHIVE</span></tt> variable.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">SHARED_LIBRARY</span></tt></p>
+<blockquote>
+<div>If <tt class="docutils literal"><span class="pre">SHARED_LIBRARY</span></tt> is defined in your Makefile, a shared (or dynamic)
+library will be built.</div></blockquote>
+</div>
+<div class="section" id="variables-for-building-programs">
+<h3><a class="toc-backref" href="#id7">Variables for Building Programs</a><a class="headerlink" href="#variables-for-building-programs" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">TOOLNAME</span></tt></p>
+<blockquote>
+<div>This variable contains the name of the program that will be built. For
+example, to build an executable named <tt class="docutils literal"><span class="pre">sample</span></tt>, <tt class="docutils literal"><span class="pre">TOOLNAME</span></tt> should be set
+to <tt class="docutils literal"><span class="pre">sample</span></tt>.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">USEDLIBS</span></tt></p>
+<blockquote>
+<div><p>This variable holds a space separated list of libraries that should be
+linked into the program. These libraries must be libraries that come from
+your <strong>lib</strong> directory. The libraries must be specified without their
+<tt class="docutils literal"><span class="pre">lib</span></tt> prefix. For example, to link <tt class="docutils literal"><span class="pre">libsample.a</span></tt>, you would set
+<tt class="docutils literal"><span class="pre">USEDLIBS</span></tt> to <tt class="docutils literal"><span class="pre">sample.a</span></tt>.</p>
+<p>Note that this works only for statically linked libraries.</p>
+</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">LLVMLIBS</span></tt></p>
+<blockquote>
+<div><p>This variable holds a space separated list of libraries that should be
+linked into the program. These libraries must be LLVM libraries. The
+libraries must be specified without their <tt class="docutils literal"><span class="pre">lib</span></tt> prefix. For example, to
+link with a driver that performs an IR transformation you might set
+<tt class="docutils literal"><span class="pre">LLVMLIBS</span></tt> to this minimal set of libraries <tt class="docutils literal"><span class="pre">LLVMSupport.a</span> <span class="pre">LLVMCore.a</span>
+<span class="pre">LLVMBitReader.a</span> <span class="pre">LLVMAsmParser.a</span> <span class="pre">LLVMAnalysis.a</span> <span class="pre">LLVMTransformUtils.a</span>
+<span class="pre">LLVMScalarOpts.a</span> <span class="pre">LLVMTarget.a</span></tt>.</p>
+<p>Note that this works only for statically linked libraries. LLVM is split
+into a large number of static libraries, and the list of libraries you
+require may be much longer than the list above. To see a full list of
+libraries use: <tt class="docutils literal"><span class="pre">llvm-config</span> <span class="pre">--libs</span> <span class="pre">all</span></tt>. Using <tt class="docutils literal"><span class="pre">LINK_COMPONENTS</span></tt> as
+described below, obviates the need to set <tt class="docutils literal"><span class="pre">LLVMLIBS</span></tt>.</p>
+</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">LINK_COMPONENTS</span></tt></p>
+<blockquote>
+<div>This variable holds a space separated list of components that the LLVM
+<tt class="docutils literal"><span class="pre">Makefiles</span></tt> pass to the <tt class="docutils literal"><span class="pre">llvm-config</span></tt> tool to generate a link line for
+the program. For example, to link with all LLVM libraries use
+<tt class="docutils literal"><span class="pre">LINK_COMPONENTS</span> <span class="pre">=</span> <span class="pre">all</span></tt>.</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">LIBS</span></tt></p>
+<blockquote>
+<div><p>To link dynamic libraries, add <tt class="docutils literal"><span class="pre">-l<library</span> <span class="pre">base</span> <span class="pre">name></span></tt> to the <tt class="docutils literal"><span class="pre">LIBS</span></tt>
+variable. The LLVM build system will look in the same places for dynamic
+libraries as it does for static libraries.</p>
+<p>For example, to link <tt class="docutils literal"><span class="pre">libsample.so</span></tt>, you would have the following line in
+your <tt class="docutils literal"><span class="pre">Makefile</span></tt>:</p>
+<blockquote>
+<div><div class="highlight-makefile"><div class="highlight"><pre><span class="nv">LIBS</span> <span class="o">+=</span> -lsample
+</pre></div>
+</div>
+</div></blockquote>
+</div></blockquote>
+<p>Note that <tt class="docutils literal"><span class="pre">LIBS</span></tt> must occur in the Makefile after the inclusion of
+<tt class="docutils literal"><span class="pre">Makefile.common</span></tt>.</p>
+</div>
+<div class="section" id="miscellaneous-variables">
+<h3><a class="toc-backref" href="#id8">Miscellaneous Variables</a><a class="headerlink" href="#miscellaneous-variables" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">CFLAGS</span></tt> & <tt class="docutils literal"><span class="pre">CPPFLAGS</span></tt></p>
+<blockquote>
+<div><p>This variable can be used to add options to the C and C++ compiler,
+respectively. It is typically used to add options that tell the compiler
+the location of additional directories to search for header files.</p>
+<p>It is highly suggested that you append to <tt class="docutils literal"><span class="pre">CFLAGS</span></tt> and <tt class="docutils literal"><span class="pre">CPPFLAGS</span></tt> as
+opposed to overwriting them. The master <tt class="docutils literal"><span class="pre">Makefiles</span></tt> may already have
+useful options in them that you may not want to overwrite.</p>
+</div></blockquote>
+</div>
+</div>
+<div class="section" id="placement-of-object-code">
+<h2><a class="toc-backref" href="#id9">Placement of Object Code</a><a class="headerlink" href="#placement-of-object-code" title="Permalink to this headline">¶</a></h2>
+<p>The final location of built libraries and executables will depend upon whether
+you do a <tt class="docutils literal"><span class="pre">Debug</span></tt>, <tt class="docutils literal"><span class="pre">Release</span></tt>, or <tt class="docutils literal"><span class="pre">Profile</span></tt> build.</p>
+<p>Libraries</p>
+<blockquote>
+<div>All libraries (static and dynamic) will be stored in
+<tt class="docutils literal"><span class="pre">PROJ_OBJ_ROOT/<type>/lib</span></tt>, where <em>type</em> is <tt class="docutils literal"><span class="pre">Debug</span></tt>, <tt class="docutils literal"><span class="pre">Release</span></tt>, or
+<tt class="docutils literal"><span class="pre">Profile</span></tt> for a debug, optimized, or profiled build, respectively.</div></blockquote>
+<p>Executables</p>
+<blockquote>
+<div>All executables will be stored in <tt class="docutils literal"><span class="pre">PROJ_OBJ_ROOT/<type>/bin</span></tt>, where <em>type</em>
+is <tt class="docutils literal"><span class="pre">Debug</span></tt>, <tt class="docutils literal"><span class="pre">Release</span></tt>, or <tt class="docutils literal"><span class="pre">Profile</span></tt> for a debug, optimized, or
+profiled build, respectively.</div></blockquote>
+</div>
+<div class="section" id="further-help">
+<h2><a class="toc-backref" href="#id10">Further Help</a><a class="headerlink" href="#further-help" title="Permalink to this headline">¶</a></h2>
+<p>If you have any questions or need any help creating an LLVM project, the LLVM
+team would be more than happy to help. You can always post your questions to
+the <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/">LLVM Developers Mailing List</a>.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="LLVMBuild.html" title="LLVMBuild Guide"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="DeveloperPolicy.html" title="LLVM Developer Policy"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/Proposals/GitHubMove.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/Proposals/GitHubMove.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/Proposals/GitHubMove.html (added)
+++ www-releases/trunk/6.0.1/docs/Proposals/GitHubMove.html Mon Jul 2 16:21:43 2018
@@ -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="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Moving LLVM Projects to GitHub — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="next" title="Vectorization Plan" href="VectorizationPlan.html" />
+ <link rel="prev" title="LLVM Community Code of Conduct" href="../CodeOfConduct.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="VectorizationPlan.html" title="Vectorization Plan"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="../CodeOfConduct.html" title="LLVM Community Code of Conduct"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="moving-llvm-projects-to-github">
+<h1>Moving LLVM Projects to GitHub<a class="headerlink" href="#moving-llvm-projects-to-github" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="table-of-contents">
+<p class="topic-title first">Table of Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id26">Introduction</a></li>
+<li><a class="reference internal" href="#what-this-proposal-is-not-about" id="id27">What This Proposal is <em>Not</em> About</a></li>
+<li><a class="reference internal" href="#why-git-and-why-github" id="id28">Why Git, and Why GitHub?</a><ul>
+<li><a class="reference internal" href="#why-move-at-all" id="id29">Why Move At All?</a></li>
+<li><a class="reference internal" href="#why-git" id="id30">Why Git?</a></li>
+<li><a class="reference internal" href="#why-github" id="id31">Why GitHub?</a></li>
+<li><a class="reference internal" href="#on-managing-revision-numbers-with-git" id="id32">On Managing Revision Numbers with Git</a></li>
+<li><a class="reference internal" href="#what-about-branches-and-merges" id="id33">What About Branches and Merges?</a></li>
+<li><a class="reference internal" href="#what-about-commit-emails" id="id34">What About Commit Emails?</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#straw-man-migration-plan" id="id35">Straw Man Migration Plan</a><ul>
+<li><a class="reference internal" href="#step-1-before-the-move" id="id36">Step #1 : Before The Move</a></li>
+<li><a class="reference internal" href="#step-2-git-move" id="id37">Step #2 : Git Move</a></li>
+<li><a class="reference internal" href="#step-3-write-access-move" id="id38">Step #3: Write Access Move</a></li>
+<li><a class="reference internal" href="#step-4-post-move" id="id39">Step #4 : Post Move</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#one-or-multiple-repositories" id="id40">One or Multiple Repositories?</a><ul>
+<li><a class="reference internal" href="#multirepo-variant" id="id41">Multirepo Variant</a><ul>
+<li><a class="reference internal" href="#umbrella-repository" id="id42">Umbrella Repository</a></li>
+<li><a class="reference internal" href="#living-downstream" id="id43">Living Downstream</a></li>
+<li><a class="reference internal" href="#multirepo-preview" id="id44">Multirepo Preview</a></li>
+<li><a class="reference internal" href="#concerns" id="id45">Concerns</a></li>
+<li><a class="reference internal" href="#workflows" id="id46">Workflows</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#monorepo-variant" id="id47">Monorepo Variant</a><ul>
+<li><a class="reference internal" href="#building-a-single-sub-project" id="id48">Building a single sub-project</a></li>
+<li><a class="reference internal" href="#read-write-sub-project-mirrors" id="id49">Read/write sub-project mirrors</a></li>
+<li><a class="reference internal" href="#id9" id="id50">Living Downstream</a></li>
+<li><a class="reference internal" href="#monorepo-preview" id="id51">Monorepo Preview</a></li>
+<li><a class="reference internal" href="#id12" id="id52">Concerns</a></li>
+<li><a class="reference internal" href="#id13" id="id53">Workflows</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#multi-mono-hybrid-variant" id="id54">Multi/Mono Hybrid Variant</a><ul>
+<li><a class="reference internal" href="#id14" id="id55">Concerns</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#workflow-before-after" id="id56">Workflow Before/After</a><ul>
+<li><a class="reference internal" href="#checkout-clone-a-single-project-without-commit-access" id="id57">Checkout/Clone a Single Project, without Commit Access</a></li>
+<li><a class="reference internal" href="#checkout-clone-a-single-project-with-commit-access" id="id58">Checkout/Clone a Single Project, with Commit Access</a><ul>
+<li><a class="reference internal" href="#currently" id="id59">Currently</a></li>
+<li><a class="reference internal" href="#workflow-multicheckout-nocommit" id="id60">Multirepo Variant</a></li>
+<li><a class="reference internal" href="#workflow-monocheckout-nocommit" id="id61">Monorepo Variant</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#checkout-clone-multiple-projects-with-commit-access" id="id62">Checkout/Clone Multiple Projects, with Commit Access</a><ul>
+<li><a class="reference internal" href="#id17" id="id63">Currently</a></li>
+<li><a class="reference internal" href="#workflow-multicheckout-multicommit" id="id64">Multirepo Variant</a></li>
+<li><a class="reference internal" href="#workflow-monocheckout-multicommit" id="id65">Monorepo Variant</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#commit-an-api-change-in-llvm-and-update-the-sub-projects" id="id66">Commit an API Change in LLVM and Update the Sub-projects</a></li>
+<li><a class="reference internal" href="#branching-stashing-updating-for-local-development-or-experiments" id="id67">Branching/Stashing/Updating for Local Development or Experiments</a><ul>
+<li><a class="reference internal" href="#id20" id="id68">Currently</a></li>
+<li><a class="reference internal" href="#workflow-multi-branching" id="id69">Multirepo Variant</a></li>
+<li><a class="reference internal" href="#workflow-mono-branching" id="id70">Monorepo Variant</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#bisecting" id="id71">Bisecting</a><ul>
+<li><a class="reference internal" href="#id23" id="id72">Currently</a></li>
+<li><a class="reference internal" href="#workflow-multi-bisecting" id="id73">Multirepo Variant</a></li>
+<li><a class="reference internal" href="#workflow-mono-bisecting" id="id74">Monorepo Variant</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#references" id="id75">References</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id26">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we are proposing such a move and how people (and validation
+infrastructure) will continue to work with a Git-based LLVM.</p>
+<p>There will be a survey pointing at this document which we’ll use to gauge the
+community’s reaction and, if we collectively decide to move, the time-frame. Be
+sure to make your view count.</p>
+<p>Additionally, we will discuss this during a BoF at the next US LLVM Developer
+meeting (<a class="reference external" href="http://llvm.org/devmtg/2016-11/">http://llvm.org/devmtg/2016-11/</a>).</p>
+</div>
+<div class="section" id="what-this-proposal-is-not-about">
+<h2><a class="toc-backref" href="#id27">What This Proposal is <em>Not</em> About</a><a class="headerlink" href="#what-this-proposal-is-not-about" title="Permalink to this headline">¶</a></h2>
+<p>Changing the development policy.</p>
+<p>This proposal relates only to moving the hosting of our source-code repository
+from SVN hosted on our own servers to Git hosted on GitHub. We are not proposing
+using GitHub’s issue tracker, pull-requests, or code-review.</p>
+<p>Contributors will continue to earn commit access on demand under the Developer
+Policy, except that that a GitHub account will be required instead of SVN
+username/password-hash.</p>
+</div>
+<div class="section" id="why-git-and-why-github">
+<h2><a class="toc-backref" href="#id28">Why Git, and Why GitHub?</a><a class="headerlink" href="#why-git-and-why-github" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="why-move-at-all">
+<h3><a class="toc-backref" href="#id29">Why Move At All?</a><a class="headerlink" href="#why-move-at-all" title="Permalink to this headline">¶</a></h3>
+<p>This discussion began because we currently host our own Subversion server
+and Git mirror on a voluntary basis. The LLVM Foundation sponsors the server and
+provides limited support, but there is only so much it can do.</p>
+<p>Volunteers are not sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don’t have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.</p>
+<p>We should take advantage of one of the services out there (GitHub, GitLab,
+and BitBucket, among others) that offer better service (24/7 stability, disk
+space, Git server, code browsing, forking facilities, etc) for free.</p>
+</div>
+<div class="section" id="why-git">
+<h3><a class="toc-backref" href="#id30">Why Git?</a><a class="headerlink" href="#why-git" title="Permalink to this headline">¶</a></h3>
+<p>Many new coders nowadays start with Git, and a lot of people have never used
+SVN, CVS, or anything else. Websites like GitHub have changed the landscape
+of open source contributions, reducing the cost of first contribution and
+fostering collaboration.</p>
+<p>Git is also the version control many LLVM developers use. Despite the
+sources being stored in a SVN server, these developers are already using Git
+through the Git-SVN integration.</p>
+<p>Git allows you to:</p>
+<ul class="simple">
+<li>Commit, squash, merge, and fork locally without touching the remote server.</li>
+<li>Maintain local branches, enabling multiple threads of development.</li>
+<li>Collaborate on these branches (e.g. through your own fork of llvm on GitHub).</li>
+<li>Inspect the repository history (blame, log, bisect) without Internet access.</li>
+<li>Maintain remote forks and branches on Git hosting services and
+integrate back to the main repository.</li>
+</ul>
+<p>In addition, because Git seems to be replacing many OSS projects’ version
+control systems, there are many tools that are built over Git.
+Future tooling may support Git first (if not only).</p>
+</div>
+<div class="section" id="why-github">
+<h3><a class="toc-backref" href="#id31">Why GitHub?</a><a class="headerlink" href="#why-github" title="Permalink to this headline">¶</a></h3>
+<p>GitHub, like GitLab and BitBucket, provides free code hosting for open source
+projects. Any of these could replace the code-hosting infrastructure that we
+have today.</p>
+<p>These services also have a dedicated team to monitor, migrate, improve and
+distribute the contents of the repositories depending on region and load.</p>
+<p>GitHub has one important advantage over GitLab and
+BitBucket: it offers read-write <strong>SVN</strong> access to the repository
+(<a class="reference external" href="https://github.com/blog/626-announcing-svn-support">https://github.com/blog/626-announcing-svn-support</a>).
+This would enable people to continue working post-migration as though our code
+were still canonically in an SVN repository.</p>
+<p>In addition, there are already multiple LLVM mirrors on GitHub, indicating that
+part of our community has already settled there.</p>
+</div>
+<div class="section" id="on-managing-revision-numbers-with-git">
+<h3><a class="toc-backref" href="#id32">On Managing Revision Numbers with Git</a><a class="headerlink" href="#on-managing-revision-numbers-with-git" title="Permalink to this headline">¶</a></h3>
+<p>The current SVN repository hosts all the LLVM sub-projects alongside each other.
+A single revision number (e.g. r123456) thus identifies a consistent version of
+all LLVM sub-projects.</p>
+<p>Git does not use sequential integer revision number but instead uses a hash to
+identify each commit. (Linus mentioned that the lack of such revision number
+is “the only real design mistake” in Git <a class="reference internal" href="#torvaldrevnum">[TorvaldRevNum]</a>.)</p>
+<p>The loss of a sequential integer revision number has been a sticking point in
+past discussions about Git:</p>
+<ul class="simple">
+<li>“The ‘branch’ I most care about is mainline, and losing the ability to say
+‘fixed in r1234’ (with some sort of monotonically increasing number) would
+be a tragic loss.” <a class="reference internal" href="#lattnerrevnum">[LattnerRevNum]</a></li>
+<li>“I like those results sorted by time and the chronology should be obvious, but
+timestamps are incredibly cumbersome and make it difficult to verify that a
+given checkout matches a given set of results.” <a class="reference internal" href="#trickrevnum">[TrickRevNum]</a></li>
+<li>“There is still the major regression with unreadable version numbers.
+Given the amount of Bugzilla traffic with ‘Fixed in...’, that’s a
+non-trivial issue.” <a class="reference internal" href="#jsonnrevnum">[JSonnRevNum]</a></li>
+<li>“Sequential IDs are important for LNT and llvmlab bisection tool.” <a class="reference internal" href="#matthewsrevnum">[MatthewsRevNum]</a>.</li>
+</ul>
+<p>However, Git can emulate this increasing revision number:
+<tt class="docutils literal"><span class="pre">git</span> <span class="pre">rev-list</span> <span class="pre">--count</span> <span class="pre"><commit-hash></span></tt>. This identifier is unique only
+within a single branch, but this means the tuple <cite>(num, branch-name)</cite> uniquely
+identifies a commit.</p>
+<p>We can thus use this revision number to ensure that e.g. <cite>clang -v</cite> reports a
+user-friendly revision number (e.g. <cite>master-12345</cite> or <cite>4.0-5321</cite>), addressing
+the objections raised above with respect to this aspect of Git.</p>
+</div>
+<div class="section" id="what-about-branches-and-merges">
+<h3><a class="toc-backref" href="#id33">What About Branches and Merges?</a><a class="headerlink" href="#what-about-branches-and-merges" title="Permalink to this headline">¶</a></h3>
+<p>In contrast to SVN, Git makes branching easy. Git’s commit history is
+represented as a DAG, a departure from SVN’s linear history. However, we propose
+to mandate making merge commits illegal in our canonical Git repository.</p>
+<p>Unfortunately, GitHub does not support server side hooks to enforce such a
+policy. We must rely on the community to avoid pushing merge commits.</p>
+<p>GitHub offers a feature called <cite>Status Checks</cite>: a branch protected by
+<cite>status checks</cite> requires commits to be whitelisted before the push can happen.
+We could supply a pre-push hook on the client side that would run and check the
+history, before whitelisting the commit being pushed <a class="reference internal" href="#statuschecks">[statuschecks]</a>.
+However this solution would be somewhat fragile (how do you update a script
+installed on every developer machine?) and prevents SVN access to the
+repository.</p>
+</div>
+<div class="section" id="what-about-commit-emails">
+<h3><a class="toc-backref" href="#id34">What About Commit Emails?</a><a class="headerlink" href="#what-about-commit-emails" title="Permalink to this headline">¶</a></h3>
+<p>We will need a new bot to send emails for each commit. This proposal leaves the
+email format unchanged besides the commit URL.</p>
+</div>
+</div>
+<div class="section" id="straw-man-migration-plan">
+<h2><a class="toc-backref" href="#id35">Straw Man Migration Plan</a><a class="headerlink" href="#straw-man-migration-plan" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="step-1-before-the-move">
+<h3><a class="toc-backref" href="#id36">Step #1 : Before The Move</a><a class="headerlink" href="#step-1-before-the-move" title="Permalink to this headline">¶</a></h3>
+<ol class="arabic simple">
+<li>Update docs to mention the move, so people are aware of what is going on.</li>
+<li>Set up a read-only version of the GitHub project, mirroring our current SVN
+repository.</li>
+<li>Add the required bots to implement the commit emails, as well as the
+umbrella repository update (if the multirepo is selected) or the read-only
+Git views for the sub-projects (if the monorepo is selected).</li>
+</ol>
+</div>
+<div class="section" id="step-2-git-move">
+<h3><a class="toc-backref" href="#id37">Step #2 : Git Move</a><a class="headerlink" href="#step-2-git-move" title="Permalink to this headline">¶</a></h3>
+<ol class="arabic simple" start="4">
+<li>Update the buildbots to pick up updates and commits from the GitHub
+repository. Not all bots have to migrate at this point, but it’ll help
+provide infrastructure testing.</li>
+<li>Update Phabricator to pick up commits from the GitHub repository.</li>
+<li>LNT and llvmlab have to be updated: they rely on unique monotonically
+increasing integer across branch <a class="reference internal" href="#matthewsrevnum">[MatthewsRevNum]</a>.</li>
+<li>Instruct downstream integrators to pick up commits from the GitHub
+repository.</li>
+<li>Review and prepare an update for the LLVM documentation.</li>
+</ol>
+<p>Until this point nothing has changed for developers, it will just
+boil down to a lot of work for buildbot and other infrastructure
+owners.</p>
+<p>The migration will pause here until all dependencies have cleared, and all
+problems have been solved.</p>
+</div>
+<div class="section" id="step-3-write-access-move">
+<h3><a class="toc-backref" href="#id38">Step #3: Write Access Move</a><a class="headerlink" href="#step-3-write-access-move" title="Permalink to this headline">¶</a></h3>
+<ol class="arabic simple" start="9">
+<li>Collect developers’ GitHub account information, and add them to the project.</li>
+<li>Switch the SVN repository to read-only and allow pushes to the GitHub repository.</li>
+<li>Update the documentation.</li>
+<li>Mirror Git to SVN.</li>
+</ol>
+</div>
+<div class="section" id="step-4-post-move">
+<h3><a class="toc-backref" href="#id39">Step #4 : Post Move</a><a class="headerlink" href="#step-4-post-move" title="Permalink to this headline">¶</a></h3>
+<ol class="arabic simple" start="13">
+<li>Archive the SVN repository.</li>
+<li>Update links on the LLVM website pointing to viewvc/klaus/phab etc. to
+point to GitHub instead.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="one-or-multiple-repositories">
+<h2><a class="toc-backref" href="#id40">One or Multiple Repositories?</a><a class="headerlink" href="#one-or-multiple-repositories" title="Permalink to this headline">¶</a></h2>
+<p>There are two major variants for how to structure our Git repository: The
+“multirepo” and the “monorepo”.</p>
+<div class="section" id="multirepo-variant">
+<h3><a class="toc-backref" href="#id41">Multirepo Variant</a><a class="headerlink" href="#multirepo-variant" title="Permalink to this headline">¶</a></h3>
+<p>This variant recommends moving each LLVM sub-project to a separate Git
+repository. This mimics the existing official read-only Git repositories
+(e.g., <a class="reference external" href="http://llvm.org/git/compiler-rt.git">http://llvm.org/git/compiler-rt.git</a>), and creates new canonical
+repositories for each sub-project.</p>
+<p>This will allow the individual sub-projects to remain distinct: a
+developer interested only in compiler-rt can checkout only this repository,
+build it, and work in isolation of the other sub-projects.</p>
+<p>A key need is to be able to check out multiple projects (i.e. lldb+clang+llvm or
+clang+llvm+libcxx for example) at a specific revision.</p>
+<p>A tuple of revisions (one entry per repository) accurately describes the state
+across the sub-projects.
+For example, a given version of clang would be
+<em><LLVM-12345, clang-5432, libcxx-123, etc.></em>.</p>
+<div class="section" id="umbrella-repository">
+<h4><a class="toc-backref" href="#id42">Umbrella Repository</a><a class="headerlink" href="#umbrella-repository" title="Permalink to this headline">¶</a></h4>
+<p>To make this more convenient, a separate <em>umbrella</em> repository will be
+provided. This repository will be used for the sole purpose of understanding
+the sequence in which commits were pushed to the different repositories and to
+provide a single revision number.</p>
+<p>This umbrella repository will be read-only and continuously updated
+to record the above tuple. The proposed form to record this is to use Git
+<a class="reference internal" href="#submodules">[submodules]</a>, possibly along with a set of scripts to help check out a
+specific revision of the LLVM distribution.</p>
+<p>A regular LLVM developer does not need to interact with the umbrella repository
+– the individual repositories can be checked out independently – but you would
+need to use the umbrella repository to bisect multiple sub-projects at the same
+time, or to check-out old revisions of LLVM with another sub-project at a
+consistent state.</p>
+<p>This umbrella repository will be updated automatically by a bot (running on
+notice from a webhook on every push, and periodically) on a per commit basis: a
+single commit in the umbrella repository would match a single commit in a
+sub-project.</p>
+</div>
+<div class="section" id="living-downstream">
+<h4><a class="toc-backref" href="#id43">Living Downstream</a><a class="headerlink" href="#living-downstream" title="Permalink to this headline">¶</a></h4>
+<p>Downstream SVN users can use the read/write SVN bridges with the following
+caveats:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Be prepared for a one-time change to the upstream revision numbers.</li>
+<li>The upstream sub-project revision numbers will no longer be in sync.</li>
+</ul>
+</div></blockquote>
+<p>Downstream Git users can continue without any major changes, with the minor
+change of upstreaming using <cite>git push</cite> instead of <cite>git svn dcommit</cite>.</p>
+<p>Git users also have the option of adopting an umbrella repository downstream.
+The tooling for the upstream umbrella can easily be reused for downstream needs,
+incorporating extra sub-projects and branching in parallel with sub-project
+branches.</p>
+</div>
+<div class="section" id="multirepo-preview">
+<h4><a class="toc-backref" href="#id44">Multirepo Preview</a><a class="headerlink" href="#multirepo-preview" title="Permalink to this headline">¶</a></h4>
+<p>As a preview (disclaimer: this rough prototype, not polished and not
+representative of the final solution), you can look at the following:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Repository: <a class="reference external" href="https://github.com/llvm-beanz/llvm-submodules">https://github.com/llvm-beanz/llvm-submodules</a></li>
+<li>Update bot: <a class="reference external" href="http://beanz-bot.com:8180/jenkins/job/submodule-update/">http://beanz-bot.com:8180/jenkins/job/submodule-update/</a></li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="concerns">
+<h4><a class="toc-backref" href="#id45">Concerns</a><a class="headerlink" href="#concerns" title="Permalink to this headline">¶</a></h4>
+<blockquote>
+<div><ul class="simple">
+<li>Because GitHub does not allow server-side hooks, and because there is no
+“push timestamp” in Git, the umbrella repository sequence isn’t totally
+exact: commits from different repositories pushed around the same time can
+appear in different orders. However, we don’t expect it to be the common case
+or to cause serious issues in practice.</li>
+<li>You can’t have a single cross-projects commit that would update both LLVM and
+other sub-projects (something that can be achieved now). It would be possible
+to establish a protocol whereby users add a special token to their commit
+messages that causes the umbrella repo’s updater bot to group all of them
+into a single revision.</li>
+<li>Another option is to group commits that were pushed closely enough together
+in the umbrella repository. This has the advantage of allowing cross-project
+commits, and is less sensitive to mis-ordering commits. However, this has the
+potential to group unrelated commits together, especially if the bot goes
+down and needs to catch up.</li>
+<li>This variant relies on heavier tooling. But the current prototype shows that
+it is not out-of-reach.</li>
+<li>Submodules don’t have a good reputation / are complicating the command line.
+However, in the proposed setup, a regular developer will seldom interact with
+submodules directly, and certainly never update them.</li>
+<li>Refactoring across projects is not friendly: taking some functions from clang
+to make it part of a utility in libSupport wouldn’t carry the history of the
+code in the llvm repo, preventing recursively applying <cite>git blame</cite> for
+instance. However, this is not very different than how most people are
+Interacting with the repository today, by splitting such change in multiple
+commits.</li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="workflows">
+<h4><a class="toc-backref" href="#id46">Workflows</a><a class="headerlink" href="#workflows" title="Permalink to this headline">¶</a></h4>
+<blockquote>
+<div><ul class="simple">
+<li><a class="reference internal" href="#workflow-checkout-commit"><em>Checkout/Clone a Single Project, without Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-multicheckout-nocommit"><em>Checkout/Clone a Single Project, with Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-multicheckout-multicommit"><em>Checkout/Clone Multiple Projects, with Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-cross-repo-commit"><em>Commit an API Change in LLVM and Update the Sub-projects</em></a>.</li>
+<li><a class="reference internal" href="#workflow-multi-branching"><em>Branching/Stashing/Updating for Local Development or Experiments</em></a>.</li>
+<li><a class="reference internal" href="#workflow-multi-bisecting"><em>Bisecting</em></a>.</li>
+</ul>
+</div></blockquote>
+</div>
+</div>
+<div class="section" id="monorepo-variant">
+<h3><a class="toc-backref" href="#id47">Monorepo Variant</a><a class="headerlink" href="#monorepo-variant" title="Permalink to this headline">¶</a></h3>
+<p>This variant recommends moving all LLVM sub-projects to a single Git repository,
+similar to <a class="reference external" href="https://github.com/llvm-project/llvm-project">https://github.com/llvm-project/llvm-project</a>.
+This would mimic an export of the current SVN repository, with each sub-project
+having its own top-level directory.
+Not all sub-projects are used for building toolchains. In practice, www/
+and test-suite/ will probably stay out of the monorepo.</p>
+<p>Putting all sub-projects in a single checkout makes cross-project refactoring
+naturally simple:</p>
+<blockquote>
+<div><ul class="simple">
+<li>New sub-projects can be trivially split out for better reuse and/or layering
+(e.g., to allow libSupport and/or LIT to be used by runtimes without adding a
+dependency on LLVM).</li>
+<li>Changing an API in LLVM and upgrading the sub-projects will always be done in
+a single commit, designing away a common source of temporary build breakage.</li>
+<li>Moving code across sub-project (during refactoring for instance) in a single
+commit enables accurate <cite>git blame</cite> when tracking code change history.</li>
+<li>Tooling based on <cite>git grep</cite> works natively across sub-projects, allowing to
+easier find refactoring opportunities across projects (for example reusing a
+datastructure initially in LLDB by moving it into libSupport).</li>
+<li>Having all the sources present encourages maintaining the other sub-projects
+when changing API.</li>
+</ul>
+</div></blockquote>
+<p>Finally, the monorepo maintains the property of the existing SVN repository that
+the sub-projects move synchronously, and a single revision number (or commit
+hash) identifies the state of the development across all projects.</p>
+<div class="section" id="building-a-single-sub-project">
+<span id="build-single-project"></span><h4><a class="toc-backref" href="#id48">Building a single sub-project</a><a class="headerlink" href="#building-a-single-sub-project" title="Permalink to this headline">¶</a></h4>
+<p>Nobody will be forced to build unnecessary projects. The exact structure
+is TBD, but making it trivial to configure builds for a single sub-project
+(or a subset of sub-projects) is a hard requirement.</p>
+<p>As an example, it could look like the following:</p>
+<div class="highlight-python"><pre>mkdir build && cd build
+# Configure only LLVM (default)
+cmake path/to/monorepo
+# Configure LLVM and lld
+cmake path/to/monorepo -DLLVM_ENABLE_PROJECTS=lld
+# Configure LLVM and clang
+cmake path/to/monorepo -DLLVM_ENABLE_PROJECTS=clang</pre>
+</div>
+</div>
+<div class="section" id="read-write-sub-project-mirrors">
+<span id="git-svn-mirror"></span><h4><a class="toc-backref" href="#id49">Read/write sub-project mirrors</a><a class="headerlink" href="#read-write-sub-project-mirrors" title="Permalink to this headline">¶</a></h4>
+<p>With the Monorepo, the existing single-subproject mirrors (e.g.
+<a class="reference external" href="http://llvm.org/git/compiler-rt.git">http://llvm.org/git/compiler-rt.git</a>) with git-svn read-write access would
+continue to be maintained: developers would continue to be able to use the
+existing single-subproject git repositories as they do today, with <em>no changes
+to workflow</em>. Everything (git fetch, git svn dcommit, etc.) could continue to
+work identically to how it works today. The monorepo can be set-up such that the
+SVN revision number matches the SVN revision in the GitHub SVN-bridge.</p>
+</div>
+<div class="section" id="id9">
+<h4><a class="toc-backref" href="#id50">Living Downstream</a><a class="headerlink" href="#id9" title="Permalink to this headline">¶</a></h4>
+<p>Downstream SVN users can use the read/write SVN bridge. The SVN revision
+number can be preserved in the monorepo, minimizing the impact.</p>
+<p>Downstream Git users can continue without any major changes, by using the
+git-svn mirrors on top of the SVN bridge.</p>
+<p>Git users can also work upstream with monorepo even if their downstream
+fork has split repositories. They can apply patches in the appropriate
+subdirectories of the monorepo using, e.g., <cite>git am –directory=...</cite>, or
+plain <cite>diff</cite> and <cite>patch</cite>.</p>
+<p>Alternatively, Git users can migrate their own fork to the monorepo. As a
+demonstration, we’ve migrated the “CHERI” fork to the monorepo in two ways:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Using a script that rewrites history (including merges) so that it looks
+like the fork always lived in the monorepo <a class="reference internal" href="#lebarcheri">[LebarCHERI]</a>. The upside of
+this is when you check out an old revision, you get a copy of all llvm
+sub-projects at a consistent revision. (For instance, if it’s a clang
+fork, when you check out an old revision you’ll get a consistent version
+of llvm proper.) The downside is that this changes the fork’s commit
+hashes.</li>
+<li>Merging the fork into the monorepo <a class="reference internal" href="#aminicheri">[AminiCHERI]</a>. This preserves the
+fork’s commit hashes, but when you check out an old commit you only get
+the one sub-project.</li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="monorepo-preview">
+<h4><a class="toc-backref" href="#id51">Monorepo Preview</a><a class="headerlink" href="#monorepo-preview" title="Permalink to this headline">¶</a></h4>
+<p>As a preview (disclaimer: this rough prototype, not polished and not
+representative of the final solution), you can look at the following:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Full Repository: <a class="reference external" href="https://github.com/joker-eph/llvm-project">https://github.com/joker-eph/llvm-project</a></li>
+<li>Single sub-project view with <em>SVN write access</em> to the full repo:
+<a class="reference external" href="https://github.com/joker-eph/compiler-rt">https://github.com/joker-eph/compiler-rt</a></li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="id12">
+<h4><a class="toc-backref" href="#id52">Concerns</a><a class="headerlink" href="#id12" title="Permalink to this headline">¶</a></h4>
+<blockquote>
+<div><ul class="simple">
+<li>Using the monolithic repository may add overhead for those contributing to a
+standalone sub-project, particularly on runtimes like libcxx and compiler-rt
+that don’t rely on LLVM; currently, a fresh clone of libcxx is only 15MB (vs.
+1GB for the monorepo), and the commit rate of LLVM may cause more frequent
+<cite>git push</cite> collisions when upstreaming. Affected contributors can continue to
+use the SVN bridge or the single-subproject Git mirrors with git-svn for
+read-write.</li>
+<li>Using the monolithic repository may add overhead for those <em>integrating</em> a
+standalone sub-project, even if they aren’t contributing to it, due to the
+same disk space concern as the point above. The availability of the
+sub-project Git mirror addresses this, even without SVN access.</li>
+<li>Preservation of the existing read/write SVN-based workflows relies on the
+GitHub SVN bridge, which is an extra dependency. Maintaining this locks us
+into GitHub and could restrict future workflow changes.</li>
+</ul>
+</div></blockquote>
+</div>
+<div class="section" id="id13">
+<h4><a class="toc-backref" href="#id53">Workflows</a><a class="headerlink" href="#id13" title="Permalink to this headline">¶</a></h4>
+<blockquote>
+<div><ul class="simple">
+<li><a class="reference internal" href="#workflow-checkout-commit"><em>Checkout/Clone a Single Project, without Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-monocheckout-nocommit"><em>Checkout/Clone a Single Project, with Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-monocheckout-multicommit"><em>Checkout/Clone Multiple Projects, with Commit Access</em></a>.</li>
+<li><a class="reference internal" href="#workflow-cross-repo-commit"><em>Commit an API Change in LLVM and Update the Sub-projects</em></a>.</li>
+<li><a class="reference internal" href="#workflow-mono-branching"><em>Branching/Stashing/Updating for Local Development or Experiments</em></a>.</li>
+<li><a class="reference internal" href="#workflow-mono-bisecting"><em>Bisecting</em></a>.</li>
+</ul>
+</div></blockquote>
+</div>
+</div>
+<div class="section" id="multi-mono-hybrid-variant">
+<h3><a class="toc-backref" href="#id54">Multi/Mono Hybrid Variant</a><a class="headerlink" href="#multi-mono-hybrid-variant" title="Permalink to this headline">¶</a></h3>
+<p>This variant recommends moving only the LLVM sub-projects that are <em>rev-locked</em>
+to LLVM into a monorepo (clang, lld, lldb, ...), following the multirepo
+proposal for the rest. While neither variant recommends combining sub-projects
+like www/ and test-suite/ (which are completely standalone), this goes further
+and keeps sub-projects like libcxx and compiler-rt in their own distinct
+repositories.</p>
+<div class="section" id="id14">
+<h4><a class="toc-backref" href="#id55">Concerns</a><a class="headerlink" href="#id14" title="Permalink to this headline">¶</a></h4>
+<blockquote>
+<div><ul class="simple">
+<li>This has most disadvantages of multirepo and monorepo, without bringing many
+of the advantages.</li>
+<li>Downstream have to upgrade to the monorepo structure, but only partially. So
+they will keep the infrastructure to integrate the other separate
+sub-projects.</li>
+<li>All projects that use LIT for testing are effectively rev-locked to LLVM.
+Furthermore, some runtimes (like compiler-rt) are rev-locked with Clang.
+It’s not clear where to draw the lines.</li>
+</ul>
+</div></blockquote>
+</div>
+</div>
+</div>
+<div class="section" id="workflow-before-after">
+<h2><a class="toc-backref" href="#id56">Workflow Before/After</a><a class="headerlink" href="#workflow-before-after" title="Permalink to this headline">¶</a></h2>
+<p>This section goes through a few examples of workflows, intended to illustrate
+how end-users or developers would interact with the repository for
+various use-cases.</p>
+<div class="section" id="checkout-clone-a-single-project-without-commit-access">
+<span id="workflow-checkout-commit"></span><h3><a class="toc-backref" href="#id57">Checkout/Clone a Single Project, without Commit Access</a><a class="headerlink" href="#checkout-clone-a-single-project-without-commit-access" title="Permalink to this headline">¶</a></h3>
+<p>Except the URL, nothing changes. The possibilities today are:</p>
+<div class="highlight-python"><pre>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+# or with Git
+git clone http://llvm.org/git/llvm.git</pre>
+</div>
+<p>After the move to GitHub, you would do either:</p>
+<div class="highlight-python"><pre>git clone https://github.com/llvm-project/llvm.git
+# or using the GitHub svn native bridge
+svn co https://github.com/llvm-project/llvm/trunk</pre>
+</div>
+<p>The above works for both the monorepo and the multirepo, as we’ll maintain the
+existing read-only views of the individual sub-projects.</p>
+</div>
+<div class="section" id="checkout-clone-a-single-project-with-commit-access">
+<h3><a class="toc-backref" href="#id58">Checkout/Clone a Single Project, with Commit Access</a><a class="headerlink" href="#checkout-clone-a-single-project-with-commit-access" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="currently">
+<h4><a class="toc-backref" href="#id59">Currently</a><a class="headerlink" href="#currently" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-python"><pre># direct SVN checkout
+svn co https://user@llvm.org/svn/llvm-project/llvm/trunk llvm
+# or using the read-only Git view, with git-svn
+git clone http://llvm.org/git/llvm.git
+cd llvm
+git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
+git config svn-remote.svn.fetch :refs/remotes/origin/master
+git svn rebase -l # -l avoids fetching ahead of the git mirror.</pre>
+</div>
+<p>Commits are performed using <cite>svn commit</cite> or with the sequence <cite>git commit</cite> and
+<cite>git svn dcommit</cite>.</p>
+</div>
+<div class="section" id="workflow-multicheckout-nocommit">
+<span id="id15"></span><h4><a class="toc-backref" href="#id60">Multirepo Variant</a><a class="headerlink" href="#workflow-multicheckout-nocommit" title="Permalink to this headline">¶</a></h4>
+<p>With the multirepo variant, nothing changes but the URL, and commits can be
+performed using <cite>svn commit</cite> or <cite>git commit</cite> and <cite>git push</cite>:</p>
+<div class="highlight-python"><pre>git clone https://github.com/llvm/llvm.git llvm
+# or using the GitHub svn native bridge
+svn co https://github.com/llvm/llvm/trunk/ llvm</pre>
+</div>
+</div>
+<div class="section" id="workflow-monocheckout-nocommit">
+<span id="id16"></span><h4><a class="toc-backref" href="#id61">Monorepo Variant</a><a class="headerlink" href="#workflow-monocheckout-nocommit" title="Permalink to this headline">¶</a></h4>
+<p>With the monorepo variant, there are a few options, depending on your
+constraints. First, you could just clone the full repository:</p>
+<div class="highlight-python"><pre>git clone https://github.com/llvm/llvm-projects.git llvm
+# or using the GitHub svn native bridge
+svn co https://github.com/llvm/llvm-projects/trunk/ llvm</pre>
+</div>
+<p>At this point you have every sub-project (llvm, clang, lld, lldb, ...), which
+<a class="reference internal" href="#build-single-project"><em>doesn’t imply you have to build all of them</em></a>. You
+can still build only compiler-rt for instance. In this way it’s not different
+from someone who would check out all the projects with SVN today.</p>
+<p>You can commit as normal using <cite>git commit</cite> and <cite>git push</cite> or <cite>svn commit</cite>, and
+read the history for a single project (<cite>git log libcxx</cite> for example).</p>
+<p>Secondly, there are a few options to avoid checking out all the sources.</p>
+<p><strong>Using the GitHub SVN bridge</strong></p>
+<p>The GitHub SVN native bridge allows to checkout a subdirectory directly:</p>
+<blockquote>
+<div>svn co <a class="reference external" href="https://github.com/llvm/llvm-projects/trunk/compiler-rt">https://github.com/llvm/llvm-projects/trunk/compiler-rt</a> compiler-rt âusername=...</div></blockquote>
+<p>This checks out only compiler-rt and provides commit access using “svn commit”,
+in the same way as it would do today.</p>
+<p><strong>Using a Subproject Git Nirror</strong></p>
+<p>You can use <em>git-svn</em> and one of the sub-project mirrors:</p>
+<div class="highlight-python"><pre># Clone from the single read-only Git repo
+git clone http://llvm.org/git/llvm.git
+cd llvm
+# Configure the SVN remote and initialize the svn metadata
+$ git svn init https://github.com/joker-eph/llvm-project/trunk/llvm âusername=...
+git config svn-remote.svn.fetch :refs/remotes/origin/master
+git svn rebase -l</pre>
+</div>
+<p>In this case the repository contains only a single sub-project, and commits can
+be made using <cite>git svn dcommit</cite>, again exactly as we do today.</p>
+<p><strong>Using a Sparse Checkouts</strong></p>
+<p>You can hide the other directories using a Git sparse checkout:</p>
+<div class="highlight-python"><pre>git config core.sparseCheckout true
+echo /compiler-rt > .git/info/sparse-checkout
+git read-tree -mu HEAD</pre>
+</div>
+<p>The data for all sub-projects is still in your <cite>.git</cite> directory, but in your
+checkout, you only see <cite>compiler-rt</cite>.
+Before you push, you’ll need to fetch and rebase (<cite>git pull –rebase</cite>) as
+usual.</p>
+<p>Note that when you fetch you’ll likely pull in changes to sub-projects you don’t
+care about. If you are using spasre checkout, the files from other projects
+won’t appear on your disk. The only effect is that your commit hash changes.</p>
+<p>You can check whether the changes in the last fetch are relevant to your commit
+by running:</p>
+<div class="highlight-python"><pre>git log origin/master@{1}..origin/master -- libcxx</pre>
+</div>
+<p>This command can be hidden in a script so that <cite>git llvmpush</cite> would perform all
+these steps, fail only if such a dependent change exists, and show immediately
+the change that prevented the push. An immediate repeat of the command would
+(almost) certainly result in a successful push.
+Note that today with SVN or git-svn, this step is not possible since the
+“rebase” implicitly happens while committing (unless a conflict occurs).</p>
+</div>
+</div>
+<div class="section" id="checkout-clone-multiple-projects-with-commit-access">
+<h3><a class="toc-backref" href="#id62">Checkout/Clone Multiple Projects, with Commit Access</a><a class="headerlink" href="#checkout-clone-multiple-projects-with-commit-access" title="Permalink to this headline">¶</a></h3>
+<p>Let’s look how to assemble llvm+clang+libcxx at a given revision.</p>
+<div class="section" id="id17">
+<h4><a class="toc-backref" href="#id63">Currently</a><a class="headerlink" href="#id17" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-python"><pre>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm -r $REVISION
+cd llvm/tools
+svn co http://llvm.org/svn/llvm-project/clang/trunk clang -r $REVISION
+cd ../projects
+svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx -r $REVISION</pre>
+</div>
+<p>Or using git-svn:</p>
+<div class="highlight-python"><pre>git clone http://llvm.org/git/llvm.git
+cd llvm/
+git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
+git config svn-remote.svn.fetch :refs/remotes/origin/master
+git svn rebase -l
+git checkout `git svn find-rev -B r258109`
+cd tools
+git clone http://llvm.org/git/clang.git
+cd clang/
+git svn init https://llvm.org/svn/llvm-project/clang/trunk --username=<username>
+git config svn-remote.svn.fetch :refs/remotes/origin/master
+git svn rebase -l
+git checkout `git svn find-rev -B r258109`
+cd ../../projects/
+git clone http://llvm.org/git/libcxx.git
+cd libcxx
+git svn init https://llvm.org/svn/llvm-project/libcxx/trunk --username=<username>
+git config svn-remote.svn.fetch :refs/remotes/origin/master
+git svn rebase -l
+git checkout `git svn find-rev -B r258109`</pre>
+</div>
+<p>Note that the list would be longer with more sub-projects.</p>
+</div>
+<div class="section" id="workflow-multicheckout-multicommit">
+<span id="id18"></span><h4><a class="toc-backref" href="#id64">Multirepo Variant</a><a class="headerlink" href="#workflow-multicheckout-multicommit" title="Permalink to this headline">¶</a></h4>
+<p>With the multirepo variant, the umbrella repository will be used. This is
+where the mapping from a single revision number to the individual repositories
+revisions is stored.:</p>
+<div class="highlight-python"><pre>git clone https://github.com/llvm-beanz/llvm-submodules
+cd llvm-submodules
+git checkout $REVISION
+git submodule init
+git submodule update clang llvm libcxx
+# the list of sub-project is optional, `git submodule update` would get them all.</pre>
+</div>
+<p>At this point the clang, llvm, and libcxx individual repositories are cloned
+and stored alongside each other. There are CMake flags to describe the directory
+structure; alternatively, you can just symlink <cite>clang</cite> to <cite>llvm/tools/clang</cite>,
+etc.</p>
+<p>Another option is to checkout repositories based on the commit timestamp:</p>
+<div class="highlight-python"><pre>git checkout `git rev-list -n 1 --before="2009-07-27 13:37" master`</pre>
+</div>
+</div>
+<div class="section" id="workflow-monocheckout-multicommit">
+<span id="id19"></span><h4><a class="toc-backref" href="#id65">Monorepo Variant</a><a class="headerlink" href="#workflow-monocheckout-multicommit" title="Permalink to this headline">¶</a></h4>
+<p>The repository contains natively the source for every sub-projects at the right
+revision, which makes this straightforward:</p>
+<div class="highlight-python"><pre>git clone https://github.com/llvm/llvm-projects.git llvm-projects
+cd llvm-projects
+git checkout $REVISION</pre>
+</div>
+<p>As before, at this point clang, llvm, and libcxx are stored in directories
+alongside each other.</p>
+</div>
+</div>
+<div class="section" id="commit-an-api-change-in-llvm-and-update-the-sub-projects">
+<span id="workflow-cross-repo-commit"></span><h3><a class="toc-backref" href="#id66">Commit an API Change in LLVM and Update the Sub-projects</a><a class="headerlink" href="#commit-an-api-change-in-llvm-and-update-the-sub-projects" title="Permalink to this headline">¶</a></h3>
+<p>Today this is possible, even though not common (at least not documented) for
+subversion users and for git-svn users. For example, few Git users try to update
+LLD or Clang in the same commit as they change an LLVM API.</p>
+<p>The multirepo variant does not address this: one would have to commit and push
+separately in every individual repository. It would be possible to establish a
+protocol whereby users add a special token to their commit messages that causes
+the umbrella repo’s updater bot to group all of them into a single revision.</p>
+<p>The monorepo variant handles this natively.</p>
+</div>
+<div class="section" id="branching-stashing-updating-for-local-development-or-experiments">
+<h3><a class="toc-backref" href="#id67">Branching/Stashing/Updating for Local Development or Experiments</a><a class="headerlink" href="#branching-stashing-updating-for-local-development-or-experiments" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id20">
+<h4><a class="toc-backref" href="#id68">Currently</a><a class="headerlink" href="#id20" title="Permalink to this headline">¶</a></h4>
+<p>SVN does not allow this use case, but developers that are currently using
+git-svn can do it. Let’s look in practice what it means when dealing with
+multiple sub-projects.</p>
+<p>To update the repository to tip of trunk:</p>
+<div class="highlight-python"><pre>git pull
+cd tools/clang
+git pull
+cd ../../projects/libcxx
+git pull</pre>
+</div>
+<p>To create a new branch:</p>
+<div class="highlight-python"><pre>git checkout -b MyBranch
+cd tools/clang
+git checkout -b MyBranch
+cd ../../projects/libcxx
+git checkout -b MyBranch</pre>
+</div>
+<p>To switch branches:</p>
+<div class="highlight-python"><pre>git checkout AnotherBranch
+cd tools/clang
+git checkout AnotherBranch
+cd ../../projects/libcxx
+git checkout AnotherBranch</pre>
+</div>
+</div>
+<div class="section" id="workflow-multi-branching">
+<span id="id21"></span><h4><a class="toc-backref" href="#id69">Multirepo Variant</a><a class="headerlink" href="#workflow-multi-branching" title="Permalink to this headline">¶</a></h4>
+<p>The multirepo works the same as the current Git workflow: every command needs
+to be applied to each of the individual repositories.
+However, the umbrella repository makes this easy using <cite>git submodule foreach</cite>
+to replicate a command on all the individual repositories (or submodules
+in this case):</p>
+<p>To create a new branch:</p>
+<div class="highlight-python"><pre>git submodule foreach git checkout -b MyBranch</pre>
+</div>
+<p>To switch branches:</p>
+<div class="highlight-python"><pre>git submodule foreach git checkout AnotherBranch</pre>
+</div>
+</div>
+<div class="section" id="workflow-mono-branching">
+<span id="id22"></span><h4><a class="toc-backref" href="#id70">Monorepo Variant</a><a class="headerlink" href="#workflow-mono-branching" title="Permalink to this headline">¶</a></h4>
+<p>Regular Git commands are sufficient, because everything is in a single
+repository:</p>
+<p>To update the repository to tip of trunk:</p>
+<div class="highlight-python"><pre>git pull</pre>
+</div>
+<p>To create a new branch:</p>
+<div class="highlight-python"><pre>git checkout -b MyBranch</pre>
+</div>
+<p>To switch branches:</p>
+<div class="highlight-python"><pre>git checkout AnotherBranch</pre>
+</div>
+</div>
+</div>
+<div class="section" id="bisecting">
+<h3><a class="toc-backref" href="#id71">Bisecting</a><a class="headerlink" href="#bisecting" title="Permalink to this headline">¶</a></h3>
+<p>Assuming a developer is looking for a bug in clang (or lld, or lldb, ...).</p>
+<div class="section" id="id23">
+<h4><a class="toc-backref" href="#id72">Currently</a><a class="headerlink" href="#id23" title="Permalink to this headline">¶</a></h4>
+<p>SVN does not have builtin bisection support, but the single revision across
+sub-projects makes it possible to script around.</p>
+<p>Using the existing Git read-only view of the repositories, it is possible to use
+the native Git bisection script over the llvm repository, and use some scripting
+to synchronize the clang repository to match the llvm revision.</p>
+</div>
+<div class="section" id="workflow-multi-bisecting">
+<span id="id24"></span><h4><a class="toc-backref" href="#id73">Multirepo Variant</a><a class="headerlink" href="#workflow-multi-bisecting" title="Permalink to this headline">¶</a></h4>
+<p>With the multi-repositories variant, the cross-repository synchronization is
+achieved using the umbrella repository. This repository contains only
+submodules for the other sub-projects. The native Git bisection can be used on
+the umbrella repository directly. A subtlety is that the bisect script itself
+needs to make sure the submodules are updated accordingly.</p>
+<p>For example, to find which commit introduces a regression where clang-3.9
+crashes but not clang-3.8 passes, one should be able to simply do:</p>
+<div class="highlight-python"><pre>git bisect start release_39 release_38
+git bisect run ./bisect_script.sh</pre>
+</div>
+<p>With the <cite>bisect_script.sh</cite> script being:</p>
+<div class="highlight-python"><pre>#!/bin/sh
+cd $UMBRELLA_DIRECTORY
+git submodule update llvm clang libcxx #....
+cd $BUILD_DIR
+
+ninja clang || exit 125 # an exit code of 125 asks "git bisect"
+ # to "skip" the current commit
+
+./bin/clang some_crash_test.cpp</pre>
+</div>
+<p>When the <cite>git bisect run</cite> command returns, the umbrella repository is set to
+the state where the regression is introduced. The commit diff in the umbrella
+indicate which submodule was updated, and the last commit in this sub-projects
+is the one that the bisect found.</p>
+</div>
+<div class="section" id="workflow-mono-bisecting">
+<span id="id25"></span><h4><a class="toc-backref" href="#id74">Monorepo Variant</a><a class="headerlink" href="#workflow-mono-bisecting" title="Permalink to this headline">¶</a></h4>
+<p>Bisecting on the monorepo is straightforward, and very similar to the above,
+except that the bisection script does not need to include the
+<cite>git submodule update</cite> step.</p>
+<p>The same example, finding which commit introduces a regression where clang-3.9
+crashes but not clang-3.8 passes, will look like:</p>
+<div class="highlight-python"><pre>git bisect start release_39 release_38
+git bisect run ./bisect_script.sh</pre>
+</div>
+<p>With the <cite>bisect_script.sh</cite> script being:</p>
+<div class="highlight-python"><pre>#!/bin/sh
+cd $BUILD_DIR
+
+ninja clang || exit 125 # an exit code of 125 asks "git bisect"
+ # to "skip" the current commit
+
+./bin/clang some_crash_test.cpp</pre>
+</div>
+<p>Also, since the monorepo handles commits update across multiple projects, you’re
+less like to encounter a build failure where a commit change an API in LLVM and
+another later one “fixes” the build in clang.</p>
+</div>
+</div>
+</div>
+<div class="section" id="references">
+<h2><a class="toc-backref" href="#id75">References</a><a class="headerlink" href="#references" title="Permalink to this headline">¶</a></h2>
+<table class="docutils citation" frame="void" id="lattnerrevnum" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2">[LattnerRevNum]</a></td><td>Chris Lattner, <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041739.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041739.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="trickrevnum" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3">[TrickRevNum]</a></td><td>Andrew Trick, <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041721.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041721.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="jsonnrevnum" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4">[JSonnRevNum]</a></td><td>Joerg Sonnenberg, <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041688.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041688.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="torvaldrevnum" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[TorvaldRevNum]</a></td><td>Linus Torvald, <a class="reference external" href="http://git.661346.n2.nabble.com/Git-commit-generation-numbers-td6584414.html">http://git.661346.n2.nabble.com/Git-commit-generation-numbers-td6584414.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="matthewsrevnum" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[MatthewsRevNum]</td><td><em>(<a class="fn-backref" href="#id5">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> Chris Matthews, <a class="reference external" href="http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html">http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="submodules" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8">[submodules]</a></td><td>Git submodules, <a class="reference external" href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="statuschecks" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6">[statuschecks]</a></td><td>GitHub status-checks, <a class="reference external" href="https://help.github.com/articles/about-required-status-checks/">https://help.github.com/articles/about-required-status-checks/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="lebarcheri" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10">[LebarCHERI]</a></td><td>Port <em>CHERI</em> to a single repository rewriting history, <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102787.html">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102787.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="aminicheri" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11">[AminiCHERI]</a></td><td>Port <em>CHERI</em> to a single repository preserving history, <a class="reference external" href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102804.html">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102804.html</a></td></tr>
+</tbody>
+</table>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="VectorizationPlan.html" title="Vectorization Plan"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="../CodeOfConduct.html" title="LLVM Community Code of Conduct"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/Proposals/VectorizationPlan.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/Proposals/VectorizationPlan.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/Proposals/VectorizationPlan.html (added)
+++ www-releases/trunk/6.0.1/docs/Proposals/VectorizationPlan.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,377 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Vectorization Plan — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="prev" title="Moving LLVM Projects to GitHub" href="GitHubMove.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="../index.html">
+ <img src="../_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="GitHubMove.html" title="Moving LLVM Projects to GitHub"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="vectorization-plan">
+<h1>Vectorization Plan<a class="headerlink" href="#vectorization-plan" title="Permalink to this headline">¶</a></h1>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id18">Abstract</a></li>
+<li><a class="reference internal" href="#high-level-design" id="id19">High-level Design</a><ul>
+<li><a class="reference internal" href="#vectorization-workflow" id="id20">Vectorization Workflow</a></li>
+<li><a class="reference internal" href="#design-guidelines" id="id21">Design Guidelines</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#definitions" id="id22">Definitions</a></li>
+<li><a class="reference internal" href="#the-planning-process-and-vplan-roadmap" id="id23">The Planning Process and VPlan Roadmap</a><ul>
+<li><a class="reference internal" href="#related-llvm-components" id="id24">Related LLVM components</a></li>
+<li><a class="reference internal" href="#references" id="id25">References</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h2><a class="toc-backref" href="#id18">Abstract</a><a class="headerlink" href="#abstract" title="Permalink to this headline">¶</a></h2>
+<p>The vectorization transformation can be rather complicated, involving several
+potential alternatives, especially for outer-loops <a class="footnote-reference" href="#id9" id="id1">[1]</a> but also possibly for
+innermost loops. These alternatives may have significant performance impact,
+both positive and negative. A cost model is therefore employed to identify the
+best alternative, including the alternative of avoiding any transformation
+altogether.</p>
+<p>The Vectorization Plan is an explicit model for describing vectorization
+candidates. It serves for both optimizing candidates including estimating their
+cost reliably, and for performing their final translation into IR. This
+facilitates dealing with multiple vectorization candidates.</p>
+</div>
+<div class="section" id="high-level-design">
+<h2><a class="toc-backref" href="#id19">High-level Design</a><a class="headerlink" href="#high-level-design" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="vectorization-workflow">
+<h3><a class="toc-backref" href="#id20">Vectorization Workflow</a><a class="headerlink" href="#vectorization-workflow" title="Permalink to this headline">¶</a></h3>
+<p>VPlan-based vectorization involves three major steps, taking a “scenario-based
+approach” to vectorization planning:</p>
+<ol class="arabic simple">
+<li>Legal Step: check if a loop can be legally vectorized; encode constraints and
+artifacts if so.</li>
+<li>Plan Step:<ol class="loweralpha">
+<li>Build initial VPlans following the constraints and decisions taken by
+Legal Step 1, and compute their cost.</li>
+<li>Apply optimizations to the VPlans, possibly forking additional VPlans.
+Prune sub-optimal VPlans having relatively high cost.</li>
+</ol>
+</li>
+<li>Execute Step: materialize the best VPlan. Note that this is the only step
+that modifies the IR.</li>
+</ol>
+</div>
+<div class="section" id="design-guidelines">
+<h3><a class="toc-backref" href="#id21">Design Guidelines</a><a class="headerlink" href="#design-guidelines" title="Permalink to this headline">¶</a></h3>
+<p>In what follows, the term “input IR” refers to code that is fed into the
+vectorizer whereas the term “output IR” refers to code that is generated by the
+vectorizer. The output IR contains code that has been vectorized or “widened”
+according to a loop Vectorization Factor (VF), and/or loop unroll-and-jammed
+according to an Unroll Factor (UF).
+The design of VPlan follows several high-level guidelines:</p>
+<ol class="arabic simple">
+<li>Analysis-like: building and manipulating VPlans must not modify the input IR.
+In particular, if the best option is not to vectorize at all, the
+vectorization process terminates before reaching Step 3, and compilation
+should proceed as if VPlans had not been built.</li>
+<li>Align Cost & Execute: each VPlan must support both estimating the cost and
+generating the output IR code, such that the cost estimation evaluates the
+to-be-generated code reliably.</li>
+<li>Support vectorizing additional constructs:<ol class="loweralpha">
+<li>Outer-loop vectorization. In particular, VPlan must be able to model the
+control-flow of the output IR which may include multiple basic-blocks and
+nested loops.</li>
+<li>SLP vectorization.</li>
+<li>Combinations of the above, including nested vectorization: vectorizing
+both an inner loop and an outer-loop at the same time (each with its own
+VF and UF), mixed vectorization: vectorizing a loop with SLP patterns
+inside <a class="footnote-reference" href="#id12" id="id2">[4]</a>, (re)vectorizing input IR containing vector code.</li>
+<li>Function vectorization <a class="footnote-reference" href="#id10" id="id3">[2]</a>.</li>
+</ol>
+</li>
+<li>Support multiple candidates efficiently. In particular, similar candidates
+related to a range of possible VF’s and UF’s must be represented efficiently.
+Potential versioning needs to be supported efficiently.</li>
+<li>Support vectorizing idioms, such as interleaved groups of strided loads or
+stores. This is achieved by modeling a sequence of output instructions using
+a “Recipe”, which is responsible for computing its cost and generating its
+code.</li>
+<li>Encapsulate Single-Entry Single-Exit regions (SESE). During vectorization
+such regions may need to be, for example, predicated and linearized, or
+replicated VF*UF times to handle scalarized and predicated instructions.
+Innerloops are also modelled as SESE regions.</li>
+<li>Support instruction-level analysis and transformation, as part of Planning
+Step 2.b: During vectorization instructions may need to be traversed, moved,
+replaced by other instructions or be created. For example, vector idiom
+detection and formation involves searching for and optimizing instruction
+patterns.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="definitions">
+<h2><a class="toc-backref" href="#id22">Definitions</a><a class="headerlink" href="#definitions" title="Permalink to this headline">¶</a></h2>
+<p>The low-level design of VPlan comprises of the following classes.</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" colspan="2">LoopVectorizationPlanner:</th></tr>
+<tr class="field-odd field"><td> </td><td class="field-body">A LoopVectorizationPlanner is designed to handle the vectorization of a loop
+or a loop nest. It can construct, optimize and discard one or more VPlans,
+each VPlan modelling a distinct way to vectorize the loop or the loop nest.
+Once the best VPlan is determined, including the best VF and UF, this VPlan
+drives the generation of output IR.</td>
+</tr>
+<tr class="field-even field"><th class="field-name">VPlan:</th><td class="field-body">A model of a vectorized candidate for a given input IR loop or loop nest. This
+candidate is represented using a Hierarchical CFG. VPlan supports estimating
+the cost and driving the generation of the output IR code it represents.</td>
+</tr>
+<tr class="field-odd field"><th class="field-name" colspan="2">Hierarchical CFG:</th></tr>
+<tr class="field-odd field"><td> </td><td class="field-body">A control-flow graph whose nodes are basic-blocks or Hierarchical CFG’s. The
+Hierarchical CFG data structure is similar to the Tile Tree <a class="footnote-reference" href="#id13" id="id4">[5]</a>, where
+cross-Tile edges are lifted to connect Tiles instead of the original
+basic-blocks as in Sharir <a class="footnote-reference" href="#id14" id="id5">[6]</a>, promoting the Tile encapsulation. The terms
+Region and Block are used rather than Tile <a class="footnote-reference" href="#id13" id="id6">[5]</a> to avoid confusion with loop
+tiling.</td>
+</tr>
+<tr class="field-even field"><th class="field-name">VPBlockBase:</th><td class="field-body">The building block of the Hierarchical CFG. A pure-virtual base-class of
+VPBasicBlock and VPRegionBlock, see below. VPBlockBase models the hierarchical
+control-flow relations with other VPBlocks. Note that in contrast to the IR
+BasicBlock, a VPBlockBase models its control-flow successors and predecessors
+directly, rather than through a Terminator branch or through predecessor
+branches that “use” the VPBlockBase.</td>
+</tr>
+<tr class="field-odd field"><th class="field-name">VPBasicBlock:</th><td class="field-body">VPBasicBlock is a subclass of VPBlockBase, and serves as the leaves of the
+Hierarchical CFG. It represents a sequence of output IR instructions that will
+appear consecutively in an output IR basic-block. The instructions of this
+basic-block originate from one or more VPBasicBlocks. VPBasicBlock holds a
+sequence of zero or more VPRecipes that model the cost and generation of the
+output IR instructions.</td>
+</tr>
+<tr class="field-even field"><th class="field-name">VPRegionBlock:</th><td class="field-body">VPRegionBlock is a subclass of VPBlockBase. It models a collection of
+VPBasicBlocks and VPRegionBlocks which form a SESE subgraph of the output IR
+CFG. A VPRegionBlock may indicate that its contents are to be replicated a
+constant number of times when output IR is generated, effectively representing
+a loop with constant trip-count that will be completely unrolled. This is used
+to support scalarized and predicated instructions with a single model for
+multiple candidate VF’s and UF’s.</td>
+</tr>
+<tr class="field-odd field"><th class="field-name">VPRecipeBase:</th><td class="field-body">A pure-virtual base class modeling a sequence of one or more output IR
+instructions, possibly based on one or more input IR instructions. These
+input IR instructions are referred to as “Ingredients” of the Recipe. A Recipe
+may specify how its ingredients are to be transformed to produce the output IR
+instructions; e.g., cloned once, replicated multiple times or widened
+according to selected VF.</td>
+</tr>
+<tr class="field-even field"><th class="field-name">VPValue:</th><td class="field-body">The base of VPlan’s def-use relations class hierarchy. When instantiated, it
+models a constant or a live-in Value in VPlan. It has users, which are of type
+VPUser, but no operands.</td>
+</tr>
+<tr class="field-odd field"><th class="field-name">VPUser:</th><td class="field-body">A VPValue representing a general vertex in the def-use graph of VPlan. It has
+operands which are of type VPValue. When instantiated, it represents a
+live-out Instruction that exists outside VPlan. VPUser is similar in some
+aspects to LLVM’s User class.</td>
+</tr>
+<tr class="field-even field"><th class="field-name">VPInstruction:</th><td class="field-body">A VPInstruction is both a VPRecipe and a VPUser. It models a single
+VPlan-level instruction to be generated if the VPlan is executed, including
+its opcode and possibly additional characteristics. It is the basis for
+writing instruction-level analyses and optimizations in VPlan as creating,
+replacing or moving VPInstructions record both def-use and scheduling
+decisions. VPInstructions also extend LLVM IR’s opcodes with idiomatic
+operations that enrich the Vectorizer’s semantics.</td>
+</tr>
+<tr class="field-odd field"><th class="field-name" colspan="2">VPTransformState:</th></tr>
+<tr class="field-odd field"><td> </td><td class="field-body">Stores information used for generating output IR, passed from
+LoopVectorizationPlanner to its selected VPlan for execution, and used to pass
+additional information down to VPBlocks and VPRecipes.</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="the-planning-process-and-vplan-roadmap">
+<h2><a class="toc-backref" href="#id23">The Planning Process and VPlan Roadmap</a><a class="headerlink" href="#the-planning-process-and-vplan-roadmap" title="Permalink to this headline">¶</a></h2>
+<p>Transforming the Loop Vectorizer to use VPlan follows a staged approach. First,
+VPlan is used to record the final vectorization decisions, and to execute them:
+the Hierarchical CFG models the planned control-flow, and Recipes capture
+decisions taken inside basic-blocks. Next, VPlan will be used also as the basis
+for taking these decisions, effectively turning them into a series of
+VPlan-to-VPlan algorithms. Finally, VPlan will support the planning process
+itself including cost-based analyses for making these decisions, to fully
+support compositional and iterative decision making.</p>
+<p>Some decisions are local to an instruction in the loop, such as whether to widen
+it into a vector instruction or replicate it, keeping the generated instructions
+in place. Other decisions, however, involve moving instructions, replacing them
+with other instructions, and/or introducing new instructions. For example, a
+cast may sink past a later instruction and be widened to handle first-order
+recurrence; an interleave group of strided gathers or scatters may effectively
+move to one place where they are replaced with shuffles and a common wide vector
+load or store; new instructions may be introduced to compute masks, shuffle the
+elements of vectors, and pack scalar values into vectors or vice-versa.</p>
+<p>In order for VPlan to support making instruction-level decisions and analyses,
+it needs to model the relevant instructions along with their def/use relations.
+This too follows a staged approach: first, the new instructions that compute
+masks are modeled as VPInstructions, along with their induced def/use subgraph.
+This effectively models masks in VPlan, facilitating VPlan-based predication.
+Next, the logic embedded within each Recipe for generating its instructions at
+VPlan execution time, will instead take part in the planning process by modeling
+them as VPInstructions. Finally, only logic that applies to instructions as a
+group will remain in Recipes, such as interleave groups and potentially other
+idiom groups having synergistic cost.</p>
+<div class="section" id="related-llvm-components">
+<h3><a class="toc-backref" href="#id24">Related LLVM components</a><a class="headerlink" href="#related-llvm-components" title="Permalink to this headline">¶</a></h3>
+<ol class="arabic simple">
+<li>SLP Vectorizer: one can compare the VPlan model with LLVM’s existing SLP
+tree, where TSLP <a class="footnote-reference" href="#id11" id="id7">[3]</a> adds Plan Step 2.b.</li>
+<li>RegionInfo: one can compare VPlan’s H-CFG with the Region Analysis as used by
+Polly <a class="footnote-reference" href="#id15" id="id8">[7]</a>.</li>
+<li>Loop Vectorizer: the Vectorization Plan aims to upgrade the infrastructure of
+the Loop Vectorizer and extend it to handle outer loops [8,9]_.</li>
+</ol>
+</div>
+<div class="section" id="references">
+<h3><a class="toc-backref" href="#id25">References</a><a class="headerlink" href="#references" title="Permalink to this headline">¶</a></h3>
+<table class="docutils footnote" frame="void" id="id9" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>“Outer-loop vectorization: revisited for short SIMD architectures”, Dorit
+Nuzman and Ayal Zaks, PACT 2008.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id10" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3">[2]</a></td><td>“Proposal for function vectorization and loop vectorization with function
+calls”, Xinmin Tian, [<a class="reference external" href="http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html">cfe-dev</a>].,
+March 2, 2016.
+See also <a class="reference external" href="https://reviews.llvm.org/D22792">review</a>.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id11" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7">[3]</a></td><td>“Throttling Automatic Vectorization: When Less is More”, Vasileios
+Porpodas and Tim Jones, PACT 2015 and LLVM Developers’ Meeting 2015.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2">[4]</a></td><td>“Exploiting mixed SIMD parallelism by reducing data reorganization
+overhead”, Hao Zhou and Jingling Xue, CGO 2016.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id13" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id4">1</a>, <a class="fn-backref" href="#id6">2</a>)</em> “Register Allocation via Hierarchical Graph Coloring”, David Callahan and
+Brian Koblenz, PLDI 1991</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id14" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5">[6]</a></td><td>“Structural analysis: A new approach to flow analysis in optimizing
+compilers”, M. Sharir, Journal of Computer Languages, Jan. 1980</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id15" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8">[7]</a></td><td>“Enabling Polyhedral Optimizations in LLVM”, Tobias Grosser, Diploma
+thesis, 2011.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id16" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[8]</td><td>“Introducing VPlan to the Loop Vectorizer”, Gil Rapaport and Ayal Zaks,
+European LLVM Developers’ Meeting 2017.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id17" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[9]</td><td>“Extending LoopVectorizer: OpenMP4.5 SIMD and Outer Loop
+Auto-Vectorization”, Intel Vectorizer Team, LLVM Developers’ Meeting 2016.</td></tr>
+</tbody>
+</table>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="GitHubMove.html" title="Moving LLVM Projects to GitHub"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="../index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/ReleaseNotes.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/ReleaseNotes.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/ReleaseNotes.html (added)
+++ www-releases/trunk/6.0.1/docs/ReleaseNotes.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,324 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM 6.0.0 Release Notes — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="LLVMâs Analysis and Transform Passes" href="Passes.html" />
+ <link rel="prev" title="5. Building a JIT: Remote-JITing â Process Isolation and Laziness at a Distance" href="tutorial/BuildingAJIT5.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Passes.html" title="LLVMâs Analysis and Transform Passes"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="tutorial/BuildingAJIT5.html" title="5. Building a JIT: Remote-JITing â Process Isolation and Laziness at a Distance"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-6-0-0-release-notes">
+<h1>LLVM 6.0.0 Release Notes<a class="headerlink" href="#llvm-6-0-0-release-notes" 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="id2">Introduction</a></li>
+<li><a class="reference internal" href="#non-comprehensive-list-of-changes-in-this-release" id="id3">Non-comprehensive list of changes in this release</a><ul>
+<li><a class="reference internal" href="#changes-to-the-llvm-ir" id="id4">Changes to the LLVM IR</a></li>
+<li><a class="reference internal" href="#changes-to-the-aarch64-target" id="id5">Changes to the AArch64 Target</a></li>
+<li><a class="reference internal" href="#changes-to-the-arm-target" id="id6">Changes to the ARM Target</a></li>
+<li><a class="reference internal" href="#changes-to-the-hexagon-target" id="id7">Changes to the Hexagon Target</a></li>
+<li><a class="reference internal" href="#changes-to-the-mips-target" id="id8">Changes to the MIPS Target</a></li>
+<li><a class="reference internal" href="#changes-to-the-systemz-target" id="id9">Changes to the SystemZ Target</a></li>
+<li><a class="reference internal" href="#changes-to-the-x86-target" id="id10">Changes to the X86 Target</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#external-open-source-projects-using-llvm-6" id="id11">External Open Source Projects Using LLVM 6</a><ul>
+<li><a class="reference internal" href="#ldc-the-llvm-based-d-compiler" id="id12">LDC - the LLVM-based D compiler</a></li>
+<li><a class="reference internal" href="#jfs-jit-fuzzing-solver" id="id13">JFS - JIT Fuzzing Solver</a></li>
+<li><a class="reference internal" href="#zig-programming-language" id="id14">Zig Programming Language</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#additional-information" id="id15">Additional Information</a></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>This document contains the release notes for the LLVM Compiler Infrastructure,
+release 6.0.0. Here we describe the status of LLVM, including major improvements
+from the previous release, improvements in various subprojects of LLVM, and
+some of the current users of the code. All LLVM releases may be downloaded
+from the <a class="reference external" href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
+<p>For more information about LLVM, including information about the latest
+release, please check out the <a class="reference external" href="http://llvm.org/">main LLVM web site</a>. If you
+have questions or comments, the <a class="reference external" href="http://lists.llvm.org/mailman/listinfo/llvm-dev">LLVM Developer’s Mailing List</a> is a good place to send
+them.</p>
+</div>
+<div class="section" id="non-comprehensive-list-of-changes-in-this-release">
+<h2><a class="toc-backref" href="#id3">Non-comprehensive list of changes in this release</a><a class="headerlink" href="#non-comprehensive-list-of-changes-in-this-release" title="Permalink to this headline">¶</a></h2>
+<ul class="simple">
+<li>Support for <a class="reference external" href="https://support.google.com/faqs/answer/7625886">retpolines</a>
+was added to help mitigate “branch target injection” (variant #2) of the
+“Spectre” speculative side channels described by <a class="reference external" href="https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html">Project Zero</a>
+and the <a class="reference external" href="https://spectreattack.com/spectre.pdf">Spectre paper</a>.</li>
+<li>The <tt class="docutils literal"><span class="pre">Redirects</span></tt> argument of <tt class="docutils literal"><span class="pre">llvm::sys::ExecuteAndWait</span></tt> and
+<tt class="docutils literal"><span class="pre">llvm::sys::ExecuteNoWait</span></tt> was changed to an <tt class="docutils literal"><span class="pre">ArrayRef</span></tt> of optional
+<tt class="docutils literal"><span class="pre">StringRef</span></tt>‘s to make it safer and more convenient to use.</li>
+<li>The backend name was added to the Target Registry to allow run-time
+information to be fed back into TableGen. Out-of-tree targets will need to add
+the name used in the <cite>def X : Target</cite> definition to the call to
+<cite>RegisterTarget</cite>.</li>
+<li>The <tt class="docutils literal"><span class="pre">Debugify</span></tt> pass was added to <tt class="docutils literal"><span class="pre">opt</span></tt> to facilitate testing of debug
+info preservation. This pass attaches synthetic <tt class="docutils literal"><span class="pre">DILocations</span></tt> and
+<tt class="docutils literal"><span class="pre">DIVariables</span></tt> to the instructions in a <tt class="docutils literal"><span class="pre">Module</span></tt>. The <tt class="docutils literal"><span class="pre">CheckDebugify</span></tt>
+pass determines how much of the metadata is lost.</li>
+<li>Significantly improved quality of CodeView debug info for Windows.</li>
+<li>Preliminary support for Sanitizers and sibling features on X86(_64) NetBSD
+(ASan, UBsan, TSan, MSan, SafeStack, libFuzzer).</li>
+</ul>
+<div class="section" id="changes-to-the-llvm-ir">
+<h3><a class="toc-backref" href="#id4">Changes to the LLVM IR</a><a class="headerlink" href="#changes-to-the-llvm-ir" title="Permalink to this headline">¶</a></h3>
+<ul class="simple">
+<li>The fast-math-flags (FMF) have been updated. Previously, the ‘fast’ flag
+indicated that floating-point reassociation was allowed and all other flags
+were set too. The ‘fast’ flag still exists, but there is a new flag called
+‘reassoc’ to indicate specifically that reassociation is allowed. A new bit
+called ‘afn’ was also added to selectively allow approximations for common
+mathlib functions like square-root. The new flags provide more flexibility
+to enable/disable specific floating-point optimizations. Making the
+optimizer respond appropriately to these flags is an ongoing effort.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-aarch64-target">
+<h3><a class="toc-backref" href="#id5">Changes to the AArch64 Target</a><a class="headerlink" href="#changes-to-the-aarch64-target" title="Permalink to this headline">¶</a></h3>
+<ul class="simple">
+<li>Enabled the new GlobalISel instruction selection framework by default at <tt class="docutils literal"><span class="pre">-O0</span></tt>.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-arm-target">
+<h3><a class="toc-backref" href="#id6">Changes to the ARM Target</a><a class="headerlink" href="#changes-to-the-arm-target" title="Permalink to this headline">¶</a></h3>
+<ul class="simple">
+<li>Support for enabling SjLj exception handling on platforms where it
+isn’t the default.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-hexagon-target">
+<h3><a class="toc-backref" href="#id7">Changes to the Hexagon Target</a><a class="headerlink" href="#changes-to-the-hexagon-target" title="Permalink to this headline">¶</a></h3>
+<ul class="simple">
+<li>The Hexagon backend now supports V65 ISA.</li>
+<li>The <tt class="docutils literal"><span class="pre">-mhvx</span></tt> option now takes an optional value that specifies the ISA
+version of the HVX coprocessor. The available values are v60, v62 and v65.
+By default, the value is set to be the same as the CPU version.</li>
+<li>The compiler option <tt class="docutils literal"><span class="pre">-mhvx-double</span></tt> is deprecated and will be removed in
+the next release of the compiler. Programmers should use the <tt class="docutils literal"><span class="pre">-mhvx-length</span></tt>
+option to specify the desired vector length: <tt class="docutils literal"><span class="pre">-mhvx-length=64b</span></tt> for
+64-byte vectors and <tt class="docutils literal"><span class="pre">-mhvx-length=128b</span></tt> for 128-byte vectors. While the
+current default vector length is 64 bytes, users should always specify the
+length explicitly, since the default value may change in the future.</li>
+<li>The target feature <tt class="docutils literal"><span class="pre">hvx-double</span></tt> is deprecated and will be removed in the
+next release. LLVM IR generators should use target features <tt class="docutils literal"><span class="pre">hvx-length64b</span></tt>
+and <tt class="docutils literal"><span class="pre">hvx-length128b</span></tt> to indicate the vector length. The length should
+always be specified when HVX code generation is enabled.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-mips-target">
+<h3><a class="toc-backref" href="#id8">Changes to the MIPS Target</a><a class="headerlink" href="#changes-to-the-mips-target" title="Permalink to this headline">¶</a></h3>
+<p>Fixed numerous bugs:</p>
+<ul class="simple">
+<li>fpowi on MIPS64 giving incorrect results when used with a negative integer.</li>
+<li>Usage of the asm ‘c’ constraint with the wrong datatype causing an
+assert/crash.</li>
+<li>Fixed a conversion bug when using the DSP ASE.</li>
+<li>Fixed an inconsistency where objects were not marked as using the microMIPS as
+when the micromips function attribute or the ”.set micromips” directive was
+used.</li>
+<li>Reordered the MIPSR6 specific hazard scheduler pass to after the delay slot
+filler, fixing a class of rare edge case bugs where the delay slot filler
+would violate ISA restrictions.</li>
+<li>Fixed a crash when using a type of unknown size with gp relative addressing.</li>
+<li>Corrected the j macro for microMIPS.</li>
+<li>Corrected the encoding of movep for microMIPS32r6.</li>
+<li>Fixed an issue with the usage of insert instructions having an invalid set of
+operands.</li>
+<li>Fixed an issue where TLS symbols were not marked as such.</li>
+<li>Enabled the usage of register scavenging with MSA, due to its shorter offsets
+for loads and stores.</li>
+<li>Corrected the ELF headers when using the DSP ASE.</li>
+</ul>
+<p>New features:</p>
+<ul class="simple">
+<li>The long branch pass now generates some R6 specific instructions when
+targeting MIPSR6.</li>
+<li>The delay slot filler now performs more branch conversions if delay slots
+cannot be filled.</li>
+<li>The MIPS MT ASE is now fully supported.</li>
+<li>Added support for the <tt class="docutils literal"><span class="pre">lapc</span></tt> pseudo instruction.</li>
+<li>Improved the selection of multiple instructions (<tt class="docutils literal"><span class="pre">dext</span></tt>, <tt class="docutils literal"><span class="pre">nmadd</span></tt>,
+<tt class="docutils literal"><span class="pre">nmsub</span></tt>).</li>
+<li>Further improved microMIPS codesize reduction.</li>
+</ul>
+<p>Deprecation notices:</p>
+<ul class="simple">
+<li>microMIPS64R6 support was been deprecated since 5.0, and has now been
+completely removed.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-systemz-target">
+<h3><a class="toc-backref" href="#id9">Changes to the SystemZ Target</a><a class="headerlink" href="#changes-to-the-systemz-target" title="Permalink to this headline">¶</a></h3>
+<p>During this release the SystemZ target has:</p>
+<ul class="simple">
+<li>Added support for 128-bit atomic operations.</li>
+<li>Added support for the “o” constraint for inline asm statements.</li>
+</ul>
+</div>
+<div class="section" id="changes-to-the-x86-target">
+<h3><a class="toc-backref" href="#id10">Changes to the X86 Target</a><a class="headerlink" href="#changes-to-the-x86-target" title="Permalink to this headline">¶</a></h3>
+<p>During this release the X86 target has:</p>
+<ul class="simple">
+<li>Added support for enabling SjLj exception handling on platforms where it
+isn’t the default.</li>
+<li>Added intrinsics for Intel Extensions: VAES, GFNI, VPCLMULQDQ, AVX512VBMI2, AVX512BITALG, AVX512VNNI.</li>
+<li>Added support for Intel Icelake CPU.</li>
+<li>Fixed some X87 codegen bugs.</li>
+<li>Added instruction scheduling information for Intel Sandy Bridge, Ivy Bridge, Haswell, Broadwell, and Skylake CPUs.</li>
+<li>Improved scheduler model for AMD Jaguar CPUs.</li>
+<li>Improved llvm-mc’s disassembler for some EVEX encoded instructions.</li>
+<li>Add support for i8 and i16 vector signed/unsigned min/max horizontal reductions.</li>
+<li>Improved codegen for memory comparisons</li>
+<li>Improved codegen for i32 vector multiplies</li>
+<li>Improved codegen for scalar integer absolute values</li>
+<li>Improved codegen for vector integer rotations (XOP and AVX512)</li>
+<li>Improved codegen of data being transferred between GPRs and K-registers.</li>
+<li>Improved codegen for vector truncations.</li>
+<li>Improved folding of address computations into gather/scatter instructions.</li>
+<li>Gained initial support recognizing variable shuffles from vector element extracts and inserts.</li>
+<li>Improved documentation for SSE/AVX intrinsics in intrin.h header files.</li>
+<li>Gained support for emitting <a class="reference external" href="https://support.google.com/faqs/answer/7625886">retpolines</a>, including automatic
+insertion of the necessary thunks or using external thunks.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="external-open-source-projects-using-llvm-6">
+<h2><a class="toc-backref" href="#id11">External Open Source Projects Using LLVM 6</a><a class="headerlink" href="#external-open-source-projects-using-llvm-6" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="ldc-the-llvm-based-d-compiler">
+<h3><a class="toc-backref" href="#id12">LDC - the LLVM-based D compiler</a><a class="headerlink" href="#ldc-the-llvm-based-d-compiler" title="Permalink to this headline">¶</a></h3>
+<p><a class="reference external" href="http://dlang.org">D</a> is a language with C-like syntax and static typing. It
+pragmatically combines efficiency, control, and modeling power, with safety and
+programmer productivity. D supports powerful concepts like Compile-Time Function
+Execution (CTFE) and Template Meta-Programming, provides an innovative approach
+to concurrency and offers many classical paradigms.</p>
+<p><a class="reference external" href="http://wiki.dlang.org/LDC">LDC</a> uses the frontend from the reference compiler
+combined with LLVM as backend to produce efficient native code. LDC targets
+x86/x86_64 systems like Linux, OS X, FreeBSD and Windows and also Linux on ARM
+and PowerPC (32/64 bit). Ports to other architectures like AArch64 and MIPS64
+are underway.</p>
+</div>
+<div class="section" id="jfs-jit-fuzzing-solver">
+<h3><a class="toc-backref" href="#id13">JFS - JIT Fuzzing Solver</a><a class="headerlink" href="#jfs-jit-fuzzing-solver" title="Permalink to this headline">¶</a></h3>
+<p><a class="reference external" href="https://github.com/delcypher/jfs">JFS</a> is an experimental constraint solver
+designed to investigate using coverage guided fuzzing as an incomplete strategy
+for solving boolean, BitVector, and floating-point constraints.
+It is built on top of LLVM, Clang, LibFuzzer, and Z3.</p>
+<p>The solver works by generating a C++ program where the reachability of an
+<cite>abort()</cite> statement is equivalent to finding a satisfying assignment to the
+constraints. This program is then compiled by Clang with <a class="reference external" href="https://releases.llvm.org/6.0.0/tools/clang/docs/SanitizerCoverage.html">SanitizerCoverage</a>
+instrumentation and then fuzzed using <a class="reference internal" href="LibFuzzer.html"><em>LibFuzzer</em></a>.</p>
+</div>
+<div class="section" id="zig-programming-language">
+<h3><a class="toc-backref" href="#id14">Zig Programming Language</a><a class="headerlink" href="#zig-programming-language" title="Permalink to this headline">¶</a></h3>
+<p><a class="reference external" href="http://ziglang.org">Zig</a> is an open-source programming language designed
+for robustness, optimality, and clarity. It is intended to replace C. It
+provides high level features such as Generics,
+Compile Time Function Execution, and Partial Evaluation, yet exposes low level
+LLVM IR features such as Aliases. Zig uses Clang to provide automatic
+import of .h symbols - even inline functions and macros. Zig uses LLD combined
+with lazily building compiler-rt to provide out-of-the-box cross-compiling for
+all supported targets.</p>
+</div>
+</div>
+<div class="section" id="additional-information">
+<h2><a class="toc-backref" href="#id15">Additional Information</a><a class="headerlink" href="#additional-information" title="Permalink to this headline">¶</a></h2>
+<p>A wide variety of additional information is available on the <a class="reference external" href="http://llvm.org/">LLVM web page</a>, in particular in the <a class="reference external" href="http://llvm.org/docs/">documentation</a> section. The web page also contains versions of the
+API documentation which is up-to-date with the Subversion version of the source
+code. You can access versions of these documents specific to this release by
+going into the <tt class="docutils literal"><span class="pre">llvm/docs/</span></tt> directory in the LLVM tree.</p>
+<p>If you have any questions or comments about LLVM, please feel free to contact
+us via the <a class="reference external" href="http://llvm.org/docs/#maillist">mailing lists</a>.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Passes.html" title="LLVMâs Analysis and Transform Passes"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="tutorial/BuildingAJIT5.html" title="5. Building a JIT: Remote-JITing â Process Isolation and Laziness at a Distance"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/ReleaseProcess.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/ReleaseProcess.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/ReleaseProcess.html (added)
+++ www-releases/trunk/6.0.1/docs/ReleaseProcess.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,254 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>How To Validate a New Release — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Code Reviews with Phabricator" href="Phabricator.html" />
+ <link rel="prev" title="Advice on Packaging LLVM" href="Packaging.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="Packaging.html" title="Advice on Packaging LLVM"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="how-to-validate-a-new-release">
+<h1>How To Validate a New Release<a class="headerlink" href="#how-to-validate-a-new-release" 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="id9">Introduction</a></li>
+<li><a class="reference internal" href="#scripts" id="id10">Scripts</a></li>
+<li><a class="reference internal" href="#test-suite" id="id11">Test Suite</a></li>
+<li><a class="reference internal" href="#pre-release-process" id="id12">Pre-Release Process</a></li>
+<li><a class="reference internal" href="#release-process" id="id13">Release Process</a></li>
+<li><a class="reference internal" href="#bug-reporting-process" id="id14">Bug Reporting Process</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id9">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document contains information about testing the release candidates that will
+ultimately be the next LLVM release. For more information on how to manage the
+actual release, please refer to <a class="reference internal" href="HowToReleaseLLVM.html"><em>How To Release LLVM To The Public</em></a>.</p>
+<div class="section" id="overview-of-the-release-process">
+<h3>Overview of the Release Process<a class="headerlink" href="#overview-of-the-release-process" title="Permalink to this headline">¶</a></h3>
+<p>Once the release process starts, the Release Manager will ask for volunteers,
+and it’ll be the role of each volunteer to:</p>
+<ul class="simple">
+<li>Test and benchmark the previous release</li>
+<li>Test and benchmark each release candidate, comparing to the previous release and candidates</li>
+<li>Identify, reduce and report every regression found during tests and benchmarks</li>
+<li>Make sure the critical bugs get fixed and merged to the next release candidate</li>
+</ul>
+<p>Not all bugs or regressions are show-stoppers and it’s a bit of a grey area what
+should be fixed before the next candidate and what can wait until the next release.</p>
+<p>It’ll depend on:</p>
+<ul class="simple">
+<li>The severity of the bug, how many people it affects and if it’s a regression or a
+known bug. Known bugs are “unsupported features” and some bugs can be disabled if
+they have been implemented recently.</li>
+<li>The stage in the release. Less critical bugs should be considered to be fixed between
+RC1 and RC2, but not so much at the end of it.</li>
+<li>If it’s a correctness or a performance regression. Performance regression tends to be
+taken more lightly than correctness.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="scripts">
+<span id="id1"></span><h2><a class="toc-backref" href="#id10">Scripts</a><a class="headerlink" href="#scripts" title="Permalink to this headline">¶</a></h2>
+<p>The scripts are in the <tt class="docutils literal"><span class="pre">utils/release</span></tt> directory.</p>
+<div class="section" id="test-release-sh">
+<h3>test-release.sh<a class="headerlink" href="#test-release-sh" title="Permalink to this headline">¶</a></h3>
+<p>This script will check-out, configure and compile LLVM+Clang (+ most add-ons, like <tt class="docutils literal"><span class="pre">compiler-rt</span></tt>,
+<tt class="docutils literal"><span class="pre">libcxx</span></tt>, <tt class="docutils literal"><span class="pre">libomp</span></tt> and <tt class="docutils literal"><span class="pre">clang-extra-tools</span></tt>) in three stages, and will test the final stage.
+It’ll have installed the final binaries on the Phase3/Releasei(+Asserts) directory, and
+that’s the one you should use for the test-suite and other external tests.</p>
+<p>To run the script on a specific release candidate run:</p>
+<div class="highlight-python"><pre>./test-release.sh \
+ -release 3.3 \
+ -rc 1 \
+ -no-64bit \
+ -test-asserts \
+ -no-compare-files</pre>
+</div>
+<p>Each system will require different options. For instance, x86_64 will obviously not need
+<tt class="docutils literal"><span class="pre">-no-64bit</span></tt> while 32-bit systems will, or the script will fail.</p>
+<p>The important flags to get right are:</p>
+<ul class="simple">
+<li>On the pre-release, you should change <tt class="docutils literal"><span class="pre">-rc</span> <span class="pre">1</span></tt> to <tt class="docutils literal"><span class="pre">-final</span></tt>. On RC2, change it to <tt class="docutils literal"><span class="pre">-rc</span> <span class="pre">2</span></tt> and so on.</li>
+<li>On non-release testing, you can use <tt class="docutils literal"><span class="pre">-final</span></tt> in conjunction with <tt class="docutils literal"><span class="pre">-no-checkout</span></tt>, but you’ll have to
+create the <tt class="docutils literal"><span class="pre">final</span></tt> directory by hand and link the correct source dir to <tt class="docutils literal"><span class="pre">final/llvm.src</span></tt>.</li>
+<li>For release candidates, you need <tt class="docutils literal"><span class="pre">-test-asserts</span></tt>, or it won’t create a “Release+Asserts” directory,
+which is needed for release testing and benchmarking. This will take twice as long.</li>
+<li>On the final candidate you just need Release builds, and that’s the binary directory you’ll have to pack.</li>
+</ul>
+<p>This script builds three phases of Clang+LLVM twice each (Release and Release+Asserts), so use
+screen or nohup to avoid headaches, since it’ll take a long time.</p>
+<p>Use the <tt class="docutils literal"><span class="pre">--help</span></tt> option to see all the options and chose it according to your needs.</p>
+</div>
+<div class="section" id="findregressions-nightly-py">
+<h3>findRegressions-nightly.py<a class="headerlink" href="#findregressions-nightly-py" title="Permalink to this headline">¶</a></h3>
+<p>TODO</p>
+</div>
+</div>
+<div class="section" id="test-suite">
+<span id="id2"></span><h2><a class="toc-backref" href="#id11">Test Suite</a><a class="headerlink" href="#test-suite" title="Permalink to this headline">¶</a></h2>
+<p>Follow the <a class="reference external" href="http://llvm.org/docs/lnt/quickstart.html">LNT Quick Start Guide</a> link on how to set-up the test-suite</p>
+<p>The binary location you’ll have to use for testing is inside the <tt class="docutils literal"><span class="pre">rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install</span></tt>.
+Link that directory to an easier location and run the test-suite.</p>
+<p>An example on the run command line, assuming you created a link from the correct
+install directory to <tt class="docutils literal"><span class="pre">~/devel/llvm/install</span></tt>:</p>
+<div class="highlight-python"><pre>./sandbox/bin/python sandbox/bin/lnt runtest \
+ nt \
+ -j4 \
+ --sandbox sandbox \
+ --test-suite ~/devel/llvm/test/test-suite \
+ --cc ~/devel/llvm/install/bin/clang \
+ --cxx ~/devel/llvm/install/bin/clang++</pre>
+</div>
+<p>It should have no new regressions, compared to the previous release or release candidate. You don’t need to fix
+all the bugs in the test-suite, since they’re not necessarily meant to pass on all architectures all the time. This is
+due to the nature of the result checking, which relies on direct comparison, and most of the time, the failures are
+related to bad output checking, rather than bad code generation.</p>
+<p>If the errors are in LLVM itself, please report every single regression found as blocker, and all the other bugs
+as important, but not necessarily blocking the release to proceed. They can be set as “known failures” and to be
+fix on a future date.</p>
+</div>
+<div class="section" id="pre-release-process">
+<span id="id4"></span><h2><a class="toc-backref" href="#id12">Pre-Release Process</a><a class="headerlink" href="#pre-release-process" title="Permalink to this headline">¶</a></h2>
+<p>When the release process is announced on the mailing list, you should prepare
+for the testing, by applying the same testing you’ll do on the release candidates,
+on the previous release.</p>
+<p>You should:</p>
+<ul class="simple">
+<li>Download the previous release sources from <a class="reference external" href="http://llvm.org/releases/download.html">http://llvm.org/releases/download.html</a>.</li>
+<li>Run the test-release.sh script on <tt class="docutils literal"><span class="pre">final</span></tt> mode (change <tt class="docutils literal"><span class="pre">-rc</span> <span class="pre">1</span></tt> to <tt class="docutils literal"><span class="pre">-final</span></tt>).</li>
+<li>Once all three stages are done, it’ll test the final stage.</li>
+<li>Using the <tt class="docutils literal"><span class="pre">Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.install</span></tt> base, run the test-suite.</li>
+</ul>
+<p>If the final phase’s <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check-all</span></tt> failed, it’s a good idea to also test the
+intermediate stages by going on the obj directory and running <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check-all</span></tt> to find
+if there’s at least one stage that passes (helps when reducing the error for bug report
+purposes).</p>
+</div>
+<div class="section" id="release-process">
+<span id="id6"></span><h2><a class="toc-backref" href="#id13">Release Process</a><a class="headerlink" href="#release-process" title="Permalink to this headline">¶</a></h2>
+<p>When the Release Manager sends you the release candidate, download all sources,
+unzip on the same directory (there will be sym-links from the appropriate places
+to them), and run the release test as above.</p>
+<p>You should:</p>
+<ul class="simple">
+<li>Download the current candidate sources from where the release manager points you
+(ex. <a class="reference external" href="http://llvm.org/pre-releases/3.3/rc1/">http://llvm.org/pre-releases/3.3/rc1/</a>).</li>
+<li>Repeat the steps above with <tt class="docutils literal"><span class="pre">-rc</span> <span class="pre">1</span></tt>, <tt class="docutils literal"><span class="pre">-rc</span> <span class="pre">2</span></tt> etc modes and run the test-suite
+the same way.</li>
+<li>Compare the results, report all errors on Bugzilla and publish the binary blob
+where the release manager can grab it.</li>
+</ul>
+<p>Once the release manages announces that the latest candidate is the good one, you
+have to pack the <tt class="docutils literal"><span class="pre">Release</span></tt> (no Asserts) install directory on <tt class="docutils literal"><span class="pre">Phase3</span></tt> and that
+will be the official binary.</p>
+<ul class="simple">
+<li>Rename (or link) <tt class="docutils literal"><span class="pre">clang+llvm-REL-ARCH-ENV</span></tt> to the .install directory</li>
+<li>Tar that into the same name with <tt class="docutils literal"><span class="pre">.tar.gz</span></tt> extensioan from outside the directory</li>
+<li>Make it available for the release manager to download</li>
+</ul>
+</div>
+<div class="section" id="bug-reporting-process">
+<span id="bug-reporting"></span><h2><a class="toc-backref" href="#id14">Bug Reporting Process</a><a class="headerlink" href="#bug-reporting-process" title="Permalink to this headline">¶</a></h2>
+<p>If you found regressions or failures when comparing a release candidate with the
+previous release, follow the rules below:</p>
+<ul class="simple">
+<li>Critical bugs on compilation should be fixed as soon as possible, possibly before
+releasing the binary blobs.</li>
+<li>Check-all tests should be fixed before the next release candidate, but can wait
+until the test-suite run is finished.</li>
+<li>Bugs in the test suite or unimportant check-all tests can be fixed in between
+release candidates.</li>
+<li>New features or recent big changes, when close to the release, should have done
+in a way that it’s easy to disable. If they misbehave, prefer disabling them than
+releasing an unstable (but untested) binary package.</li>
+</ul>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="Packaging.html" title="Advice on Packaging LLVM"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/ReportingGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/ReportingGuide.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/ReportingGuide.html (added)
+++ www-releases/trunk/6.0.1/docs/ReportingGuide.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,220 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Reporting Guide — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Benchmarking tips" href="Benchmarking.html" />
+ <link rel="prev" title="Compiling CUDA with clang" href="CompileCudaWithLLVM.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Benchmarking.html" title="Benchmarking tips"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="CompileCudaWithLLVM.html" title="Compiling CUDA with clang"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="reporting-guide">
+<h1>Reporting Guide<a class="headerlink" href="#reporting-guide" title="Permalink to this headline">¶</a></h1>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">This document is currently a <strong>DRAFT</strong> document while it is being discussed
+by the community.</p>
+</div>
+<p>If you believe someone is violating the <a class="reference internal" href="CodeOfConduct.html"><em>code of conduct</em></a>
+you can always report it to the LLVM Foundation Code of Conduct Advisory
+Committee by emailing <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>. <strong>All reports will be kept
+confidential.</strong> This isn’t a public list and only <a class="reference internal" href="#members">members</a> of the advisory
+committee will receive the report.</p>
+<p>If you believe anyone is in <strong>physical danger</strong>, please notify appropriate law
+enforcement first. If you are unsure what law enforcement agency is
+appropriate, please include this in your report and we will attempt to notify
+them.</p>
+<p>If the violation occurs at an event such as a Developer Meeting and requires
+immediate attention, you can also reach out to any of the event organizers or
+staff. Event organizers and staff will be prepared to handle the incident and
+able to help. If you cannot find one of the organizers, the venue staff can
+locate one for you. We will also post detailed contact information for specific
+events as part of each events’ information. In person reports will still be
+kept confidential exactly as above, but also feel free to (anonymously if
+needed) email <a class="reference external" href="mailto:conduct%40llvm.org">conduct<span>@</span>llvm<span>.</span>org</a>.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">The LLVM community has long handled inappropriate behavior on its own, using
+both private communication and public responses. Nothing in this document is
+intended to discourage this self enforcement of community norms. Instead,
+the mechanisms described here are intended to supplement any self
+enforcement within the community. They provide avenues for handling severe
+cases or cases where the reporting party does not wish to respond directly
+for any reason.</p>
+</div>
+<div class="section" id="filing-a-report">
+<h2>Filing a report<a class="headerlink" href="#filing-a-report" title="Permalink to this headline">¶</a></h2>
+<p>Reports can be as formal or informal as needed for the situation at hand. If
+possible, please include as much information as you can. If you feel
+comfortable, please consider including:</p>
+<ul class="simple">
+<li>Your contact info (so we can get in touch with you if we need to follow up).</li>
+<li>Names (real, nicknames, or pseudonyms) of any individuals involved. If there
+were other witnesses besides you, please try to include them as well.</li>
+<li>When and where the incident occurred. Please be as specific as possible.</li>
+<li>Your account of what occurred. If there is a publicly available record (e.g.
+a mailing list archive or a public IRC logger) please include a link.</li>
+<li>Any extra context you believe existed for the incident.</li>
+<li>If you believe this incident is ongoing.</li>
+<li>Any other information you believe we should have.</li>
+</ul>
+</div>
+<div class="section" id="what-happens-after-you-file-a-report">
+<h2>What happens after you file a report?<a class="headerlink" href="#what-happens-after-you-file-a-report" title="Permalink to this headline">¶</a></h2>
+<p>You will receive an email from the advisory committee acknowledging receipt
+within 24 hours (and we will aim to respond much quicker than that).</p>
+<p>The advisory committee will immediately meet to review the incident and try to
+determine:</p>
+<ul class="simple">
+<li>What happened and who was involved.</li>
+<li>Whether this event constitutes a code of conduct violation.</li>
+<li>Whether this is an ongoing situation, or if there is a threat to anyone’s
+physical safety.</li>
+</ul>
+<p>If this is determined to be an ongoing incident or a threat to physical safety,
+the working groups’ immediate priority will be to protect everyone involved.
+This means we may delay an “official” response until we believe that the
+situation has ended and that everyone is physically safe.</p>
+<p>The working group will try to contact other parties involved or witnessing the
+event to gain clarity on what happened and understand any different
+perspectives.</p>
+<p>Once the advisory committee has a complete account of the events they will make
+a decision as to how to respond. Responses may include:</p>
+<ul class="simple">
+<li>Nothing, if we determine no violation occurred or it has already been
+appropriately resolved.</li>
+<li>Providing either moderation or mediation to ongoing interactions (where
+appropriate, safe, and desired by both parties).</li>
+<li>A private reprimand from the working group to the individuals involved.</li>
+<li>An imposed vacation (i.e. asking someone to “take a week off” from a mailing
+list or IRC).</li>
+<li>A public reprimand.</li>
+<li>A permanent or temporary ban from some or all LLVM spaces (mailing lists,
+IRC, etc.)</li>
+<li>Involvement of relevant law enforcement if appropriate.</li>
+</ul>
+<p>If the situation is not resolved within one week, we’ll respond within one week
+to the original reporter with an update and explanation.</p>
+<p>Once we’ve determined our response, we will separately contact the original
+reporter and other individuals to let them know what actions (if any) we’ll be
+taking. We will take into account feedback from the individuals involved on the
+appropriateness of our response, but we don’t guarantee we’ll act on it.</p>
+<p>After any incident, the advisory committee will make a report on the situation
+to the LLVM Foundation board. The board may choose to make a public statement
+about the incident. If that’s the case, the identities of anyone involved will
+remain confidential unless instructed by those inviduals otherwise.</p>
+</div>
+<div class="section" id="appealing">
+<h2>Appealing<a class="headerlink" href="#appealing" title="Permalink to this headline">¶</a></h2>
+<p>Only permanent resolutions (such as bans) or requests for public actions may be
+appealed. To appeal a decision of the working group, contact the LLVM
+Foundation board at <a class="reference external" href="mailto:board%40llvm.org">board<span>@</span>llvm<span>.</span>org</a> with your appeal and the board will review
+the case.</p>
+<p>In general, it is <strong>not</strong> appropriate to appeal a particular decision on
+a public mailing list. Doing so would involve disclosure of information which
+whould be confidential. Disclosing this kind of information publicly may be
+considered a separate and (potentially) more serious violation of the Code of
+Conduct. This is not meant to limit discussion of the Code of Conduct, the
+advisory board itself, or the appropriateness of responses in general, but
+<strong>please</strong> refrain from mentioning specific facts about cases without the
+explicit permission of all parties involved.</p>
+</div>
+<div class="section" id="members-of-the-code-of-conduct-advisory-committee">
+<span id="members"></span><h2>Members of the Code of Conduct Advisory Committee<a class="headerlink" href="#members-of-the-code-of-conduct-advisory-committee" title="Permalink to this headline">¶</a></h2>
+<p>The members serving on the advisory committee are listed here with contact
+information in case you are more comfortable talking directly to a specific
+member of the committee.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">FIXME: When we form the initial advisory committee, the members names and private contact info need to be added here.</p>
+</div>
+<p>(This text is based on the <a class="reference external" href="https://www.djangoproject.com/conduct/">Django Project</a> Code of Conduct, which is in turn
+based on wording from the <a class="reference external" href="http://speakup.io/coc.html">Speak Up! project</a>.)</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Benchmarking.html" title="Benchmarking tips"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="CompileCudaWithLLVM.html" title="Compiling CUDA with clang"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/ScudoHardenedAllocator.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/ScudoHardenedAllocator.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/ScudoHardenedAllocator.html (added)
+++ www-releases/trunk/6.0.1/docs/ScudoHardenedAllocator.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,276 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Scudo Hardened Allocator — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Using -opt-bisect-limit to debug optimization errors" href="OptBisect.html" />
+ <link rel="prev" title="Fuzzing LLVM libraries and tools" href="FuzzingLLVM.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="OptBisect.html" title="Using -opt-bisect-limit to debug optimization errors"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="FuzzingLLVM.html" title="Fuzzing LLVM libraries and tools"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="scudo-hardened-allocator">
+<h1>Scudo Hardened Allocator<a class="headerlink" href="#scudo-hardened-allocator" 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="#design" id="id2">Design</a></li>
+<li><a class="reference internal" href="#usage" id="id3">Usage</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>The Scudo Hardened Allocator is a user-mode allocator based on LLVM Sanitizer’s
+CombinedAllocator, which aims at providing additional mitigations against heap
+based vulnerabilities, while maintaining good performance.</p>
+<p>Currently, the allocator supports (was tested on) the following architectures:</p>
+<ul class="simple">
+<li>i386 (& i686) (32-bit);</li>
+<li>x86_64 (64-bit);</li>
+<li>armhf (32-bit);</li>
+<li>AArch64 (64-bit).</li>
+</ul>
+<p>The name “Scudo” has been retained from the initial implementation (Escudo
+meaning Shield in Spanish and Portuguese).</p>
+</div>
+<div class="section" id="design">
+<h2><a class="toc-backref" href="#id2">Design</a><a class="headerlink" href="#design" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="chunk-header">
+<h3>Chunk Header<a class="headerlink" href="#chunk-header" title="Permalink to this headline">¶</a></h3>
+<p>Every chunk of heap memory will be preceded by a chunk header. This has two
+purposes, the first one being to store various information about the chunk,
+the second one being to detect potential heap overflows. In order to achieve
+this, the header will be checksumed, involving the pointer to the chunk itself
+and a global secret. Any corruption of the header will be detected when said
+header is accessed, and the process terminated.</p>
+<p>The following information is stored in the header:</p>
+<ul class="simple">
+<li>the 16-bit checksum;</li>
+<li>the unused bytes amount for that chunk, which is necessary for computing the
+size of the chunk;</li>
+<li>the state of the chunk (available, allocated or quarantined);</li>
+<li>the allocation type (malloc, new, new[] or memalign), to detect potential
+mismatches in the allocation APIs used;</li>
+<li>the offset of the chunk, which is the distance in bytes from the beginning of
+the returned chunk to the beginning of the backend allocation;</li>
+<li>a 8-bit salt.</li>
+</ul>
+<p>This header fits within 8 bytes, on all platforms supported.</p>
+<p>The checksum is computed as a CRC32 (made faster with hardware support)
+of the global secret, the chunk pointer itself, and the 8 bytes of header with
+the checksum field zeroed out.</p>
+<p>The header is atomically loaded and stored to prevent races. This is important
+as two consecutive chunks could belong to different threads. We also want to
+avoid any type of double fetches of information located in the header, and use
+local copies of the header for this purpose.</p>
+</div>
+<div class="section" id="delayed-freelist">
+<h3>Delayed Freelist<a class="headerlink" href="#delayed-freelist" title="Permalink to this headline">¶</a></h3>
+<p>A delayed freelist allows us to not return a chunk directly to the backend, but
+to keep it aside for a while. Once a criterion is met, the delayed freelist is
+emptied, and the quarantined chunks are returned to the backend. This helps
+mitigate use-after-free vulnerabilities by reducing the determinism of the
+allocation and deallocation patterns.</p>
+<p>This feature is using the Sanitizer’s Quarantine as its base, and the amount of
+memory that it can hold is configurable by the user (see the Options section
+below).</p>
+</div>
+<div class="section" id="randomness">
+<h3>Randomness<a class="headerlink" href="#randomness" title="Permalink to this headline">¶</a></h3>
+<p>It is important for the allocator to not make use of fixed addresses. We use
+the dynamic base option for the SizeClassAllocator, allowing us to benefit
+from the randomness of mmap.</p>
+</div>
+</div>
+<div class="section" id="usage">
+<h2><a class="toc-backref" href="#id3">Usage</a><a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="library">
+<h3>Library<a class="headerlink" href="#library" title="Permalink to this headline">¶</a></h3>
+<p>The allocator static library can be built from the LLVM build tree thanks to
+the <tt class="docutils literal"><span class="pre">scudo</span></tt> CMake rule. The associated tests can be exercised thanks to the
+<tt class="docutils literal"><span class="pre">check-scudo</span></tt> CMake rule.</p>
+<p>Linking the static library to your project can require the use of the
+<tt class="docutils literal"><span class="pre">whole-archive</span></tt> linker flag (or equivalent), depending on your linker.
+Additional flags might also be necessary.</p>
+<p>Your linked binary should now make use of the Scudo allocation and deallocation
+functions.</p>
+<p>You may also build Scudo like this:</p>
+<div class="code highlight-python"><pre>cd $LLVM/projects/compiler-rt/lib
+clang++ -fPIC -std=c++11 -msse4.2 -O2 -I. scudo/*.cpp \
+ $(\ls sanitizer_common/*.{cc,S} | grep -v "sanitizer_termination\|sanitizer_common_nolibc") \
+ -shared -o scudo-allocator.so -pthread</pre>
+</div>
+<p>and then use it with existing binaries as follows:</p>
+<div class="code highlight-python"><pre>LD_PRELOAD=`pwd`/scudo-allocator.so ./a.out</pre>
+</div>
+</div>
+<div class="section" id="options">
+<h3>Options<a class="headerlink" href="#options" title="Permalink to this headline">¶</a></h3>
+<p>Several aspects of the allocator can be configured through the following ways:</p>
+<ul class="simple">
+<li>by defining a <tt class="docutils literal"><span class="pre">__scudo_default_options</span></tt> function in one’s program that
+returns the options string to be parsed. Said function must have the following
+prototype: <tt class="docutils literal"><span class="pre">extern</span> <span class="pre">"C"</span> <span class="pre">const</span> <span class="pre">char*</span> <span class="pre">__scudo_default_options()</span></tt>.</li>
+<li>through the environment variable SCUDO_OPTIONS, containing the options string
+to be parsed. Options defined this way will override any definition made
+through <tt class="docutils literal"><span class="pre">__scudo_default_options</span></tt>;</li>
+</ul>
+<p>The options string follows a syntax similar to ASan, where distinct options
+can be assigned in the same string, separated by colons.</p>
+<p>For example, using the environment variable:</p>
+<div class="code highlight-python"><pre>SCUDO_OPTIONS="DeleteSizeMismatch=1:QuarantineSizeKb=64" ./a.out</pre>
+</div>
+<p>Or using the function:</p>
+<div class="code cpp highlight-python"><pre>extern "C" const char *__scudo_default_options() {
+ return "DeleteSizeMismatch=1:QuarantineSizeKb=64";
+}</pre>
+</div>
+<p>The following options are available:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="27%" />
+<col width="15%" />
+<col width="15%" />
+<col width="44%" />
+</colgroup>
+<tbody valign="top">
+<tr class="row-odd"><td>Option</td>
+<td>64-bit default</td>
+<td>32-bit default</td>
+<td>Description</td>
+</tr>
+<tr class="row-even"><td>QuarantineSizeKb</td>
+<td>256</td>
+<td>64</td>
+<td>The size (in Kb) of quarantine used to delay
+the actual deallocation of chunks. Lower value
+may reduce memory usage but decrease the
+effectiveness of the mitigation; a negative
+value will fallback to the defaults.</td>
+</tr>
+<tr class="row-odd"><td>QuarantineChunksUpToSize</td>
+<td>2048</td>
+<td>512</td>
+<td>Size (in bytes) up to which chunks can be
+quarantined.</td>
+</tr>
+<tr class="row-even"><td>ThreadLocalQuarantineSizeKb</td>
+<td>1024</td>
+<td>256</td>
+<td>The size (in Kb) of per-thread cache use to
+offload the global quarantine. Lower value may
+reduce memory usage but might increase
+contention on the global quarantine.</td>
+</tr>
+<tr class="row-odd"><td>DeallocationTypeMismatch</td>
+<td>true</td>
+<td>true</td>
+<td>Whether or not we report errors on
+malloc/delete, new/free, new/delete[], etc.</td>
+</tr>
+<tr class="row-even"><td>DeleteSizeMismatch</td>
+<td>true</td>
+<td>true</td>
+<td>Whether or not we report errors on mismatch
+between sizes of new and delete.</td>
+</tr>
+<tr class="row-odd"><td>ZeroContents</td>
+<td>false</td>
+<td>false</td>
+<td>Whether or not we zero chunk contents on
+allocation and deallocation.</td>
+</tr>
+</tbody>
+</table>
+<p>Allocator related common Sanitizer options can also be passed through Scudo
+options, such as <tt class="docutils literal"><span class="pre">allocator_may_return_null</span></tt>. A detailed list including those
+can be found here:
+<a class="reference external" href="https://github.com/google/sanitizers/wiki/SanitizerCommonFlags">https://github.com/google/sanitizers/wiki/SanitizerCommonFlags</a>.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="OptBisect.html" title="Using -opt-bisect-limit to debug optimization errors"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="FuzzingLLVM.html" title="Fuzzing LLVM libraries and tools"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/SegmentedStacks.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/SegmentedStacks.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/SegmentedStacks.html (added)
+++ www-releases/trunk/6.0.1/docs/SegmentedStacks.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,170 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Segmented Stacks in LLVM — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="TableGen Fundamentals" href="TableGenFundamentals.html" />
+ <link rel="prev" title="LLVM Link Time Optimization: Design and Implementation" href="LinkTimeOptimization.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="TableGenFundamentals.html" title="TableGen Fundamentals"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="LinkTimeOptimization.html" title="LLVM Link Time Optimization: Design and Implementation"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="segmented-stacks-in-llvm">
+<h1>Segmented Stacks in LLVM<a class="headerlink" href="#segmented-stacks-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="#introduction" id="id2">Introduction</a></li>
+<li><a class="reference internal" href="#implementation-details" id="id3">Implementation Details</a><ul>
+<li><a class="reference internal" href="#allocating-stacklets" id="id4">Allocating Stacklets</a></li>
+<li><a class="reference internal" href="#variable-sized-allocas" id="id5">Variable Sized Allocas</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>Segmented stack allows stack space to be allocated incrementally than as a
+monolithic chunk (of some worst case size) at thread initialization. This is
+done by allocating stack blocks (henceforth called <em>stacklets</em>) and linking them
+into a doubly linked list. The function prologue is responsible for checking if
+the current stacklet has enough space for the function to execute; and if not,
+call into the libgcc runtime to allocate more stack space. Segmented stacks are
+enabled with the <tt class="docutils literal"><span class="pre">"split-stack"</span></tt> attribute on LLVM functions.</p>
+<p>The runtime functionality is <a class="reference external" href="http://gcc.gnu.org/wiki/SplitStacks">already there in libgcc</a>.</p>
+</div>
+<div class="section" id="implementation-details">
+<h2><a class="toc-backref" href="#id3">Implementation Details</a><a class="headerlink" href="#implementation-details" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="allocating-stacklets">
+<span id="id1"></span><h3><a class="toc-backref" href="#id4">Allocating Stacklets</a><a class="headerlink" href="#allocating-stacklets" title="Permalink to this headline">¶</a></h3>
+<p>As mentioned above, the function prologue checks if the current stacklet has
+enough space. The current approach is to use a slot in the TCB to store the
+current stack limit (minus the amount of space needed to allocate a new block) -
+this slot’s offset is again dictated by <tt class="docutils literal"><span class="pre">libgcc</span></tt>. The generated
+assembly looks like this on x86-64:</p>
+<div class="highlight-text"><div class="highlight"><pre> leaq -8(%rsp), %r10
+ cmpq %fs:112, %r10
+ jg .LBB0_2
+
+ # More stack space needs to be allocated
+ movabsq $8, %r10 # The amount of space needed
+ movabsq $0, %r11 # The total size of arguments passed on stack
+ callq __morestack
+ ret # The reason for this extra return is explained below
+.LBB0_2:
+ # Usual prologue continues here
+</pre></div>
+</div>
+<p>The size of function arguments on the stack needs to be passed to
+<tt class="docutils literal"><span class="pre">__morestack</span></tt> (this function is implemented in <tt class="docutils literal"><span class="pre">libgcc</span></tt>) since that number
+of bytes has to be copied from the previous stacklet to the current one. This is
+so that SP (and FP) relative addressing of function arguments work as expected.</p>
+<p>The unusual <tt class="docutils literal"><span class="pre">ret</span></tt> is needed to have the function which made a call to
+<tt class="docutils literal"><span class="pre">__morestack</span></tt> return correctly. <tt class="docutils literal"><span class="pre">__morestack</span></tt>, instead of returning, calls
+into <tt class="docutils literal"><span class="pre">.LBB0_2</span></tt>. This is possible since both, the size of the <tt class="docutils literal"><span class="pre">ret</span></tt>
+instruction and the PC of call to <tt class="docutils literal"><span class="pre">__morestack</span></tt> are known. When the function
+body returns, control is transferred back to <tt class="docutils literal"><span class="pre">__morestack</span></tt>. <tt class="docutils literal"><span class="pre">__morestack</span></tt>
+then de-allocates the new stacklet, restores the correct SP value, and does a
+second return, which returns control to the correct caller.</p>
+</div>
+<div class="section" id="variable-sized-allocas">
+<h3><a class="toc-backref" href="#id5">Variable Sized Allocas</a><a class="headerlink" href="#variable-sized-allocas" title="Permalink to this headline">¶</a></h3>
+<p>The section on <a class="reference internal" href="#allocating-stacklets">allocating stacklets</a> automatically assumes that every stack
+frame will be of fixed size. However, LLVM allows the use of the <tt class="docutils literal"><span class="pre">llvm.alloca</span></tt>
+intrinsic to allocate dynamically sized blocks of memory on the stack. When
+faced with such a variable-sized alloca, code is generated to:</p>
+<ul class="simple">
+<li>Check if the current stacklet has enough space. If yes, just bump the SP, like
+in the normal case.</li>
+<li>If not, generate a call to <tt class="docutils literal"><span class="pre">libgcc</span></tt>, which allocates the memory from the
+heap.</li>
+</ul>
+<p>The memory allocated from the heap is linked into a list in the current
+stacklet, and freed along with the same. This prevents a memory leak.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="TableGenFundamentals.html" title="TableGen Fundamentals"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="LinkTimeOptimization.html" title="LLVM Link Time Optimization: Design and Implementation"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/SourceLevelDebugging.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/SourceLevelDebugging.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/SourceLevelDebugging.html (added)
+++ www-releases/trunk/6.0.1/docs/SourceLevelDebugging.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,1494 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Source Level Debugging with LLVM — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Auto-Vectorization in LLVM" href="Vectorizers.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">
+ <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="Vectorizers.html" title="Auto-Vectorization in 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">
+
+ <div class="section" id="source-level-debugging-with-llvm">
+<h1>Source Level Debugging with LLVM<a class="headerlink" href="#source-level-debugging-with-llvm" 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="id8">Introduction</a><ul>
+<li><a class="reference internal" href="#philosophy-behind-llvm-debugging-information" id="id9">Philosophy behind LLVM debugging information</a></li>
+<li><a class="reference internal" href="#debug-information-consumers" id="id10">Debug information consumers</a></li>
+<li><a class="reference internal" href="#debugging-optimized-code" id="id11">Debugging optimized code</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#debugging-information-format" id="id12">Debugging information format</a><ul>
+<li><a class="reference internal" href="#debugger-intrinsic-functions" id="id13">Debugger intrinsic functions</a><ul>
+<li><a class="reference internal" href="#llvm-dbg-addr" id="id14"><tt class="docutils literal"><span class="pre">llvm.dbg.addr</span></tt></a></li>
+<li><a class="reference internal" href="#llvm-dbg-declare" id="id15"><tt class="docutils literal"><span class="pre">llvm.dbg.declare</span></tt></a></li>
+<li><a class="reference internal" href="#llvm-dbg-value" id="id16"><tt class="docutils literal"><span class="pre">llvm.dbg.value</span></tt></a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#object-lifetimes-and-scoping" id="id17">Object lifetimes and scoping</a></li>
+<li><a class="reference internal" href="#c-c-front-end-specific-debug-information" id="id18">C/C++ front-end specific debug information</a><ul>
+<li><a class="reference internal" href="#c-c-source-file-information" id="id19">C/C++ source file information</a></li>
+<li><a class="reference internal" href="#c-c-global-variable-information" id="id20">C/C++ global variable information</a></li>
+<li><a class="reference internal" href="#c-c-function-information" id="id21">C/C++ function information</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#id4" id="id22">Debugging information format</a><ul>
+<li><a class="reference internal" href="#debugging-information-extension-for-objective-c-properties" id="id23">Debugging Information Extension for Objective C Properties</a><ul>
+<li><a class="reference internal" href="#id5" id="id24">Introduction</a></li>
+<li><a class="reference internal" href="#proposal" id="id25">Proposal</a></li>
+<li><a class="reference internal" href="#new-dwarf-tags" id="id26">New DWARF Tags</a></li>
+<li><a class="reference internal" href="#new-dwarf-attributes" id="id27">New DWARF Attributes</a></li>
+<li><a class="reference internal" href="#new-dwarf-constants" id="id28">New DWARF Constants</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#name-accelerator-tables" id="id29">Name Accelerator Tables</a><ul>
+<li><a class="reference internal" href="#id6" id="id30">Introduction</a></li>
+<li><a class="reference internal" href="#hash-tables" id="id31">Hash Tables</a><ul>
+<li><a class="reference internal" href="#standard-hash-tables" id="id32">Standard Hash Tables</a></li>
+<li><a class="reference internal" href="#name-hash-tables" id="id33">Name Hash Tables</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#details" id="id34">Details</a><ul>
+<li><a class="reference internal" href="#header-layout" id="id35">Header Layout</a></li>
+<li><a class="reference internal" href="#fixed-lookup" id="id36">Fixed Lookup</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#id7" id="id37">Contents</a></li>
+<li><a class="reference internal" href="#language-extensions-and-file-format-changes" id="id38">Language Extensions and File Format Changes</a><ul>
+<li><a class="reference internal" href="#objective-c-extensions" id="id39">Objective-C Extensions</a></li>
+<li><a class="reference internal" href="#mach-o-changes" id="id40">Mach-O Changes</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#codeview-debug-info-format" id="id41">CodeView Debug Info Format</a><ul>
+<li><a class="reference internal" href="#format-background" id="id42">Format Background</a></li>
+<li><a class="reference internal" href="#working-with-codeview" id="id43">Working with CodeView</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id8">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document is the central repository for all information pertaining to debug
+information in LLVM. It describes the <a class="reference internal" href="#format"><em>actual format that the LLVM debug
+information takes</em></a>, which is useful for those interested in creating
+front-ends or dealing directly with the information. Further, this document
+provides specific examples of what debug information for C/C++ looks like.</p>
+<div class="section" id="philosophy-behind-llvm-debugging-information">
+<h3><a class="toc-backref" href="#id9">Philosophy behind LLVM debugging information</a><a class="headerlink" href="#philosophy-behind-llvm-debugging-information" title="Permalink to this headline">¶</a></h3>
+<p>The idea of the LLVM debugging information is to capture how the important
+pieces of the source-language’s Abstract Syntax Tree map onto LLVM code.
+Several design aspects have shaped the solution that appears here. The
+important ones are:</p>
+<ul class="simple">
+<li>Debugging information should have very little impact on the rest of the
+compiler. No transformations, analyses, or code generators should need to
+be modified because of debugging information.</li>
+<li>LLVM optimizations should interact in <a class="reference internal" href="#intro-debugopt"><em>well-defined and easily described
+ways</em></a> with the debugging information.</li>
+<li>Because LLVM is designed to support arbitrary programming languages,
+LLVM-to-LLVM tools should not need to know anything about the semantics of
+the source-level-language.</li>
+<li>Source-level languages are often <strong>widely</strong> different from one another.
+LLVM should not put any restrictions of the flavor of the source-language,
+and the debugging information should work with any language.</li>
+<li>With code generator support, it should be possible to use an LLVM compiler
+to compile a program to native machine code and standard debugging
+formats. This allows compatibility with traditional machine-code level
+debuggers, like GDB or DBX.</li>
+</ul>
+<p>The approach used by the LLVM implementation is to use a small set of
+<a class="reference internal" href="#format-common-intrinsics"><em>intrinsic functions</em></a> to define a mapping
+between LLVM program objects and the source-level objects. The description of
+the source-level program is maintained in LLVM metadata in an
+<a class="reference internal" href="#ccxx-frontend"><em>implementation-defined format</em></a> (the C/C++ front-end
+currently uses working draft 7 of the <a class="reference external" href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3 standard</a>).</p>
+<p>When a program is being debugged, a debugger interacts with the user and turns
+the stored debug information into source-language specific information. As
+such, a debugger must be aware of the source-language, and is thus tied to a
+specific language or family of languages.</p>
+</div>
+<div class="section" id="debug-information-consumers">
+<h3><a class="toc-backref" href="#id10">Debug information consumers</a><a class="headerlink" href="#debug-information-consumers" title="Permalink to this headline">¶</a></h3>
+<p>The role of debug information is to provide meta information normally stripped
+away during the compilation process. This meta information provides an LLVM
+user a relationship between generated code and the original program source
+code.</p>
+<p>Currently, there are two backend consumers of debug info: DwarfDebug and
+CodeViewDebug. DwarfDebug produces DWARF suitable for use with GDB, LLDB, and
+other DWARF-based debuggers. <a class="reference internal" href="#codeview"><em>CodeViewDebug</em></a> produces CodeView,
+the Microsoft debug info format, which is usable with Microsoft debuggers such
+as Visual Studio and WinDBG. LLVM’s debug information format is mostly derived
+from and inspired by DWARF, but it is feasible to translate into other target
+debug info formats such as STABS.</p>
+<p>It would also be reasonable to use debug information to feed profiling tools
+for analysis of generated code, or, tools for reconstructing the original
+source from generated code.</p>
+</div>
+<div class="section" id="debugging-optimized-code">
+<span id="intro-debugopt"></span><h3><a class="toc-backref" href="#id11">Debugging optimized code</a><a class="headerlink" href="#debugging-optimized-code" title="Permalink to this headline">¶</a></h3>
+<p>An extremely high priority of LLVM debugging information is to make it interact
+well with optimizations and analysis. In particular, the LLVM debug
+information provides the following guarantees:</p>
+<ul class="simple">
+<li>LLVM debug information <strong>always provides information to accurately read
+the source-level state of the program</strong>, regardless of which LLVM
+optimizations have been run, and without any modification to the
+optimizations themselves. However, some optimizations may impact the
+ability to modify the current state of the program with a debugger, such
+as setting program variables, or calling functions that have been
+deleted.</li>
+<li>As desired, LLVM optimizations can be upgraded to be aware of debugging
+information, allowing them to update the debugging information as they
+perform aggressive optimizations. This means that, with effort, the LLVM
+optimizers could optimize debug code just as well as non-debug code.</li>
+<li>LLVM debug information does not prevent optimizations from
+happening (for example inlining, basic block reordering/merging/cleanup,
+tail duplication, etc).</li>
+<li>LLVM debug information is automatically optimized along with the rest of
+the program, using existing facilities. For example, duplicate
+information is automatically merged by the linker, and unused information
+is automatically removed.</li>
+</ul>
+<p>Basically, the debug information allows you to compile a program with
+“<tt class="docutils literal"><span class="pre">-O0</span> <span class="pre">-g</span></tt>” and get full debug information, allowing you to arbitrarily modify
+the program as it executes from a debugger. Compiling a program with
+“<tt class="docutils literal"><span class="pre">-O3</span> <span class="pre">-g</span></tt>” gives you full debug information that is always available and
+accurate for reading (e.g., you get accurate stack traces despite tail call
+elimination and inlining), but you might lose the ability to modify the program
+and call functions which were optimized out of the program, or inlined away
+completely.</p>
+<p>The <a class="reference internal" href="TestingGuide.html#test-suite-quickstart"><em>LLVM test suite</em></a> provides a framework to test
+optimizer’s handling of debugging information. It can be run like this:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% <span class="nb">cd </span>llvm/projects/test-suite/MultiSource/Benchmarks <span class="c"># or some other level</span>
+% make <span class="nv">TEST</span><span class="o">=</span>dbgopt
+</pre></div>
+</div>
+<p>This will test impact of debugging information on optimization passes. If
+debugging information influences optimization passes then it will be reported
+as a failure. See <a class="reference internal" href="TestingGuide.html"><em>LLVM Testing Infrastructure Guide</em></a> for more information on LLVM test
+infrastructure and how to run various tests.</p>
+</div>
+</div>
+<div class="section" id="debugging-information-format">
+<span id="format"></span><h2><a class="toc-backref" href="#id12">Debugging information format</a><a class="headerlink" href="#debugging-information-format" title="Permalink to this headline">¶</a></h2>
+<p>LLVM debugging information has been carefully designed to make it possible for
+the optimizer to optimize the program and debugging information without
+necessarily having to know anything about debugging information. In
+particular, the use of metadata avoids duplicated debugging information from
+the beginning, and the global dead code elimination pass automatically deletes
+debugging information for a function if it decides to delete the function.</p>
+<p>To do this, most of the debugging information (descriptors for types,
+variables, functions, source files, etc) is inserted by the language front-end
+in the form of LLVM metadata.</p>
+<p>Debug information is designed to be agnostic about the target debugger and
+debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic
+pass to decode the information that represents variables, types, functions,
+namespaces, etc: this allows for arbitrary source-language semantics and
+type-systems to be used, as long as there is a module written for the target
+debugger to interpret the information.</p>
+<p>To provide basic functionality, the LLVM debugger does have to make some
+assumptions about the source-level language being debugged, though it keeps
+these to a minimum. The only common features that the LLVM debugger assumes
+exist are <a class="reference external" href="LangRef.html#difile">source files</a>, and <a class="reference external" href="LangRef.html#diglobalvariable">program objects</a>. These abstract objects are used by a
+debugger to form stack traces, show information about local variables, etc.</p>
+<p>This section of the documentation first describes the representation aspects
+common to any source-language. <a class="reference internal" href="#ccxx-frontend"><em>C/C++ front-end specific debug information</em></a> describes the data layout
+conventions used by the C and C++ front-ends.</p>
+<p>Debug information descriptors are <a class="reference external" href="LangRef.html#specialized-metadata">specialized metadata nodes</a>, first-class subclasses of <tt class="docutils literal"><span class="pre">Metadata</span></tt>.</p>
+<div class="section" id="debugger-intrinsic-functions">
+<span id="format-common-intrinsics"></span><h3><a class="toc-backref" href="#id13">Debugger intrinsic functions</a><a class="headerlink" href="#debugger-intrinsic-functions" title="Permalink to this headline">¶</a></h3>
+<p>LLVM uses several intrinsic functions (name prefixed with “<tt class="docutils literal"><span class="pre">llvm.dbg</span></tt>”) to
+track source local variables through optimization and code generation.</p>
+<div class="section" id="llvm-dbg-addr">
+<h4><a class="toc-backref" href="#id14"><tt class="docutils literal"><span class="pre">llvm.dbg.addr</span></tt></a><a class="headerlink" href="#llvm-dbg-addr" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="kt">void</span> <span class="vg">@llvm.dbg.addr</span><span class="p">(</span><span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>This intrinsic provides information about a local element (e.g., variable).
+The first argument is metadata holding the address of variable, typically a
+static alloca in the function entry block. The second argument is a
+<a class="reference external" href="LangRef.html#dilocalvariable">local variable</a> containing a description of
+the variable. The third argument is a <a class="reference external" href="LangRef.html#diexpression">complex expression</a>. An <cite>llvm.dbg.addr</cite> intrinsic describes the
+<em>address</em> of a source variable.</p>
+<div class="highlight-text"><div class="highlight"><pre>%i.addr = alloca i32, align 4
+call void @llvm.dbg.addr(metadata i32* %i.addr, metadata !1,
+ metadata !DIExpression()), !dbg !2
+!1 = !DILocalVariable(name: "i", ...) ; int i
+!2 = !DILocation(...)
+...
+%buffer = alloca [256 x i8], align 8
+; The address of i is buffer+64.
+call void @llvm.dbg.addr(metadata [256 x i8]* %buffer, metadata !3,
+ metadata !DIExpression(DW_OP_plus, 64)), !dbg !4
+!3 = !DILocalVariable(name: "i", ...) ; int i
+!4 = !DILocation(...)
+</pre></div>
+</div>
+<p>A frontend should generate exactly one call to <tt class="docutils literal"><span class="pre">llvm.dbg.addr</span></tt> at the point
+of declaration of a source variable. Optimization passes that fully promote the
+variable from memory to SSA values will replace this call with possibly
+multiple calls to <cite>llvm.dbg.value</cite>. Passes that delete stores are effectively
+partial promotion, and they will insert a mix of calls to <tt class="docutils literal"><span class="pre">llvm.dbg.value</span></tt>
+and <tt class="docutils literal"><span class="pre">llvm.dbg.addr</span></tt> to track the source variable value when it is available.
+After optimization, there may be multiple calls to <tt class="docutils literal"><span class="pre">llvm.dbg.addr</span></tt> describing
+the program points where the variables lives in memory. All calls for the same
+concrete source variable must agree on the memory location.</p>
+</div>
+<div class="section" id="llvm-dbg-declare">
+<h4><a class="toc-backref" href="#id15"><tt class="docutils literal"><span class="pre">llvm.dbg.declare</span></tt></a><a class="headerlink" href="#llvm-dbg-declare" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="kt">void</span> <span class="vg">@llvm.dbg.declare</span><span class="p">(</span><span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>This intrinsic is identical to <cite>llvm.dbg.addr</cite>, except that there can only be
+one call to <cite>llvm.dbg.declare</cite> for a given concrete <a class="reference external" href="LangRef.html#dilocalvariable">local variable</a>. It is not control-dependent, meaning that if
+a call to <cite>llvm.dbg.declare</cite> exists and has a valid location argument, that
+address is considered to be the true home of the variable across its entire
+lifetime. This makes it hard for optimizations to preserve accurate debug info
+in the presence of <tt class="docutils literal"><span class="pre">llvm.dbg.declare</span></tt>, so we are transitioning away from it,
+and we plan to deprecate it in future LLVM releases.</p>
+</div>
+<div class="section" id="llvm-dbg-value">
+<h4><a class="toc-backref" href="#id16"><tt class="docutils literal"><span class="pre">llvm.dbg.value</span></tt></a><a class="headerlink" href="#llvm-dbg-value" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="kt">void</span> <span class="vg">@llvm.dbg.value</span><span class="p">(</span><span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">,</span> <span class="kt">metadata</span><span class="p">)</span>
+</pre></div>
+</div>
+<p>This intrinsic provides information when a user source variable is set to a new
+value. The first argument is the new value (wrapped as metadata). The second
+argument is a <a class="reference external" href="LangRef.html#dilocalvariable">local variable</a> containing a
+description of the variable. The third argument is a <a class="reference external" href="LangRef.html#diexpression">complex expression</a>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="object-lifetimes-and-scoping">
+<h2><a class="toc-backref" href="#id17">Object lifetimes and scoping</a><a class="headerlink" href="#object-lifetimes-and-scoping" title="Permalink to this headline">¶</a></h2>
+<p>In many languages, the local variables in functions can have their lifetimes or
+scopes limited to a subset of a function. In the C family of languages, for
+example, variables are only live (readable and writable) within the source
+block that they are defined in. In functional languages, values are only
+readable after they have been defined. Though this is a very obvious concept,
+it is non-trivial to model in LLVM, because it has no notion of scoping in this
+sense, and does not want to be tied to a language’s scoping rules.</p>
+<p>In order to handle this, the LLVM debug format uses the metadata attached to
+llvm instructions to encode line number and scoping information. Consider the
+following C fragment, for example:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="mf">1.</span> <span class="kt">void</span> <span class="n">foo</span><span class="p">()</span> <span class="p">{</span>
+<span class="mf">2.</span> <span class="kt">int</span> <span class="n">X</span> <span class="o">=</span> <span class="mi">21</span><span class="p">;</span>
+<span class="mf">3.</span> <span class="kt">int</span> <span class="n">Y</span> <span class="o">=</span> <span class="mi">22</span><span class="p">;</span>
+<span class="mf">4.</span> <span class="p">{</span>
+<span class="mf">5.</span> <span class="kt">int</span> <span class="n">Z</span> <span class="o">=</span> <span class="mi">23</span><span class="p">;</span>
+<span class="mf">6.</span> <span class="n">Z</span> <span class="o">=</span> <span class="n">X</span><span class="p">;</span>
+<span class="mf">7.</span> <span class="p">}</span>
+<span class="mf">8.</span> <span class="n">X</span> <span class="o">=</span> <span class="n">Y</span><span class="p">;</span>
+<span class="mf">9.</span> <span class="p">}</span>
+</pre></div>
+</div>
+<p>Compiled to LLVM, this function would be represented like this:</p>
+<div class="highlight-text"><div class="highlight"><pre>; Function Attrs: nounwind ssp uwtable
+define void @foo() #0 !dbg !4 {
+entry:
+ %X = alloca i32, align 4
+ %Y = alloca i32, align 4
+ %Z = alloca i32, align 4
+ call void @llvm.dbg.declare(metadata i32* %X, metadata !11, metadata !13), !dbg !14
+ store i32 21, i32* %X, align 4, !dbg !14
+ call void @llvm.dbg.declare(metadata i32* %Y, metadata !15, metadata !13), !dbg !16
+ store i32 22, i32* %Y, align 4, !dbg !16
+ call void @llvm.dbg.declare(metadata i32* %Z, metadata !17, metadata !13), !dbg !19
+ store i32 23, i32* %Z, align 4, !dbg !19
+ %0 = load i32, i32* %X, align 4, !dbg !20
+ store i32 %0, i32* %Z, align 4, !dbg !21
+ %1 = load i32, i32* %Y, align 4, !dbg !22
+ store i32 %1, i32* %X, align 4, !dbg !23
+ ret void, !dbg !24
+}
+
+; Function Attrs: nounwind readnone
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+attributes #0 = { nounwind ssp uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
+attributes #1 = { nounwind readnone }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!7, !8, !9}
+!llvm.ident = !{!10}
+
+!0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 3.7.0 (trunk 231150) (llvm/trunk 231154)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, retainedTypes: !2, subprograms: !3, globals: !2, imports: !2)
+!1 = !DIFile(filename: "/dev/stdin", directory: "/Users/dexonsmith/data/llvm/debug-info")
+!2 = !{}
+!3 = !{!4}
+!4 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 1, type: !5, isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: false, variables: !2)
+!5 = !DISubroutineType(types: !6)
+!6 = !{null}
+!7 = !{i32 2, !"Dwarf Version", i32 2}
+!8 = !{i32 2, !"Debug Info Version", i32 3}
+!9 = !{i32 1, !"PIC Level", i32 2}
+!10 = !{!"clang version 3.7.0 (trunk 231150) (llvm/trunk 231154)"}
+!11 = !DILocalVariable(name: "X", scope: !4, file: !1, line: 2, type: !12)
+!12 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!13 = !DIExpression()
+!14 = !DILocation(line: 2, column: 9, scope: !4)
+!15 = !DILocalVariable(name: "Y", scope: !4, file: !1, line: 3, type: !12)
+!16 = !DILocation(line: 3, column: 9, scope: !4)
+!17 = !DILocalVariable(name: "Z", scope: !18, file: !1, line: 5, type: !12)
+!18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 4, column: 5)
+!19 = !DILocation(line: 5, column: 11, scope: !18)
+!20 = !DILocation(line: 6, column: 11, scope: !18)
+!21 = !DILocation(line: 6, column: 9, scope: !18)
+!22 = !DILocation(line: 8, column: 9, scope: !4)
+!23 = !DILocation(line: 8, column: 7, scope: !4)
+!24 = !DILocation(line: 9, column: 3, scope: !4)
+</pre></div>
+</div>
+<p>This example illustrates a few important details about LLVM debugging
+information. In particular, it shows how the <tt class="docutils literal"><span class="pre">llvm.dbg.declare</span></tt> intrinsic and
+location information, which are attached to an instruction, are applied
+together to allow a debugger to analyze the relationship between statements,
+variable definitions, and the code used to implement the function.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">call</span> <span class="kt">void</span> <span class="vg">@llvm.dbg.declare</span><span class="p">(</span><span class="kt">metadata</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%X</span><span class="p">,</span> <span class="kt">metadata</span> <span class="nv-Anonymous">!11</span><span class="p">,</span> <span class="kt">metadata</span> <span class="nv-Anonymous">!13</span><span class="p">),</span> <span class="nv">!dbg</span> <span class="nv-Anonymous">!14</span>
+ <span class="c">; [debug line = 2:7] [debug variable = X]</span>
+</pre></div>
+</div>
+<p>The first intrinsic <tt class="docutils literal"><span class="pre">%llvm.dbg.declare</span></tt> encodes debugging information for the
+variable <tt class="docutils literal"><span class="pre">X</span></tt>. The metadata <tt class="docutils literal"><span class="pre">!dbg</span> <span class="pre">!14</span></tt> attached to the intrinsic provides
+scope information for the variable <tt class="docutils literal"><span class="pre">X</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>!14 = !DILocation(line: 2, column: 9, scope: !4)
+!4 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 1, type: !5,
+ isLocal: false, isDefinition: true, scopeLine: 1,
+ isOptimized: false, variables: !2)
+</pre></div>
+</div>
+<p>Here <tt class="docutils literal"><span class="pre">!14</span></tt> is metadata providing <a class="reference external" href="LangRef.html#dilocation">location information</a>. In this example, scope is encoded by <tt class="docutils literal"><span class="pre">!4</span></tt>, a
+<a class="reference external" href="LangRef.html#disubprogram">subprogram descriptor</a>. This way the location
+information attached to the intrinsics indicates that the variable <tt class="docutils literal"><span class="pre">X</span></tt> is
+declared at line number 2 at a function level scope in function <tt class="docutils literal"><span class="pre">foo</span></tt>.</p>
+<p>Now lets take another example.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">call</span> <span class="kt">void</span> <span class="vg">@llvm.dbg.declare</span><span class="p">(</span><span class="kt">metadata</span> <span class="k">i32</span><span class="p">*</span> <span class="nv">%Z</span><span class="p">,</span> <span class="kt">metadata</span> <span class="nv-Anonymous">!17</span><span class="p">,</span> <span class="kt">metadata</span> <span class="nv-Anonymous">!13</span><span class="p">),</span> <span class="nv">!dbg</span> <span class="nv-Anonymous">!19</span>
+ <span class="c">; [debug line = 5:9] [debug variable = Z]</span>
+</pre></div>
+</div>
+<p>The third intrinsic <tt class="docutils literal"><span class="pre">%llvm.dbg.declare</span></tt> encodes debugging information for
+variable <tt class="docutils literal"><span class="pre">Z</span></tt>. The metadata <tt class="docutils literal"><span class="pre">!dbg</span> <span class="pre">!19</span></tt> attached to the intrinsic provides
+scope information for the variable <tt class="docutils literal"><span class="pre">Z</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>!18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 4, column: 5)
+!19 = !DILocation(line: 5, column: 11, scope: !18)
+</pre></div>
+</div>
+<p>Here <tt class="docutils literal"><span class="pre">!19</span></tt> indicates that <tt class="docutils literal"><span class="pre">Z</span></tt> is declared at line number 5 and column
+number 0 inside of lexical scope <tt class="docutils literal"><span class="pre">!18</span></tt>. The lexical scope itself resides
+inside of subprogram <tt class="docutils literal"><span class="pre">!4</span></tt> described above.</p>
+<p>The scope information attached with each instruction provides a straightforward
+way to find instructions covered by a scope.</p>
+</div>
+<div class="section" id="c-c-front-end-specific-debug-information">
+<span id="ccxx-frontend"></span><h2><a class="toc-backref" href="#id18">C/C++ front-end specific debug information</a><a class="headerlink" href="#c-c-front-end-specific-debug-information" title="Permalink to this headline">¶</a></h2>
+<p>The C and C++ front-ends represent information about the program in a format
+that is effectively identical to <a class="reference external" href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3.0</a> in terms of information
+content. This allows code generators to trivially support native debuggers by
+generating standard dwarf information, and contains enough information for
+non-dwarf targets to translate it as needed.</p>
+<p>This section describes the forms used to represent C and C++ programs. Other
+languages could pattern themselves after this (which itself is tuned to
+representing programs in the same way that DWARF 3 does), or they could choose
+to provide completely different forms if they don’t fit into the DWARF model.
+As support for debugging information gets added to the various LLVM
+source-language front-ends, the information used should be documented here.</p>
+<p>The following sections provide examples of a few C/C++ constructs and the debug
+information that would best describe those constructs. The canonical
+references are the <tt class="docutils literal"><span class="pre">DIDescriptor</span></tt> classes defined in
+<tt class="docutils literal"><span class="pre">include/llvm/IR/DebugInfo.h</span></tt> and the implementations of the helper functions
+in <tt class="docutils literal"><span class="pre">lib/IR/DIBuilder.cpp</span></tt>.</p>
+<div class="section" id="c-c-source-file-information">
+<h3><a class="toc-backref" href="#id19">C/C++ source file information</a><a class="headerlink" href="#c-c-source-file-information" title="Permalink to this headline">¶</a></h3>
+<p><tt class="docutils literal"><span class="pre">llvm::Instruction</span></tt> provides easy access to metadata attached with an
+instruction. One can extract line number information encoded in LLVM IR using
+<tt class="docutils literal"><span class="pre">Instruction::getDebugLoc()</span></tt> and <tt class="docutils literal"><span class="pre">DILocation::getLine()</span></tt>.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">if</span> <span class="p">(</span><span class="n">DILocation</span> <span class="o">*</span><span class="n">Loc</span> <span class="o">=</span> <span class="n">I</span><span class="o">-></span><span class="n">getDebugLoc</span><span class="p">())</span> <span class="p">{</span> <span class="c1">// Here I is an LLVM instruction</span>
+ <span class="kt">unsigned</span> <span class="n">Line</span> <span class="o">=</span> <span class="n">Loc</span><span class="o">-></span><span class="n">getLine</span><span class="p">();</span>
+ <span class="n">StringRef</span> <span class="n">File</span> <span class="o">=</span> <span class="n">Loc</span><span class="o">-></span><span class="n">getFilename</span><span class="p">();</span>
+ <span class="n">StringRef</span> <span class="n">Dir</span> <span class="o">=</span> <span class="n">Loc</span><span class="o">-></span><span class="n">getDirectory</span><span class="p">();</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="c-c-global-variable-information">
+<h3><a class="toc-backref" href="#id20">C/C++ global variable information</a><a class="headerlink" href="#c-c-global-variable-information" title="Permalink to this headline">¶</a></h3>
+<p>Given an integer global variable declared as follows:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="n">_Alignas</span><span class="p">(</span><span class="mi">8</span><span class="p">)</span> <span class="kt">int</span> <span class="n">MyGlobal</span> <span class="o">=</span> <span class="mi">100</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="highlight-text"><div class="highlight"><pre>;;
+;; Define the global itself.
+;;
+ at MyGlobal = global i32 100, align 8, !dbg !0
+
+;;
+;; List of debug info of globals
+;;
+!llvm.dbg.cu = !{!1}
+
+;; Some unrelated metadata.
+!llvm.module.flags = !{!6, !7}
+!llvm.ident = !{!8}
+
+;; Define the global variable itself
+!0 = distinct !DIGlobalVariable(name: "MyGlobal", scope: !1, file: !2, line: 1, type: !5, isLocal: false, isDefinition: true, align: 64)
+
+;; Define the compile unit.
+!1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2,
+ producer: "clang version 4.0.0 (http://llvm.org/git/clang.git ae4deadbea242e8ea517eef662c30443f75bd086) (http://llvm.org/git/llvm.git 818b4c1539df3e51dc7e62c89ead4abfd348827d)",
+ isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug,
+ enums: !3, globals: !4)
+
+;;
+;; Define the file
+;;
+!2 = !DIFile(filename: "/dev/stdin",
+ directory: "/Users/dexonsmith/data/llvm/debug-info")
+
+;; An empty array.
+!3 = !{}
+
+;; The Array of Global Variables
+!4 = !{!0}
+
+;;
+;; Define the type
+;;
+!5 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+
+;; Dwarf version to output.
+!6 = !{i32 2, !"Dwarf Version", i32 4}
+
+;; Debug info schema version.
+!7 = !{i32 2, !"Debug Info Version", i32 3}
+
+;; Compiler identification
+!8 = !{!"clang version 4.0.0 (http://llvm.org/git/clang.git ae4deadbea242e8ea517eef662c30443f75bd086) (http://llvm.org/git/llvm.git 818b4c1539df3e51dc7e62c89ead4abfd348827d)"}
+</pre></div>
+</div>
+<p>The align value in DIGlobalVariable description specifies variable alignment in
+case it was forced by C11 _Alignas(), C++11 alignas() keywords or compiler
+attribute __attribute__((aligned ())). In other case (when this field is missing)
+alignment is considered default. This is used when producing DWARF output
+for DW_AT_alignment value.</p>
+</div>
+<div class="section" id="c-c-function-information">
+<h3><a class="toc-backref" href="#id21">C/C++ function information</a><a class="headerlink" href="#c-c-function-information" title="Permalink to this headline">¶</a></h3>
+<p>Given a function declared as follows:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="kt">int</span> <span class="nf">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="k">return</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="highlight-text"><div class="highlight"><pre>;;
+;; Define the anchor for subprograms.
+;;
+!4 = !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type: !5,
+ isLocal: false, isDefinition: true, scopeLine: 1,
+ flags: DIFlagPrototyped, isOptimized: false,
+ variables: !2)
+
+;;
+;; Define the subprogram itself.
+;;
+define i32 @main(i32 %argc, i8** %argv) !dbg !4 {
+...
+}
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="id4">
+<h2><a class="toc-backref" href="#id22">Debugging information format</a><a class="headerlink" href="#id4" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="debugging-information-extension-for-objective-c-properties">
+<h3><a class="toc-backref" href="#id23">Debugging Information Extension for Objective C Properties</a><a class="headerlink" href="#debugging-information-extension-for-objective-c-properties" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id5">
+<h4><a class="toc-backref" href="#id24">Introduction</a><a class="headerlink" href="#id5" title="Permalink to this headline">¶</a></h4>
+<p>Objective C provides a simpler way to declare and define accessor methods using
+declared properties. The language provides features to declare a property and
+to let compiler synthesize accessor methods.</p>
+<p>The debugger lets developer inspect Objective C interfaces and their instance
+variables and class variables. However, the debugger does not know anything
+about the properties defined in Objective C interfaces. The debugger consumes
+information generated by compiler in DWARF format. The format does not support
+encoding of Objective C properties. This proposal describes DWARF extensions to
+encode Objective C properties, which the debugger can use to let developers
+inspect Objective C properties.</p>
+</div>
+<div class="section" id="proposal">
+<h4><a class="toc-backref" href="#id25">Proposal</a><a class="headerlink" href="#proposal" title="Permalink to this headline">¶</a></h4>
+<p>Objective C properties exist separately from class members. A property can be
+defined only by “setter” and “getter” selectors, and be calculated anew on each
+access. Or a property can just be a direct access to some declared ivar.
+Finally it can have an ivar “automatically synthesized” for it by the compiler,
+in which case the property can be referred to in user code directly using the
+standard C dereference syntax as well as through the property “dot” syntax, but
+there is no entry in the <tt class="docutils literal"><span class="pre">@interface</span></tt> declaration corresponding to this ivar.</p>
+<p>To facilitate debugging, these properties we will add a new DWARF TAG into the
+<tt class="docutils literal"><span class="pre">DW_TAG_structure_type</span></tt> definition for the class to hold the description of a
+given property, and a set of DWARF attributes that provide said description.
+The property tag will also contain the name and declared type of the property.</p>
+<p>If there is a related ivar, there will also be a DWARF property attribute placed
+in the <tt class="docutils literal"><span class="pre">DW_TAG_member</span></tt> DIE for that ivar referring back to the property TAG
+for that property. And in the case where the compiler synthesizes the ivar
+directly, the compiler is expected to generate a <tt class="docutils literal"><span class="pre">DW_TAG_member</span></tt> for that
+ivar (with the <tt class="docutils literal"><span class="pre">DW_AT_artificial</span></tt> set to 1), whose name will be the name used
+to access this ivar directly in code, and with the property attribute pointing
+back to the property it is backing.</p>
+<p>The following examples will serve as illustration for our discussion:</p>
+<div class="highlight-objc"><div class="highlight"><pre><span class="k">@interface</span> <span class="nc">I1</span> <span class="p">{</span>
+ <span class="kt">int</span> <span class="n">n2</span><span class="p">;</span>
+<span class="p">}</span>
+
+<span class="k">@property</span> <span class="kt">int</span> <span class="n">p1</span><span class="p">;</span>
+<span class="k">@property</span> <span class="kt">int</span> <span class="n">p2</span><span class="p">;</span>
+<span class="k">@end</span>
+
+<span class="k">@implementation</span> <span class="nc">I1</span>
+<span class="k">@synthesize</span> <span class="n">p1</span><span class="p">;</span>
+<span class="k">@synthesize</span> <span class="n">p2</span> <span class="o">=</span> <span class="n">n2</span><span class="p">;</span>
+<span class="k">@end</span>
+</pre></div>
+</div>
+<p>This produces the following DWARF (this is a “pseudo dwarfdump” output):</p>
+<div class="highlight-none"><div class="highlight"><pre>0x00000100: TAG_structure_type [7] *
+ AT_APPLE_runtime_class( 0x10 )
+ AT_name( "I1" )
+ AT_decl_file( "Objc_Property.m" )
+ AT_decl_line( 3 )
+
+0x00000110 TAG_APPLE_property
+ AT_name ( "p1" )
+ AT_type ( {0x00000150} ( int ) )
+
+0x00000120: TAG_APPLE_property
+ AT_name ( "p2" )
+ AT_type ( {0x00000150} ( int ) )
+
+0x00000130: TAG_member [8]
+ AT_name( "_p1" )
+ AT_APPLE_property ( {0x00000110} "p1" )
+ AT_type( {0x00000150} ( int ) )
+ AT_artificial ( 0x1 )
+
+0x00000140: TAG_member [8]
+ AT_name( "n2" )
+ AT_APPLE_property ( {0x00000120} "p2" )
+ AT_type( {0x00000150} ( int ) )
+
+0x00000150: AT_type( ( int ) )
+</pre></div>
+</div>
+<p>Note, the current convention is that the name of the ivar for an
+auto-synthesized property is the name of the property from which it derives
+with an underscore prepended, as is shown in the example. But we actually
+don’t need to know this convention, since we are given the name of the ivar
+directly.</p>
+<p>Also, it is common practice in ObjC to have different property declarations in
+the @interface and @implementation - e.g. to provide a read-only property in
+the interface,and a read-write interface in the implementation. In that case,
+the compiler should emit whichever property declaration will be in force in the
+current translation unit.</p>
+<p>Developers can decorate a property with attributes which are encoded using
+<tt class="docutils literal"><span class="pre">DW_AT_APPLE_property_attribute</span></tt>.</p>
+<div class="highlight-objc"><div class="highlight"><pre><span class="k">@property</span> <span class="p">(</span><span class="n">readonly</span><span class="p">,</span> <span class="n">nonatomic</span><span class="p">)</span> <span class="kt">int</span> <span class="n">pr</span><span class="p">;</span>
+</pre></div>
+</div>
+<div class="highlight-none"><div class="highlight"><pre>TAG_APPLE_property [8]
+ AT_name( "pr" )
+ AT_type ( {0x00000147} (int) )
+ AT_APPLE_property_attribute (DW_APPLE_PROPERTY_readonly, DW_APPLE_PROPERTY_nonatomic)
+</pre></div>
+</div>
+<p>The setter and getter method names are attached to the property using
+<tt class="docutils literal"><span class="pre">DW_AT_APPLE_property_setter</span></tt> and <tt class="docutils literal"><span class="pre">DW_AT_APPLE_property_getter</span></tt> attributes.</p>
+<div class="highlight-objc"><div class="highlight"><pre><span class="k">@interface</span> <span class="nc">I1</span>
+<span class="k">@property</span> <span class="p">(</span><span class="n">setter</span><span class="o">=</span><span class="nl">myOwnP3Setter:</span><span class="p">)</span> <span class="kt">int</span> <span class="n">p3</span><span class="p">;</span>
+<span class="o">-</span><span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="nl">myOwnP3Setter:</span><span class="p">(</span><span class="kt">int</span><span class="p">)</span><span class="n">a</span><span class="p">;</span>
+<span class="k">@end</span>
+
+<span class="k">@implementation</span> <span class="nc">I1</span>
+<span class="k">@synthesize</span> <span class="n">p3</span><span class="p">;</span>
+<span class="o">-</span><span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="nl">myOwnP3Setter:</span><span class="p">(</span><span class="kt">int</span><span class="p">)</span><span class="n">a</span><span class="p">{</span> <span class="p">}</span>
+<span class="k">@end</span>
+</pre></div>
+</div>
+<p>The DWARF for this would be:</p>
+<div class="highlight-none"><div class="highlight"><pre>0x000003bd: TAG_structure_type [7] *
+ AT_APPLE_runtime_class( 0x10 )
+ AT_name( "I1" )
+ AT_decl_file( "Objc_Property.m" )
+ AT_decl_line( 3 )
+
+0x000003cd TAG_APPLE_property
+ AT_name ( "p3" )
+ AT_APPLE_property_setter ( "myOwnP3Setter:" )
+ AT_type( {0x00000147} ( int ) )
+
+0x000003f3: TAG_member [8]
+ AT_name( "_p3" )
+ AT_type ( {0x00000147} ( int ) )
+ AT_APPLE_property ( {0x000003cd} )
+ AT_artificial ( 0x1 )
+</pre></div>
+</div>
+</div>
+<div class="section" id="new-dwarf-tags">
+<h4><a class="toc-backref" href="#id26">New DWARF Tags</a><a class="headerlink" href="#new-dwarf-tags" title="Permalink to this headline">¶</a></h4>
+<table border="1" class="docutils">
+<colgroup>
+<col width="74%" />
+<col width="26%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">TAG</th>
+<th class="head">Value</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>DW_TAG_APPLE_property</td>
+<td>0x4200</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="new-dwarf-attributes">
+<h4><a class="toc-backref" href="#id27">New DWARF Attributes</a><a class="headerlink" href="#new-dwarf-attributes" title="Permalink to this headline">¶</a></h4>
+<table border="1" class="docutils">
+<colgroup>
+<col width="63%" />
+<col width="16%" />
+<col width="22%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Attribute</th>
+<th class="head">Value</th>
+<th class="head">Classes</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>DW_AT_APPLE_property</td>
+<td>0x3fed</td>
+<td>Reference</td>
+</tr>
+<tr class="row-odd"><td>DW_AT_APPLE_property_getter</td>
+<td>0x3fe9</td>
+<td>String</td>
+</tr>
+<tr class="row-even"><td>DW_AT_APPLE_property_setter</td>
+<td>0x3fea</td>
+<td>String</td>
+</tr>
+<tr class="row-odd"><td>DW_AT_APPLE_property_attribute</td>
+<td>0x3feb</td>
+<td>Constant</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="new-dwarf-constants">
+<h4><a class="toc-backref" href="#id28">New DWARF Constants</a><a class="headerlink" href="#new-dwarf-constants" title="Permalink to this headline">¶</a></h4>
+<table border="1" class="docutils">
+<colgroup>
+<col width="84%" />
+<col width="16%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Name</th>
+<th class="head">Value</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>DW_APPLE_PROPERTY_readonly</td>
+<td>0x01</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_getter</td>
+<td>0x02</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_assign</td>
+<td>0x04</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_readwrite</td>
+<td>0x08</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_retain</td>
+<td>0x10</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_copy</td>
+<td>0x20</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_nonatomic</td>
+<td>0x40</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_setter</td>
+<td>0x80</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_atomic</td>
+<td>0x100</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_weak</td>
+<td>0x200</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_strong</td>
+<td>0x400</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_unsafe_unretained</td>
+<td>0x800</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_nullability</td>
+<td>0x1000</td>
+</tr>
+<tr class="row-odd"><td>DW_APPLE_PROPERTY_null_resettable</td>
+<td>0x2000</td>
+</tr>
+<tr class="row-even"><td>DW_APPLE_PROPERTY_class</td>
+<td>0x4000</td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="section" id="name-accelerator-tables">
+<h3><a class="toc-backref" href="#id29">Name Accelerator Tables</a><a class="headerlink" href="#name-accelerator-tables" title="Permalink to this headline">¶</a></h3>
+<div class="section" id="id6">
+<h4><a class="toc-backref" href="#id30">Introduction</a><a class="headerlink" href="#id6" title="Permalink to this headline">¶</a></h4>
+<p>The “<tt class="docutils literal"><span class="pre">.debug_pubnames</span></tt>” and “<tt class="docutils literal"><span class="pre">.debug_pubtypes</span></tt>” formats are not what a
+debugger needs. The “<tt class="docutils literal"><span class="pre">pub</span></tt>” in the section name indicates that the entries
+in the table are publicly visible names only. This means no static or hidden
+functions show up in the “<tt class="docutils literal"><span class="pre">.debug_pubnames</span></tt>”. No static variables or private
+class variables are in the “<tt class="docutils literal"><span class="pre">.debug_pubtypes</span></tt>”. Many compilers add different
+things to these tables, so we can’t rely upon the contents between gcc, icc, or
+clang.</p>
+<p>The typical query given by users tends not to match up with the contents of
+these tables. For example, the DWARF spec states that “In the case of the name
+of a function member or static data member of a C++ structure, class or union,
+the name presented in the “<tt class="docutils literal"><span class="pre">.debug_pubnames</span></tt>” section is not the simple name
+given by the <tt class="docutils literal"><span class="pre">DW_AT_name</span> <span class="pre">attribute</span></tt> of the referenced debugging information
+entry, but rather the fully qualified name of the data or function member.”
+So the only names in these tables for complex C++ entries is a fully
+qualified name. Debugger users tend not to enter their search strings as
+“<tt class="docutils literal"><span class="pre">a::b::c(int,const</span> <span class="pre">Foo&)</span> <span class="pre">const</span></tt>”, but rather as “<tt class="docutils literal"><span class="pre">c</span></tt>”, “<tt class="docutils literal"><span class="pre">b::c</span></tt>” , or
+“<tt class="docutils literal"><span class="pre">a::b::c</span></tt>”. So the name entered in the name table must be demangled in
+order to chop it up appropriately and additional names must be manually entered
+into the table to make it effective as a name lookup table for debuggers to
+use.</p>
+<p>All debuggers currently ignore the “<tt class="docutils literal"><span class="pre">.debug_pubnames</span></tt>” table as a result of
+its inconsistent and useless public-only name content making it a waste of
+space in the object file. These tables, when they are written to disk, are not
+sorted in any way, leaving every debugger to do its own parsing and sorting.
+These tables also include an inlined copy of the string values in the table
+itself making the tables much larger than they need to be on disk, especially
+for large C++ programs.</p>
+<p>Can’t we just fix the sections by adding all of the names we need to this
+table? No, because that is not what the tables are defined to contain and we
+won’t know the difference between the old bad tables and the new good tables.
+At best we could make our own renamed sections that contain all of the data we
+need.</p>
+<p>These tables are also insufficient for what a debugger like LLDB needs. LLDB
+uses clang for its expression parsing where LLDB acts as a PCH. LLDB is then
+often asked to look for type “<tt class="docutils literal"><span class="pre">foo</span></tt>” or namespace “<tt class="docutils literal"><span class="pre">bar</span></tt>”, or list items in
+namespace “<tt class="docutils literal"><span class="pre">baz</span></tt>”. Namespaces are not included in the pubnames or pubtypes
+tables. Since clang asks a lot of questions when it is parsing an expression,
+we need to be very fast when looking up names, as it happens a lot. Having new
+accelerator tables that are optimized for very quick lookups will benefit this
+type of debugging experience greatly.</p>
+<p>We would like to generate name lookup tables that can be mapped into memory
+from disk, and used as is, with little or no up-front parsing. We would also
+be able to control the exact content of these different tables so they contain
+exactly what we need. The Name Accelerator Tables were designed to fix these
+issues. In order to solve these issues we need to:</p>
+<ul class="simple">
+<li>Have a format that can be mapped into memory from disk and used as is</li>
+<li>Lookups should be very fast</li>
+<li>Extensible table format so these tables can be made by many producers</li>
+<li>Contain all of the names needed for typical lookups out of the box</li>
+<li>Strict rules for the contents of tables</li>
+</ul>
+<p>Table size is important and the accelerator table format should allow the reuse
+of strings from common string tables so the strings for the names are not
+duplicated. We also want to make sure the table is ready to be used as-is by
+simply mapping the table into memory with minimal header parsing.</p>
+<p>The name lookups need to be fast and optimized for the kinds of lookups that
+debuggers tend to do. Optimally we would like to touch as few parts of the
+mapped table as possible when doing a name lookup and be able to quickly find
+the name entry we are looking for, or discover there are no matches. In the
+case of debuggers we optimized for lookups that fail most of the time.</p>
+<p>Each table that is defined should have strict rules on exactly what is in the
+accelerator tables and documented so clients can rely on the content.</p>
+</div>
+<div class="section" id="hash-tables">
+<h4><a class="toc-backref" href="#id31">Hash Tables</a><a class="headerlink" href="#hash-tables" title="Permalink to this headline">¶</a></h4>
+<div class="section" id="standard-hash-tables">
+<h5><a class="toc-backref" href="#id32">Standard Hash Tables</a><a class="headerlink" href="#standard-hash-tables" title="Permalink to this headline">¶</a></h5>
+<p>Typical hash tables have a header, buckets, and each bucket points to the
+bucket contents:</p>
+<div class="highlight-none"><div class="highlight"><pre>.------------.
+| HEADER |
+|------------|
+| BUCKETS |
+|------------|
+| DATA |
+`------------'
+</pre></div>
+</div>
+<p>The BUCKETS are an array of offsets to DATA for each hash:</p>
+<div class="highlight-none"><div class="highlight"><pre>.------------.
+| 0x00001000 | BUCKETS[0]
+| 0x00002000 | BUCKETS[1]
+| 0x00002200 | BUCKETS[2]
+| 0x000034f0 | BUCKETS[3]
+| | ...
+| 0xXXXXXXXX | BUCKETS[n_buckets]
+'------------'
+</pre></div>
+</div>
+<p>So for <tt class="docutils literal"><span class="pre">bucket[3]</span></tt> in the example above, we have an offset into the table
+0x000034f0 which points to a chain of entries for the bucket. Each bucket must
+contain a next pointer, full 32 bit hash value, the string itself, and the data
+for the current string value.</p>
+<div class="highlight-none"><div class="highlight"><pre> .------------.
+0x000034f0: | 0x00003500 | next pointer
+ | 0x12345678 | 32 bit hash
+ | "erase" | string value
+ | data[n] | HashData for this bucket
+ |------------|
+0x00003500: | 0x00003550 | next pointer
+ | 0x29273623 | 32 bit hash
+ | "dump" | string value
+ | data[n] | HashData for this bucket
+ |------------|
+0x00003550: | 0x00000000 | next pointer
+ | 0x82638293 | 32 bit hash
+ | "main" | string value
+ | data[n] | HashData for this bucket
+ `------------'
+</pre></div>
+</div>
+<p>The problem with this layout for debuggers is that we need to optimize for the
+negative lookup case where the symbol we’re searching for is not present. So
+if we were to lookup “<tt class="docutils literal"><span class="pre">printf</span></tt>” in the table above, we would make a 32-bit
+hash for “<tt class="docutils literal"><span class="pre">printf</span></tt>”, it might match <tt class="docutils literal"><span class="pre">bucket[3]</span></tt>. We would need to go to
+the offset 0x000034f0 and start looking to see if our 32 bit hash matches. To
+do so, we need to read the next pointer, then read the hash, compare it, and
+skip to the next bucket. Each time we are skipping many bytes in memory and
+touching new pages just to do the compare on the full 32 bit hash. All of
+these accesses then tell us that we didn’t have a match.</p>
+</div>
+<div class="section" id="name-hash-tables">
+<h5><a class="toc-backref" href="#id33">Name Hash Tables</a><a class="headerlink" href="#name-hash-tables" title="Permalink to this headline">¶</a></h5>
+<p>To solve the issues mentioned above we have structured the hash tables a bit
+differently: a header, buckets, an array of all unique 32 bit hash values,
+followed by an array of hash value data offsets, one for each hash value, then
+the data for all hash values:</p>
+<div class="highlight-none"><div class="highlight"><pre>.-------------.
+| HEADER |
+|-------------|
+| BUCKETS |
+|-------------|
+| HASHES |
+|-------------|
+| OFFSETS |
+|-------------|
+| DATA |
+`-------------'
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">BUCKETS</span></tt> in the name tables are an index into the <tt class="docutils literal"><span class="pre">HASHES</span></tt> array. By
+making all of the full 32 bit hash values contiguous in memory, we allow
+ourselves to efficiently check for a match while touching as little memory as
+possible. Most often checking the 32 bit hash values is as far as the lookup
+goes. If it does match, it usually is a match with no collisions. So for a
+table with “<tt class="docutils literal"><span class="pre">n_buckets</span></tt>” buckets, and “<tt class="docutils literal"><span class="pre">n_hashes</span></tt>” unique 32 bit hash
+values, we can clarify the contents of the <tt class="docutils literal"><span class="pre">BUCKETS</span></tt>, <tt class="docutils literal"><span class="pre">HASHES</span></tt> and
+<tt class="docutils literal"><span class="pre">OFFSETS</span></tt> as:</p>
+<div class="highlight-none"><div class="highlight"><pre>.-------------------------.
+| HEADER.magic | uint32_t
+| HEADER.version | uint16_t
+| HEADER.hash_function | uint16_t
+| HEADER.bucket_count | uint32_t
+| HEADER.hashes_count | uint32_t
+| HEADER.header_data_len | uint32_t
+| HEADER_DATA | HeaderData
+|-------------------------|
+| BUCKETS | uint32_t[n_buckets] // 32 bit hash indexes
+|-------------------------|
+| HASHES | uint32_t[n_hashes] // 32 bit hash values
+|-------------------------|
+| OFFSETS | uint32_t[n_hashes] // 32 bit offsets to hash value data
+|-------------------------|
+| ALL HASH DATA |
+`-------------------------'
+</pre></div>
+</div>
+<p>So taking the exact same data from the standard hash example above we end up
+with:</p>
+<div class="highlight-none"><div class="highlight"><pre> .------------.
+ | HEADER |
+ |------------|
+ | 0 | BUCKETS[0]
+ | 2 | BUCKETS[1]
+ | 5 | BUCKETS[2]
+ | 6 | BUCKETS[3]
+ | | ...
+ | ... | BUCKETS[n_buckets]
+ |------------|
+ | 0x........ | HASHES[0]
+ | 0x........ | HASHES[1]
+ | 0x........ | HASHES[2]
+ | 0x........ | HASHES[3]
+ | 0x........ | HASHES[4]
+ | 0x........ | HASHES[5]
+ | 0x12345678 | HASHES[6] hash for BUCKETS[3]
+ | 0x29273623 | HASHES[7] hash for BUCKETS[3]
+ | 0x82638293 | HASHES[8] hash for BUCKETS[3]
+ | 0x........ | HASHES[9]
+ | 0x........ | HASHES[10]
+ | 0x........ | HASHES[11]
+ | 0x........ | HASHES[12]
+ | 0x........ | HASHES[13]
+ | 0x........ | HASHES[n_hashes]
+ |------------|
+ | 0x........ | OFFSETS[0]
+ | 0x........ | OFFSETS[1]
+ | 0x........ | OFFSETS[2]
+ | 0x........ | OFFSETS[3]
+ | 0x........ | OFFSETS[4]
+ | 0x........ | OFFSETS[5]
+ | 0x000034f0 | OFFSETS[6] offset for BUCKETS[3]
+ | 0x00003500 | OFFSETS[7] offset for BUCKETS[3]
+ | 0x00003550 | OFFSETS[8] offset for BUCKETS[3]
+ | 0x........ | OFFSETS[9]
+ | 0x........ | OFFSETS[10]
+ | 0x........ | OFFSETS[11]
+ | 0x........ | OFFSETS[12]
+ | 0x........ | OFFSETS[13]
+ | 0x........ | OFFSETS[n_hashes]
+ |------------|
+ | |
+ | |
+ | |
+ | |
+ | |
+ |------------|
+0x000034f0: | 0x00001203 | .debug_str ("erase")
+ | 0x00000004 | A 32 bit array count - number of HashData with name "erase"
+ | 0x........ | HashData[0]
+ | 0x........ | HashData[1]
+ | 0x........ | HashData[2]
+ | 0x........ | HashData[3]
+ | 0x00000000 | String offset into .debug_str (terminate data for hash)
+ |------------|
+0x00003500: | 0x00001203 | String offset into .debug_str ("collision")
+ | 0x00000002 | A 32 bit array count - number of HashData with name "collision"
+ | 0x........ | HashData[0]
+ | 0x........ | HashData[1]
+ | 0x00001203 | String offset into .debug_str ("dump")
+ | 0x00000003 | A 32 bit array count - number of HashData with name "dump"
+ | 0x........ | HashData[0]
+ | 0x........ | HashData[1]
+ | 0x........ | HashData[2]
+ | 0x00000000 | String offset into .debug_str (terminate data for hash)
+ |------------|
+0x00003550: | 0x00001203 | String offset into .debug_str ("main")
+ | 0x00000009 | A 32 bit array count - number of HashData with name "main"
+ | 0x........ | HashData[0]
+ | 0x........ | HashData[1]
+ | 0x........ | HashData[2]
+ | 0x........ | HashData[3]
+ | 0x........ | HashData[4]
+ | 0x........ | HashData[5]
+ | 0x........ | HashData[6]
+ | 0x........ | HashData[7]
+ | 0x........ | HashData[8]
+ | 0x00000000 | String offset into .debug_str (terminate data for hash)
+ `------------'
+</pre></div>
+</div>
+<p>So we still have all of the same data, we just organize it more efficiently for
+debugger lookup. If we repeat the same “<tt class="docutils literal"><span class="pre">printf</span></tt>” lookup from above, we
+would hash “<tt class="docutils literal"><span class="pre">printf</span></tt>” and find it matches <tt class="docutils literal"><span class="pre">BUCKETS[3]</span></tt> by taking the 32 bit
+hash value and modulo it by <tt class="docutils literal"><span class="pre">n_buckets</span></tt>. <tt class="docutils literal"><span class="pre">BUCKETS[3]</span></tt> contains “6” which
+is the index into the <tt class="docutils literal"><span class="pre">HASHES</span></tt> table. We would then compare any consecutive
+32 bit hashes values in the <tt class="docutils literal"><span class="pre">HASHES</span></tt> array as long as the hashes would be in
+<tt class="docutils literal"><span class="pre">BUCKETS[3]</span></tt>. We do this by verifying that each subsequent hash value modulo
+<tt class="docutils literal"><span class="pre">n_buckets</span></tt> is still 3. In the case of a failed lookup we would access the
+memory for <tt class="docutils literal"><span class="pre">BUCKETS[3]</span></tt>, and then compare a few consecutive 32 bit hashes
+before we know that we have no match. We don’t end up marching through
+multiple words of memory and we really keep the number of processor data cache
+lines being accessed as small as possible.</p>
+<p>The string hash that is used for these lookup tables is the Daniel J.
+Bernstein hash which is also used in the ELF <tt class="docutils literal"><span class="pre">GNU_HASH</span></tt> sections. It is a
+very good hash for all kinds of names in programs with very few hash
+collisions.</p>
+<p>Empty buckets are designated by using an invalid hash index of <tt class="docutils literal"><span class="pre">UINT32_MAX</span></tt>.</p>
+</div>
+</div>
+<div class="section" id="details">
+<h4><a class="toc-backref" href="#id34">Details</a><a class="headerlink" href="#details" title="Permalink to this headline">¶</a></h4>
+<p>These name hash tables are designed to be generic where specializations of the
+table get to define additional data that goes into the header (“<tt class="docutils literal"><span class="pre">HeaderData</span></tt>”),
+how the string value is stored (“<tt class="docutils literal"><span class="pre">KeyType</span></tt>”) and the content of the data for each
+hash value.</p>
+<div class="section" id="header-layout">
+<h5><a class="toc-backref" href="#id35">Header Layout</a><a class="headerlink" href="#header-layout" title="Permalink to this headline">¶</a></h5>
+<p>The header has a fixed part, and the specialized part. The exact format of the
+header is:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">struct</span> <span class="n">Header</span>
+<span class="p">{</span>
+ <span class="kt">uint32_t</span> <span class="n">magic</span><span class="p">;</span> <span class="c1">// 'HASH' magic value to allow endian detection</span>
+ <span class="kt">uint16_t</span> <span class="n">version</span><span class="p">;</span> <span class="c1">// Version number</span>
+ <span class="kt">uint16_t</span> <span class="n">hash_function</span><span class="p">;</span> <span class="c1">// The hash function enumeration that was used</span>
+ <span class="kt">uint32_t</span> <span class="n">bucket_count</span><span class="p">;</span> <span class="c1">// The number of buckets in this hash table</span>
+ <span class="kt">uint32_t</span> <span class="n">hashes_count</span><span class="p">;</span> <span class="c1">// The total number of unique hash values and hash data offsets in this table</span>
+ <span class="kt">uint32_t</span> <span class="n">header_data_len</span><span class="p">;</span> <span class="c1">// The bytes to skip to get to the hash indexes (buckets) for correct alignment</span>
+ <span class="c1">// Specifically the length of the following HeaderData field - this does not</span>
+ <span class="c1">// include the size of the preceding fields</span>
+ <span class="n">HeaderData</span> <span class="n">header_data</span><span class="p">;</span> <span class="c1">// Implementation specific header data</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The header starts with a 32 bit “<tt class="docutils literal"><span class="pre">magic</span></tt>” value which must be <tt class="docutils literal"><span class="pre">'HASH'</span></tt>
+encoded as an ASCII integer. This allows the detection of the start of the
+hash table and also allows the table’s byte order to be determined so the table
+can be correctly extracted. The “<tt class="docutils literal"><span class="pre">magic</span></tt>” value is followed by a 16 bit
+<tt class="docutils literal"><span class="pre">version</span></tt> number which allows the table to be revised and modified in the
+future. The current version number is 1. <tt class="docutils literal"><span class="pre">hash_function</span></tt> is a <tt class="docutils literal"><span class="pre">uint16_t</span></tt>
+enumeration that specifies which hash function was used to produce this table.
+The current values for the hash function enumerations include:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">enum</span> <span class="n">HashFunctionType</span>
+<span class="p">{</span>
+ <span class="n">eHashFunctionDJB</span> <span class="o">=</span> <span class="mi">0u</span><span class="p">,</span> <span class="c1">// Daniel J Bernstein hash function</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">bucket_count</span></tt> is a 32 bit unsigned integer that represents how many buckets
+are in the <tt class="docutils literal"><span class="pre">BUCKETS</span></tt> array. <tt class="docutils literal"><span class="pre">hashes_count</span></tt> is the number of unique 32 bit
+hash values that are in the <tt class="docutils literal"><span class="pre">HASHES</span></tt> array, and is the same number of offsets
+are contained in the <tt class="docutils literal"><span class="pre">OFFSETS</span></tt> array. <tt class="docutils literal"><span class="pre">header_data_len</span></tt> specifies the size
+in bytes of the <tt class="docutils literal"><span class="pre">HeaderData</span></tt> that is filled in by specialized versions of
+this table.</p>
+</div>
+<div class="section" id="fixed-lookup">
+<h5><a class="toc-backref" href="#id36">Fixed Lookup</a><a class="headerlink" href="#fixed-lookup" title="Permalink to this headline">¶</a></h5>
+<p>The header is followed by the buckets, hashes, offsets, and hash value data.</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">struct</span> <span class="n">FixedTable</span>
+<span class="p">{</span>
+ <span class="kt">uint32_t</span> <span class="n">buckets</span><span class="p">[</span><span class="n">Header</span><span class="p">.</span><span class="n">bucket_count</span><span class="p">];</span> <span class="c1">// An array of hash indexes into the "hashes[]" array below</span>
+ <span class="kt">uint32_t</span> <span class="n">hashes</span> <span class="p">[</span><span class="n">Header</span><span class="p">.</span><span class="n">hashes_count</span><span class="p">];</span> <span class="c1">// Every unique 32 bit hash for the entire table is in this table</span>
+ <span class="kt">uint32_t</span> <span class="n">offsets</span><span class="p">[</span><span class="n">Header</span><span class="p">.</span><span class="n">hashes_count</span><span class="p">];</span> <span class="c1">// An offset that corresponds to each item in the "hashes[]" array above</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">buckets</span></tt> is an array of 32 bit indexes into the <tt class="docutils literal"><span class="pre">hashes</span></tt> array. The
+<tt class="docutils literal"><span class="pre">hashes</span></tt> array contains all of the 32 bit hash values for all names in the
+hash table. Each hash in the <tt class="docutils literal"><span class="pre">hashes</span></tt> table has an offset in the <tt class="docutils literal"><span class="pre">offsets</span></tt>
+array that points to the data for the hash value.</p>
+<p>This table setup makes it very easy to repurpose these tables to contain
+different data, while keeping the lookup mechanism the same for all tables.
+This layout also makes it possible to save the table to disk and map it in
+later and do very efficient name lookups with little or no parsing.</p>
+<p>DWARF lookup tables can be implemented in a variety of ways and can store a lot
+of information for each name. We want to make the DWARF tables extensible and
+able to store the data efficiently so we have used some of the DWARF features
+that enable efficient data storage to define exactly what kind of data we store
+for each name.</p>
+<p>The <tt class="docutils literal"><span class="pre">HeaderData</span></tt> contains a definition of the contents of each HashData chunk.
+We might want to store an offset to all of the debug information entries (DIEs)
+for each name. To keep things extensible, we create a list of items, or
+Atoms, that are contained in the data for each name. First comes the type of
+the data in each atom:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">enum</span> <span class="n">AtomType</span>
+<span class="p">{</span>
+ <span class="n">eAtomTypeNULL</span> <span class="o">=</span> <span class="mi">0u</span><span class="p">,</span>
+ <span class="n">eAtomTypeDIEOffset</span> <span class="o">=</span> <span class="mi">1u</span><span class="p">,</span> <span class="c1">// DIE offset, check form for encoding</span>
+ <span class="n">eAtomTypeCUOffset</span> <span class="o">=</span> <span class="mi">2u</span><span class="p">,</span> <span class="c1">// DIE offset of the compiler unit header that contains the item in question</span>
+ <span class="n">eAtomTypeTag</span> <span class="o">=</span> <span class="mi">3u</span><span class="p">,</span> <span class="c1">// DW_TAG_xxx value, should be encoded as DW_FORM_data1 (if no tags exceed 255) or DW_FORM_data2</span>
+ <span class="n">eAtomTypeNameFlags</span> <span class="o">=</span> <span class="mi">4u</span><span class="p">,</span> <span class="c1">// Flags from enum NameFlags</span>
+ <span class="n">eAtomTypeTypeFlags</span> <span class="o">=</span> <span class="mi">5u</span><span class="p">,</span> <span class="c1">// Flags from enum TypeFlags</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The enumeration values and their meanings are:</p>
+<div class="highlight-none"><div class="highlight"><pre>eAtomTypeNULL - a termination atom that specifies the end of the atom list
+eAtomTypeDIEOffset - an offset into the .debug_info section for the DWARF DIE for this name
+eAtomTypeCUOffset - an offset into the .debug_info section for the CU that contains the DIE
+eAtomTypeDIETag - The DW_TAG_XXX enumeration value so you don't have to parse the DWARF to see what it is
+eAtomTypeNameFlags - Flags for functions and global variables (isFunction, isInlined, isExternal...)
+eAtomTypeTypeFlags - Flags for types (isCXXClass, isObjCClass, ...)
+</pre></div>
+</div>
+<p>Then we allow each atom type to define the atom type and how the data for each
+atom type data is encoded:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">struct</span> <span class="n">Atom</span>
+<span class="p">{</span>
+ <span class="kt">uint16_t</span> <span class="n">type</span><span class="p">;</span> <span class="c1">// AtomType enum value</span>
+ <span class="kt">uint16_t</span> <span class="n">form</span><span class="p">;</span> <span class="c1">// DWARF DW_FORM_XXX defines</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The <tt class="docutils literal"><span class="pre">form</span></tt> type above is from the DWARF specification and defines the exact
+encoding of the data for the Atom type. See the DWARF specification for the
+<tt class="docutils literal"><span class="pre">DW_FORM_</span></tt> definitions.</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">struct</span> <span class="n">HeaderData</span>
+<span class="p">{</span>
+ <span class="kt">uint32_t</span> <span class="n">die_offset_base</span><span class="p">;</span>
+ <span class="kt">uint32_t</span> <span class="n">atom_count</span><span class="p">;</span>
+ <span class="n">Atoms</span> <span class="n">atoms</span><span class="p">[</span><span class="n">atom_count0</span><span class="p">];</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">HeaderData</span></tt> defines the base DIE offset that should be added to any atoms
+that are encoded using the <tt class="docutils literal"><span class="pre">DW_FORM_ref1</span></tt>, <tt class="docutils literal"><span class="pre">DW_FORM_ref2</span></tt>,
+<tt class="docutils literal"><span class="pre">DW_FORM_ref4</span></tt>, <tt class="docutils literal"><span class="pre">DW_FORM_ref8</span></tt> or <tt class="docutils literal"><span class="pre">DW_FORM_ref_udata</span></tt>. It also defines
+what is contained in each <tt class="docutils literal"><span class="pre">HashData</span></tt> object – <tt class="docutils literal"><span class="pre">Atom.form</span></tt> tells us how large
+each field will be in the <tt class="docutils literal"><span class="pre">HashData</span></tt> and the <tt class="docutils literal"><span class="pre">Atom.type</span></tt> tells us how this data
+should be interpreted.</p>
+<p>For the current implementations of the “<tt class="docutils literal"><span class="pre">.apple_names</span></tt>” (all functions +
+globals), the “<tt class="docutils literal"><span class="pre">.apple_types</span></tt>” (names of all types that are defined), and
+the “<tt class="docutils literal"><span class="pre">.apple_namespaces</span></tt>” (all namespaces), we currently set the <tt class="docutils literal"><span class="pre">Atom</span></tt>
+array to be:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="n">HeaderData</span><span class="p">.</span><span class="n">atom_count</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
+<span class="n">HeaderData</span><span class="p">.</span><span class="n">atoms</span><span class="p">[</span><span class="mi">0</span><span class="p">].</span><span class="n">type</span> <span class="o">=</span> <span class="n">eAtomTypeDIEOffset</span><span class="p">;</span>
+<span class="n">HeaderData</span><span class="p">.</span><span class="n">atoms</span><span class="p">[</span><span class="mi">0</span><span class="p">].</span><span class="n">form</span> <span class="o">=</span> <span class="n">DW_FORM_data4</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>This defines the contents to be the DIE offset (eAtomTypeDIEOffset) that is
+encoded as a 32 bit value (DW_FORM_data4). This allows a single name to have
+multiple matching DIEs in a single file, which could come up with an inlined
+function for instance. Future tables could include more information about the
+DIE such as flags indicating if the DIE is a function, method, block,
+or inlined.</p>
+<p>The KeyType for the DWARF table is a 32 bit string table offset into the
+”.debug_str” table. The ”.debug_str” is the string table for the DWARF which
+may already contain copies of all of the strings. This helps make sure, with
+help from the compiler, that we reuse the strings between all of the DWARF
+sections and keeps the hash table size down. Another benefit to having the
+compiler generate all strings as DW_FORM_strp in the debug info, is that
+DWARF parsing can be made much faster.</p>
+<p>After a lookup is made, we get an offset into the hash data. The hash data
+needs to be able to deal with 32 bit hash collisions, so the chunk of data
+at the offset in the hash data consists of a triple:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="kt">uint32_t</span> <span class="n">str_offset</span>
+<span class="kt">uint32_t</span> <span class="n">hash_data_count</span>
+<span class="n">HashData</span><span class="p">[</span><span class="n">hash_data_count</span><span class="p">]</span>
+</pre></div>
+</div>
+<p>If “str_offset” is zero, then the bucket contents are done. 99.9% of the
+hash data chunks contain a single item (no 32 bit hash collision):</p>
+<div class="highlight-none"><div class="highlight"><pre>.------------.
+| 0x00001023 | uint32_t KeyType (.debug_str[0x0001023] => "main")
+| 0x00000004 | uint32_t HashData count
+| 0x........ | uint32_t HashData[0] DIE offset
+| 0x........ | uint32_t HashData[1] DIE offset
+| 0x........ | uint32_t HashData[2] DIE offset
+| 0x........ | uint32_t HashData[3] DIE offset
+| 0x00000000 | uint32_t KeyType (end of hash chain)
+`------------'
+</pre></div>
+</div>
+<p>If there are collisions, you will have multiple valid string offsets:</p>
+<div class="highlight-none"><div class="highlight"><pre>.------------.
+| 0x00001023 | uint32_t KeyType (.debug_str[0x0001023] => "main")
+| 0x00000004 | uint32_t HashData count
+| 0x........ | uint32_t HashData[0] DIE offset
+| 0x........ | uint32_t HashData[1] DIE offset
+| 0x........ | uint32_t HashData[2] DIE offset
+| 0x........ | uint32_t HashData[3] DIE offset
+| 0x00002023 | uint32_t KeyType (.debug_str[0x0002023] => "print")
+| 0x00000002 | uint32_t HashData count
+| 0x........ | uint32_t HashData[0] DIE offset
+| 0x........ | uint32_t HashData[1] DIE offset
+| 0x00000000 | uint32_t KeyType (end of hash chain)
+`------------'
+</pre></div>
+</div>
+<p>Current testing with real world C++ binaries has shown that there is around 1
+32 bit hash collision per 100,000 name entries.</p>
+</div>
+</div>
+<div class="section" id="id7">
+<h4><a class="toc-backref" href="#id37">Contents</a><a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h4>
+<p>As we said, we want to strictly define exactly what is included in the
+different tables. For DWARF, we have 3 tables: “<tt class="docutils literal"><span class="pre">.apple_names</span></tt>”,
+“<tt class="docutils literal"><span class="pre">.apple_types</span></tt>”, and “<tt class="docutils literal"><span class="pre">.apple_namespaces</span></tt>”.</p>
+<p>“<tt class="docutils literal"><span class="pre">.apple_names</span></tt>” sections should contain an entry for each DWARF DIE whose
+<tt class="docutils literal"><span class="pre">DW_TAG</span></tt> is a <tt class="docutils literal"><span class="pre">DW_TAG_label</span></tt>, <tt class="docutils literal"><span class="pre">DW_TAG_inlined_subroutine</span></tt>, or
+<tt class="docutils literal"><span class="pre">DW_TAG_subprogram</span></tt> that has address attributes: <tt class="docutils literal"><span class="pre">DW_AT_low_pc</span></tt>,
+<tt class="docutils literal"><span class="pre">DW_AT_high_pc</span></tt>, <tt class="docutils literal"><span class="pre">DW_AT_ranges</span></tt> or <tt class="docutils literal"><span class="pre">DW_AT_entry_pc</span></tt>. It also contains
+<tt class="docutils literal"><span class="pre">DW_TAG_variable</span></tt> DIEs that have a <tt class="docutils literal"><span class="pre">DW_OP_addr</span></tt> in the location (global and
+static variables). All global and static variables should be included,
+including those scoped within functions and classes. For example using the
+following code:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="k">static</span> <span class="kt">int</span> <span class="n">var</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+
+<span class="kt">void</span> <span class="nf">f</span> <span class="p">()</span>
+<span class="p">{</span>
+ <span class="k">static</span> <span class="kt">int</span> <span class="n">var</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Both of the static <tt class="docutils literal"><span class="pre">var</span></tt> variables would be included in the table. All
+functions should emit both their full names and their basenames. For C or C++,
+the full name is the mangled name (if available) which is usually in the
+<tt class="docutils literal"><span class="pre">DW_AT_MIPS_linkage_name</span></tt> attribute, and the <tt class="docutils literal"><span class="pre">DW_AT_name</span></tt> contains the
+function basename. If global or static variables have a mangled name in a
+<tt class="docutils literal"><span class="pre">DW_AT_MIPS_linkage_name</span></tt> attribute, this should be emitted along with the
+simple name found in the <tt class="docutils literal"><span class="pre">DW_AT_name</span></tt> attribute.</p>
+<p>“<tt class="docutils literal"><span class="pre">.apple_types</span></tt>” sections should contain an entry for each DWARF DIE whose
+tag is one of:</p>
+<ul class="simple">
+<li>DW_TAG_array_type</li>
+<li>DW_TAG_class_type</li>
+<li>DW_TAG_enumeration_type</li>
+<li>DW_TAG_pointer_type</li>
+<li>DW_TAG_reference_type</li>
+<li>DW_TAG_string_type</li>
+<li>DW_TAG_structure_type</li>
+<li>DW_TAG_subroutine_type</li>
+<li>DW_TAG_typedef</li>
+<li>DW_TAG_union_type</li>
+<li>DW_TAG_ptr_to_member_type</li>
+<li>DW_TAG_set_type</li>
+<li>DW_TAG_subrange_type</li>
+<li>DW_TAG_base_type</li>
+<li>DW_TAG_const_type</li>
+<li>DW_TAG_file_type</li>
+<li>DW_TAG_namelist</li>
+<li>DW_TAG_packed_type</li>
+<li>DW_TAG_volatile_type</li>
+<li>DW_TAG_restrict_type</li>
+<li>DW_TAG_atomic_type</li>
+<li>DW_TAG_interface_type</li>
+<li>DW_TAG_unspecified_type</li>
+<li>DW_TAG_shared_type</li>
+</ul>
+<p>Only entries with a <tt class="docutils literal"><span class="pre">DW_AT_name</span></tt> attribute are included, and the entry must
+not be a forward declaration (<tt class="docutils literal"><span class="pre">DW_AT_declaration</span></tt> attribute with a non-zero
+value). For example, using the following code:</p>
+<div class="highlight-c"><div class="highlight"><pre><span class="kt">int</span> <span class="nf">main</span> <span class="p">()</span>
+<span class="p">{</span>
+ <span class="kt">int</span> <span class="o">*</span><span class="n">b</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="k">return</span> <span class="o">*</span><span class="n">b</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>We get a few type DIEs:</p>
+<div class="highlight-none"><div class="highlight"><pre>0x00000067: TAG_base_type [5]
+ AT_encoding( DW_ATE_signed )
+ AT_name( "int" )
+ AT_byte_size( 0x04 )
+
+0x0000006e: TAG_pointer_type [6]
+ AT_type( {0x00000067} ( int ) )
+ AT_byte_size( 0x08 )
+</pre></div>
+</div>
+<p>The DW_TAG_pointer_type is not included because it does not have a <tt class="docutils literal"><span class="pre">DW_AT_name</span></tt>.</p>
+<p>“<tt class="docutils literal"><span class="pre">.apple_namespaces</span></tt>” section should contain all <tt class="docutils literal"><span class="pre">DW_TAG_namespace</span></tt> DIEs.
+If we run into a namespace that has no name this is an anonymous namespace, and
+the name should be output as “<tt class="docutils literal"><span class="pre">(anonymous</span> <span class="pre">namespace)</span></tt>” (without the quotes).
+Why? This matches the output of the <tt class="docutils literal"><span class="pre">abi::cxa_demangle()</span></tt> that is in the
+standard C++ library that demangles mangled names.</p>
+</div>
+<div class="section" id="language-extensions-and-file-format-changes">
+<h4><a class="toc-backref" href="#id38">Language Extensions and File Format Changes</a><a class="headerlink" href="#language-extensions-and-file-format-changes" title="Permalink to this headline">¶</a></h4>
+<div class="section" id="objective-c-extensions">
+<h5><a class="toc-backref" href="#id39">Objective-C Extensions</a><a class="headerlink" href="#objective-c-extensions" title="Permalink to this headline">¶</a></h5>
+<p>“<tt class="docutils literal"><span class="pre">.apple_objc</span></tt>” section should contain all <tt class="docutils literal"><span class="pre">DW_TAG_subprogram</span></tt> DIEs for an
+Objective-C class. The name used in the hash table is the name of the
+Objective-C class itself. If the Objective-C class has a category, then an
+entry is made for both the class name without the category, and for the class
+name with the category. So if we have a DIE at offset 0x1234 with a name of
+method “<tt class="docutils literal"><span class="pre">-[NSString(my_additions)</span> <span class="pre">stringWithSpecialString:]</span></tt>”, we would add
+an entry for “<tt class="docutils literal"><span class="pre">NSString</span></tt>” that points to DIE 0x1234, and an entry for
+“<tt class="docutils literal"><span class="pre">NSString(my_additions)</span></tt>” that points to 0x1234. This allows us to quickly
+track down all Objective-C methods for an Objective-C class when doing
+expressions. It is needed because of the dynamic nature of Objective-C where
+anyone can add methods to a class. The DWARF for Objective-C methods is also
+emitted differently from C++ classes where the methods are not usually
+contained in the class definition, they are scattered about across one or more
+compile units. Categories can also be defined in different shared libraries.
+So we need to be able to quickly find all of the methods and class functions
+given the Objective-C class name, or quickly find all methods and class
+functions for a class + category name. This table does not contain any
+selector names, it just maps Objective-C class names (or class names +
+category) to all of the methods and class functions. The selectors are added
+as function basenames in the “<tt class="docutils literal"><span class="pre">.debug_names</span></tt>” section.</p>
+<p>In the “<tt class="docutils literal"><span class="pre">.apple_names</span></tt>” section for Objective-C functions, the full name is
+the entire function name with the brackets (“<tt class="docutils literal"><span class="pre">-[NSString</span>
+<span class="pre">stringWithCString:]</span></tt>”) and the basename is the selector only
+(“<tt class="docutils literal"><span class="pre">stringWithCString:</span></tt>”).</p>
+</div>
+<div class="section" id="mach-o-changes">
+<h5><a class="toc-backref" href="#id40">Mach-O Changes</a><a class="headerlink" href="#mach-o-changes" title="Permalink to this headline">¶</a></h5>
+<p>The sections names for the apple hash tables are for non-mach-o files. For
+mach-o files, the sections should be contained in the <tt class="docutils literal"><span class="pre">__DWARF</span></tt> segment with
+names as follows:</p>
+<ul class="simple">
+<li>“<tt class="docutils literal"><span class="pre">.apple_names</span></tt>” -> “<tt class="docutils literal"><span class="pre">__apple_names</span></tt>“</li>
+<li>“<tt class="docutils literal"><span class="pre">.apple_types</span></tt>” -> “<tt class="docutils literal"><span class="pre">__apple_types</span></tt>“</li>
+<li>“<tt class="docutils literal"><span class="pre">.apple_namespaces</span></tt>” -> “<tt class="docutils literal"><span class="pre">__apple_namespac</span></tt>” (16 character limit)</li>
+<li>“<tt class="docutils literal"><span class="pre">.apple_objc</span></tt>” -> “<tt class="docutils literal"><span class="pre">__apple_objc</span></tt>“</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="section" id="codeview-debug-info-format">
+<span id="codeview"></span><h2><a class="toc-backref" href="#id41">CodeView Debug Info Format</a><a class="headerlink" href="#codeview-debug-info-format" title="Permalink to this headline">¶</a></h2>
+<p>LLVM supports emitting CodeView, the Microsoft debug info format, and this
+section describes the design and implementation of that support.</p>
+<div class="section" id="format-background">
+<h3><a class="toc-backref" href="#id42">Format Background</a><a class="headerlink" href="#format-background" title="Permalink to this headline">¶</a></h3>
+<p>CodeView as a format is clearly oriented around C++ debugging, and in C++, the
+majority of debug information tends to be type information. Therefore, the
+overriding design constraint of CodeView is the separation of type information
+from other “symbol” information so that type information can be efficiently
+merged across translation units. Both type information and symbol information is
+generally stored as a sequence of records, where each record begins with a
+16-bit record size and a 16-bit record kind.</p>
+<p>Type information is usually stored in the <tt class="docutils literal"><span class="pre">.debug$T</span></tt> section of the object
+file. All other debug info, such as line info, string table, symbol info, and
+inlinee info, is stored in one or more <tt class="docutils literal"><span class="pre">.debug$S</span></tt> sections. There may only be
+one <tt class="docutils literal"><span class="pre">.debug$T</span></tt> section per object file, since all other debug info refers to
+it. If a PDB (enabled by the <tt class="docutils literal"><span class="pre">/Zi</span></tt> MSVC option) was used during compilation,
+the <tt class="docutils literal"><span class="pre">.debug$T</span></tt> section will contain only an <tt class="docutils literal"><span class="pre">LF_TYPESERVER2</span></tt> record pointing
+to the PDB. When using PDBs, symbol information appears to remain in the object
+file <tt class="docutils literal"><span class="pre">.debug$S</span></tt> sections.</p>
+<p>Type records are referred to by their index, which is the number of records in
+the stream before a given record plus <tt class="docutils literal"><span class="pre">0x1000</span></tt>. Many common basic types, such
+as the basic integral types and unqualified pointers to them, are represented
+using type indices less than <tt class="docutils literal"><span class="pre">0x1000</span></tt>. Such basic types are built in to
+CodeView consumers and do not require type records.</p>
+<p>Each type record may only contain type indices that are less than its own type
+index. This ensures that the graph of type stream references is acyclic. While
+the source-level type graph may contain cycles through pointer types (consider a
+linked list struct), these cycles are removed from the type stream by always
+referring to the forward declaration record of user-defined record types. Only
+“symbol” records in the <tt class="docutils literal"><span class="pre">.debug$S</span></tt> streams may refer to complete,
+non-forward-declaration type records.</p>
+</div>
+<div class="section" id="working-with-codeview">
+<h3><a class="toc-backref" href="#id43">Working with CodeView</a><a class="headerlink" href="#working-with-codeview" title="Permalink to this headline">¶</a></h3>
+<p>These are instructions for some common tasks for developers working to improve
+LLVM’s CodeView support. Most of them revolve around using the CodeView dumper
+embedded in <tt class="docutils literal"><span class="pre">llvm-readobj</span></tt>.</p>
+<ul>
+<li><p class="first">Testing MSVC’s output:</p>
+<div class="highlight-python"><pre>$ cl -c -Z7 foo.cpp # Use /Z7 to keep types in the object file
+$ llvm-readobj -codeview foo.obj</pre>
+</div>
+</li>
+<li><p class="first">Getting LLVM IR debug info out of Clang:</p>
+<div class="highlight-python"><pre>$ clang -g -gcodeview --target=x86_64-windows-msvc foo.cpp -S -emit-llvm</pre>
+</div>
+<p>Use this to generate LLVM IR for LLVM test cases.</p>
+</li>
+<li><p class="first">Generate and dump CodeView from LLVM IR metadata:</p>
+<div class="highlight-python"><pre>$ llc foo.ll -filetype=obj -o foo.obj
+$ llvm-readobj -codeview foo.obj > foo.txt</pre>
+</div>
+<p>Use this pattern in lit test cases and FileCheck the output of llvm-readobj</p>
+</li>
+</ul>
+<p>Improving LLVM’s CodeView support is a process of finding interesting type
+records, constructing a C++ test case that makes MSVC emit those records,
+dumping the records, understanding them, and then generating equivalent records
+in LLVM’s backend.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Vectorizers.html" title="Auto-Vectorization in 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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/SphinxQuickstartTemplate.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/SphinxQuickstartTemplate.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/SphinxQuickstartTemplate.html (added)
+++ www-releases/trunk/6.0.1/docs/SphinxQuickstartTemplate.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,223 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Sphinx Quickstart Template — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Code Reviews with Phabricator" href="Phabricator.html" />
+ <link rel="prev" title="How to submit an LLVM bug report" href="HowToSubmitABug.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="HowToSubmitABug.html" title="How to submit an LLVM bug report"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="sphinx-quickstart-template">
+<h1>Sphinx Quickstart Template<a class="headerlink" href="#sphinx-quickstart-template" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction-and-quickstart">
+<h2>Introduction and Quickstart<a class="headerlink" href="#introduction-and-quickstart" title="Permalink to this headline">¶</a></h2>
+<p>This document is meant to get you writing documentation as fast as possible
+even if you have no previous experience with Sphinx. The goal is to take
+someone in the state of “I want to write documentation and get it added to
+LLVM’s docs” and turn that into useful documentation mailed to llvm-commits
+with as little nonsense as possible.</p>
+<p>You can find this document in <tt class="docutils literal"><span class="pre">docs/SphinxQuickstartTemplate.rst</span></tt>. You
+should copy it, open the new file in your text editor, write your docs, and
+then send the new document to llvm-commits for review.</p>
+<p>Focus on <em>content</em>. It is easy to fix the Sphinx (reStructuredText) syntax
+later if necessary, although reStructuredText tries to imitate common
+plain-text conventions so it should be quite natural. A basic knowledge of
+reStructuredText syntax is useful when writing the document, so the last
+~half of this document (starting with <a class="reference internal" href="#example-section">Example Section</a>) gives examples
+which should cover 99% of use cases.</p>
+<p>Let me say that again: focus on <em>content</em>. But if you really need to verify
+Sphinx’s output, see <tt class="docutils literal"><span class="pre">docs/README.txt</span></tt> for information.</p>
+<p>Once you have finished with the content, please send the <tt class="docutils literal"><span class="pre">.rst</span></tt> file to
+llvm-commits for review.</p>
+</div>
+<div class="section" id="guidelines">
+<h2>Guidelines<a class="headerlink" href="#guidelines" title="Permalink to this headline">¶</a></h2>
+<p>Try to answer the following questions in your first section:</p>
+<ol class="arabic simple">
+<li>Why would I want to read this document?</li>
+<li>What should I know to be able to follow along with this document?</li>
+<li>What will I have learned by the end of this document?</li>
+</ol>
+<p>Common names for the first section are <tt class="docutils literal"><span class="pre">Introduction</span></tt>, <tt class="docutils literal"><span class="pre">Overview</span></tt>, or
+<tt class="docutils literal"><span class="pre">Background</span></tt>.</p>
+<p>If possible, make your document a “how to”. Give it a name <tt class="docutils literal"><span class="pre">HowTo*.rst</span></tt>
+like the other “how to” documents. This format is usually the easiest
+for another person to understand and also the most useful.</p>
+<p>You generally should not be writing documentation other than a “how to”
+unless there is already a “how to” about your topic. The reason for this
+is that without a “how to” document to read first, it is difficult for a
+person to understand a more advanced document.</p>
+<p>Focus on content (yes, I had to say it again).</p>
+<p>The rest of this document shows example reStructuredText markup constructs
+that are meant to be read by you in your text editor after you have copied
+this file into a new file for the documentation you are about to write.</p>
+</div>
+<div class="section" id="example-section">
+<h2>Example Section<a class="headerlink" href="#example-section" title="Permalink to this headline">¶</a></h2>
+<p>Your text can be <em>emphasized</em>, <strong>bold</strong>, or <tt class="docutils literal"><span class="pre">monospace</span></tt>.</p>
+<p>Use blank lines to separate paragraphs.</p>
+<p>Headings (like <tt class="docutils literal"><span class="pre">Example</span> <span class="pre">Section</span></tt> just above) give your document its
+structure. Use the same kind of adornments (e.g. <tt class="docutils literal"><span class="pre">======</span></tt> vs. <tt class="docutils literal"><span class="pre">------</span></tt>)
+as are used in this document. The adornment must be the same length as the
+text above it. For Vim users, variations of <tt class="docutils literal"><span class="pre">yypVr=</span></tt> might be handy.</p>
+<div class="section" id="example-subsection">
+<h3>Example Subsection<a class="headerlink" href="#example-subsection" title="Permalink to this headline">¶</a></h3>
+<p>Make a link <a class="reference external" href="http://llvm.org/">like this</a>. There is also a more
+sophisticated syntax which <a class="reference external" href="http://en.wikipedia.org/wiki/LLVM">can be more readable</a> for longer links since
+it disrupts the flow less. You can put the <tt class="docutils literal"><span class="pre">..</span> <span class="pre">_`link</span> <span class="pre">text`:</span> <span class="pre"><URL></span></tt> block
+pretty much anywhere later in the document.</p>
+<p>Lists can be made like this:</p>
+<ol class="arabic simple">
+<li>A list starting with <tt class="docutils literal"><span class="pre">#.</span></tt> will be automatically numbered.</li>
+<li>This is a second list element.<ol class="arabic">
+<li>Use indentation to create nested lists.</li>
+</ol>
+</li>
+</ol>
+<p>You can also use unordered lists.</p>
+<ul class="simple">
+<li>Stuff.<ul>
+<li>Deeper stuff.</li>
+</ul>
+</li>
+<li>More stuff.</li>
+</ul>
+<div class="section" id="example-subsubsection">
+<h4>Example Subsubsection<a class="headerlink" href="#example-subsubsection" title="Permalink to this headline">¶</a></h4>
+<p>You can make blocks of code like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">main</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>For a shell session, use a <tt class="docutils literal"><span class="pre">console</span></tt> code block (some existing docs use
+<tt class="docutils literal"><span class="pre">bash</span></tt>):</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> <span class="nb">echo</span> <span class="s2">"Goodbye cruel world!"</span>
+<span class="gp">$</span> rm -rf /
+</pre></div>
+</div>
+<p>If you need to show LLVM IR use the <tt class="docutils literal"><span class="pre">llvm</span></tt> code block.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span class="k">define</span> <span class="k">i32</span> <span class="vg">@test1</span><span class="p">()</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+ <span class="k">ret</span> <span class="k">i32</span> <span class="m">0</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>Some other common code blocks you might need are <tt class="docutils literal"><span class="pre">c</span></tt>, <tt class="docutils literal"><span class="pre">objc</span></tt>, <tt class="docutils literal"><span class="pre">make</span></tt>,
+and <tt class="docutils literal"><span class="pre">cmake</span></tt>. If you need something beyond that, you can look at the <a class="reference external" href="http://pygments.org/docs/lexers/">full
+list</a> of supported code blocks.</p>
+<p>However, don’t waste time fiddling with syntax highlighting when you could
+be adding meaningful content. When in doubt, show preformatted text
+without any syntax highlighting like this:</p>
+<div class="highlight-python"><pre> .
+ +:.
+ ..:: ::
+ .++:+:: ::+:.:.
+ .:+ :
+ ::.::..:: .+.
+ ..:+ :: :
+......+:. ..
+ :++. .. :
+ .+:::+:: :
+ .. . .+ ::
+ +.: .::+.
+ ...+. .: .
+ .++:..
+ ...</pre>
+</div>
+<div class="section" id="hopefully-you-won-t-need-to-be-this-deep">
+<h5>Hopefully you won’t need to be this deep<a class="headerlink" href="#hopefully-you-won-t-need-to-be-this-deep" title="Permalink to this headline">¶</a></h5>
+<p>If you need to do fancier things than what has been shown in this document,
+you can mail the list or check Sphinx’s <a class="reference external" href="http://sphinx.pocoo.org/rest.html">reStructuredText Primer</a>.</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="Phabricator.html" title="Code Reviews with Phabricator"
+ >next</a> |</li>
+ <li class="right" >
+ <a href="HowToSubmitABug.html" title="How to submit an LLVM bug report"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/StackMaps.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/StackMaps.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/StackMaps.html (added)
+++ www-releases/trunk/6.0.1/docs/StackMaps.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,585 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Stack maps and patch points in LLVM — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Design and Usage of the InAlloca Attribute" href="InAlloca.html" />
+ <link rel="prev" title="User Guide for AMDGPU Backend" href="AMDGPUUsage.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="InAlloca.html" title="Design and Usage of the InAlloca Attribute"
+ accesskey="N">next</a> |</li>
+ <li class="right" >
+ <a href="AMDGPUUsage.html" title="User Guide for AMDGPU Backend"
+ accesskey="P">previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="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">‘<tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt>‘ Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-patchpoint-intrinsic" id="id9">‘<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint.*</span></tt>‘ 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 <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt> at a particular
+instruction address. These <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt> 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"><em>Stack Map Section</em></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 <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt> 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"><em>Computing stack maps</em></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: <tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt> and
+<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint</span></tt>. 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. <tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint</span></tt>
+implicitly generates a stack map without the need for an additional
+call to <tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt>). 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. <tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt> 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
+<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint</span></tt>, which reserves space for in-place
+patching without overwriting surrounding code. The
+<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint</span></tt> 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"><em>Stack Map Section</em></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">‘<tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt>‘ 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-python"><pre>declare void
+ @llvm.experimental.stackmap(i64 <id>, i32 <numShadowBytes>, ...)</pre>
+</div>
+</div>
+<div class="section" id="overview">
+<h4>Overview:<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h4>
+<p>The ‘<tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt>‘ 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 <tt class="docutils literal"><span class="pre">live</span>
+<span class="pre">values</span></tt> 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 <tt class="docutils literal"><span class="pre">llvm.experimental.stackmap</span></tt> or
+<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint</span></tt> 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"><div class="highlight"><pre><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"><div class="highlight"><pre>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"><div class="highlight"><pre>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">‘<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint.*</span></tt>‘ 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-python"><pre>declare void
+ @llvm.experimental.patchpoint.void(i64 <id>, i32 <numBytes>,
+ i8* <target>, i32 <numArgs>, ...)
+declare i64
+ @llvm.experimental.patchpoint.i64(i64 <id>, i32 <numBytes>,
+ i8* <target>, i32 <numArgs>, ...)</pre>
+</div>
+</div>
+<div class="section" id="id2">
+<h4>Overview:<a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h4>
+<p>The ‘<tt class="docutils literal"><span class="pre">llvm.experimental.patchpoint.*</span></tt>‘ intrinsics creates a function
+call to the specified <tt class="docutils literal"><span class="pre"><target></span></tt> 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 <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt> 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 <tt class="docutils literal"><span class="pre"><target></span></tt> 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 <tt class="docutils literal"><span class="pre"><target></span></tt> must be the ABI function pointer for the
+intended target of the indirect call. Specifically, when compiling for the
+ELF V1 ABI, <tt class="docutils literal"><span class="pre"><target></span></tt> 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
+<tt class="docutils literal"><span class="pre">llvm.experimental.stackmap.*</span></tt>. 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 <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt> 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 <tt class="docutils literal"><span class="pre">live</span> <span class="pre">values</span></tt>.</p>
+<p>The patch point also emits nops to cover at least <tt class="docutils literal"><span class="pre"><numBytes></span></tt> of
+instruction encoding space. Hence, the client must ensure that
+<tt class="docutils literal"><span class="pre"><numBytes></span></tt> 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"><div class="highlight"><pre><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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">anyregcc</span></tt> convention may be used:</p>
+<div class="highlight-none"><div class="highlight"><pre>%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"><div class="highlight"><pre>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"><div class="highlight"><pre>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"><em>Stack Map Section</em></a>. The
+format of this section follows:</p>
+<div class="highlight-none"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">RegNum</span></tt> and <tt class="docutils literal"><span class="pre">Offset</span></tt> 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
+<tt class="docutils literal"><span class="pre">Offset</span></tt> field will be zero. Values spilled to the stack are encoded
+as <tt class="docutils literal"><span class="pre">Indirect</span></tt> locations. The runtime must load those values from a
+stack address, typically in the form <tt class="docutils literal"><span class="pre">[BP</span> <span class="pre">+</span> <span class="pre">Offset]</span></tt>. If an
+<tt class="docutils literal"><span class="pre">alloca</span></tt> 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 <tt class="docutils literal"><span class="pre">Direct</span></tt> locations in the form <tt class="docutils literal"><span class="pre">BP</span> <span class="pre">+</span> <span class="pre">Offset</span></tt>. LLVM may
+also optimize constants by emitting them directly in the stack map,
+either in the <tt class="docutils literal"><span class="pre">Offset</span></tt> of a <tt class="docutils literal"><span class="pre">Constant</span></tt> location or in the constant
+pool, referred to by <tt class="docutils literal"><span class="pre">ConstantIndex</span></tt> 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 <tt class="docutils literal"><span class="pre">%rax</span></tt>, then the value may be in either <tt class="docutils literal"><span class="pre">%al</span></tt> or
+<tt class="docutils literal"><span class="pre">%ah</span></tt>. It doesn’t matter in practice, because the runtime will
+simply save <tt class="docutils literal"><span class="pre">%rax</span></tt>. However, if the stackmap reports 16 bytes at
+<tt class="docutils literal"><span class="pre">%ymm0</span></tt>, then the runtime can safely optimize by saving only
+<tt class="docutils literal"><span class="pre">%xmm0</span></tt>.</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
+<tt class="docutils literal"><span class="pre">LLVMCreateSimpleMCJITMemoryManager()</span></tt>. When creating the memory
+manager, the JIT provides a callback:
+<tt class="docutils literal"><span class="pre">LLVMMemoryManagerAllocateDataSectionCallback()</span></tt>. 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>On Darwin, 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"><em>Stack Map Section</em></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"><div class="highlight"><pre>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">
+ <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="AMDGPUUsage.html" title="User Guide for AMDGPU Backend"
+ >previous</a> |</li>
+ <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+ <li><a href="index.html">Documentation</a>»</li>
+
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/Statepoints.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/Statepoints.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/Statepoints.html (added)
+++ www-releases/trunk/6.0.1/docs/Statepoints.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,877 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Garbage Collection Safepoints in LLVM — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.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">
+ <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">
+
+ <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="id12">Status</a></li>
+<li><a class="reference internal" href="#overview" id="id13">Overview</a><ul>
+<li><a class="reference internal" href="#base-derived-pointers" id="id14">Base & Derived Pointers</a></li>
+<li><a class="reference internal" href="#gc-transitions" id="id15">GC Transitions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#intrinsics" id="id16">Intrinsics</a><ul>
+<li><a class="reference internal" href="#llvm-experimental-gc-statepoint-intrinsic" id="id17">‘llvm.experimental.gc.statepoint’ Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-gc-result-intrinsic" id="id18">‘llvm.experimental.gc.result’ Intrinsic</a></li>
+<li><a class="reference internal" href="#llvm-experimental-gc-relocate-intrinsic" id="id19">‘llvm.experimental.gc.relocate’ Intrinsic</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#stack-map-format" id="id20">Stack Map Format</a></li>
+<li><a class="reference internal" href="#safepoint-semantics-verification" id="id21">Safepoint Semantics & Verification</a></li>
+<li><a class="reference internal" href="#utility-passes-for-safepoint-insertion" id="id22">Utility Passes for Safepoint Insertion</a><ul>
+<li><a class="reference internal" href="#rewritestatepointsforgc" id="id23">RewriteStatepointsForGC</a></li>
+<li><a class="reference internal" href="#placesafepoints" id="id24">PlaceSafepoints</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#supported-architectures" id="id25">Supported Architectures</a></li>
+<li><a class="reference internal" href="#problem-areas-and-active-work" id="id26">Problem Areas and Active Work</a></li>
+<li><a class="reference internal" href="#bugs-and-enhancements" id="id27">Bugs and Enhancements</a></li>
+</ul>
+</div>
+<div class="section" id="status">
+<h2><a class="toc-backref" href="#id12">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 <tt class="docutils literal"><span class="pre">gcroot</span></tt> intrinsic. The <tt class="docutils literal"><span class="pre">gcroot</span></tt> 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">
+<h2><a class="toc-backref" href="#id13">Overview</a><a class="headerlink" href="#overview" 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>
+<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>Warning: Non-Integral Pointer Types are a newly added concept in LLVM IR.
+It’s possible that we’ve missed disabling some of the optimizations which
+assume an integral value for pointers. If you find such a case, please
+file a bug or share a patch.</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>
+<p>This high level abstract machine model is used for most of the LLVM optimizer.
+Before starting code generation, we switch representations to an explicit form.
+In theory, a frontend could directly generate this low level explicit form, but
+doing so is likely to inhibit optimization.</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"><em>utility passes</em></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"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">foo</span></tt>. 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 <tt class="docutils literal"><span class="pre">%obj</span></tt>. Since we can’t
+actually change the value in the SSA value <tt class="docutils literal"><span class="pre">%obj</span></tt>, we need to introduce a new
+SSA value <tt class="docutils literal"><span class="pre">%obj.relocated</span></tt> which represents the potentially changed value of
+<tt class="docutils literal"><span class="pre">%obj</span></tt> after the safepoint and update any following uses appropriately. The
+resulting relocation sequence is:</p>
+<div class="highlight-llvm"><pre>define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
+ gc "statepoint-example" {
+ %0 = call token (i64, i32, void ()*, i32, i32, ...)* @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32 0, i32 0, i32 0, i32 0, i8 addrspace(1)* %obj)
+ %obj.relocated = call coldcc i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token %0, i32 7, i32 7)
+ ret i8 addrspace(1)* %obj.relocated
+}</pre>
+</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 <tt class="docutils literal"><span class="pre">gc.result</span></tt> intrinsic. To get the relocation
+of each pointer in turn, we use the <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> intrinsic with the
+appropriate index. Note that both the <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> and <tt class="docutils literal"><span class="pre">gc.result</span></tt> 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"><div class="highlight"><pre> <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"><em>Stack Map section</em></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"><div class="highlight"><pre><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</span><span class="p">-</span><span class="no">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"><em>RewriteStatepointsForGC</em></a>
+utility pass. As such, its full StackMap can be easily examined with the
+following command.</p>
+<div class="highlight-bash"><div class="highlight"><pre>opt -rewrite-statepoints-for-gc <span class="nb">test</span>/Transforms/RewriteStatepointsForGC/basics.ll -S | llc -debug-only<span class="o">=</span>stackmaps
+</pre></div>
+</div>
+<div class="section" id="base-derived-pointers">
+<h3><a class="toc-backref" href="#id14">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 <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> 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"><pre>define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
+ gc "statepoint-example" {
+ %gep = getelementptr i8, i8 addrspace(1)* %obj, i64 20000
+ %token = call token (i64, i32, void ()*, i32, i32, ...)* @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32 0, i32 0, i32 0, i32 0, i8 addrspace(1)* %obj, i8 addrspace(1)* %gep)
+ %obj.relocated = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token %token, i32 7, i32 7)
+ %gep.relocated = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token %token, i32 7, i32 8)
+ %p = getelementptr i8, i8 addrspace(1)* %gep, i64 -20000
+ ret i8 addrspace(1)* %p
+}</pre>
+</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="#id15">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 <tt class="docutils literal"><span class="pre">@foo</span></tt>
+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"><pre>@flag = thread_local global i32 0, align 4
+
+define i8 addrspace(1)* @test1(i8 addrspace(1) *%obj)
+ gc "hypothetical-gc" {
+
+ %0 = call token (i64, i32, void ()*, i32, i32, ...)* @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32 0, i32 1, i32* @Flag, i32 0, i8 addrspace(1)* %obj)
+ %obj.relocated = call coldcc i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token %0, i32 7, i32 7)
+ ret i8 addrspace(1)* %obj.relocated
+}</pre>
+</div>
+<p>During lowering, this will result in a instruction selection DAG that looks
+something like:</p>
+<div class="highlight-python"><pre>CALLSEQ_START
+...
+GC_TRANSITION_START (lowered i32 *@Flag), SRCVALUE i32* Flag
+STATEPOINT
+GC_TRANSITION_END (lowered i32 *@Flag), SRCVALUE i32 *Flag
+...
+CALLSEQ_END</pre>
+</div>
+<p>In order to generate the necessary transition code, the backend for each target
+supported by “hypothetical-gc” must be modified to lower <tt class="docutils literal"><span class="pre">GC_TRANSITION_START</span></tt>
+and <tt class="docutils literal"><span class="pre">GC_TRANSITION_END</span></tt> 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"><div class="highlight"><pre> <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="#id16">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="#id17">‘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-python"><pre>declare token
+ @llvm.experimental.gc.statepoint(i64 <id>, i32 <num patch bytes>,
+ func_type <target>,
+ i64 <#call args>, i64 <flags>,
+ ... (call parameters),
+ i64 <# transition args>, ... (transition parameters),
+ i64 <# deopt args>, ... (deopt parameters),
+ ... (gc parameters))</pre>
+</div>
+</div>
+<div class="section" id="id1">
+<h4>Overview:<a class="headerlink" href="#id1" 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"><em>Stack maps and patch points in LLVM</em></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
+<tt class="docutils literal"><span class="pre">gc.relocate</span></tt>) must be used.</p>
+</div>
+</div>
+<div class="section" id="llvm-experimental-gc-result-intrinsic">
+<h3><a class="toc-backref" href="#id18">‘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="id2">
+<h4>Syntax:<a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-python"><pre>declare type*
+ @llvm.experimental.gc.result(token %statepoint_token)</pre>
+</div>
+</div>
+<div class="section" id="id3">
+<h4>Overview:<a class="headerlink" href="#id3" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">gc.result</span></tt> extracts the result of the original call instruction
+which was replaced by the <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>. The <tt class="docutils literal"><span class="pre">gc.result</span></tt>
+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="id4">
+<h4>Operands:<a class="headerlink" href="#id4" title="Permalink to this headline">¶</a></h4>
+<p>The first and only argument is the <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> which starts
+the safepoint sequence of which this <tt class="docutils literal"><span class="pre">gc.result</span></tt> is a part.
+Despite the typing of this as a generic token, <em>only</em> the value defined
+by a <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> is legal here.</p>
+</div>
+<div class="section" id="id5">
+<h4>Semantics:<a class="headerlink" href="#id5" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">gc.result</span></tt> represents the return value of the call target of
+the <tt class="docutils literal"><span class="pre">statepoint</span></tt>. The type of the <tt class="docutils literal"><span class="pre">gc.result</span></tt> must exactly match
+the type of the target. If the call target returns void, there will
+be no <tt class="docutils literal"><span class="pre">gc.result</span></tt>.</p>
+<p>A <tt class="docutils literal"><span class="pre">gc.result</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>.</p>
+</div>
+</div>
+<div class="section" id="llvm-experimental-gc-relocate-intrinsic">
+<h3><a class="toc-backref" href="#id19">‘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="id6">
+<h4>Syntax:<a class="headerlink" href="#id6" title="Permalink to this headline">¶</a></h4>
+<div class="highlight-python"><pre>declare <pointer type>
+ @llvm.experimental.gc.relocate(token %statepoint_token,
+ i32 %base_offset,
+ i32 %pointer_offset)</pre>
+</div>
+</div>
+<div class="section" id="id7">
+<h4>Overview:<a class="headerlink" href="#id7" title="Permalink to this headline">¶</a></h4>
+<p>A <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> returns the potentially relocated value of a pointer
+at the safepoint.</p>
+</div>
+<div class="section" id="id8">
+<h4>Operands:<a class="headerlink" href="#id8" title="Permalink to this headline">¶</a></h4>
+<p>The first argument is the <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> which starts the
+safepoint sequence of which this <tt class="docutils literal"><span class="pre">gc.relocation</span></tt> is a part.
+Despite the typing of this as a generic token, <em>only</em> the value defined
+by a <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> 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="id9">
+<h4>Semantics:<a class="headerlink" href="#id9" title="Permalink to this headline">¶</a></h4>
+<p>The return value of <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> 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
+<tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.relocate</span></tt> is modeled as a <tt class="docutils literal"><span class="pre">readnone</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>.</p>
+</div>
+</div>
+</div>
+<div class="section" id="stack-map-format">
+<span id="statepoint-stackmap-format"></span><h2><a class="toc-backref" href="#id20">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 via the <a class="reference internal" href="StackMaps.html#stackmap-format"><em>Stack Map format</em></a> specified in the PatchPoint documentation.</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"><em>calling convention identifier</em></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="#id21">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="#id22">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="id10"></span><h3><a class="toc-backref" href="#id23">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 <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> and associated full
+relocation sequence, including all required <tt class="docutils literal"><span class="pre">gc.relocates</span></tt>.</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"><div class="highlight"><pre><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"><pre>define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
+ gc "statepoint-example" {
+ %0 = call token (i64, i32, void ()*, i32, i32, ...)* @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 2882400000, i32 0, void ()* @foo, i32 0, i32 0, i32 0, i32 5, i32 0, i32 -1, i32 0, i32 0, i32 0, i8 addrspace(1)* %obj)
+ %obj.relocated = call coldcc i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token %0, i32 12, i32 12)
+ ret i8 addrspace(1)* %obj.relocated
+}</pre>
+</div>
+<p>In the above examples, the addrspace(1) marker on the pointers is the mechanism
+that the <tt class="docutils literal"><span class="pre">statepoint-example</span></tt> 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 <tt class="docutils literal"><span class="pre">0xABCDEF00</span></tt> as the statepoint
+ID and <tt class="docutils literal"><span class="pre">0</span></tt> as the number of patchable bytes to the newly constructed
+<tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>. These values can be configured on a per-callsite
+basis using the attributes <tt class="docutils literal"><span class="pre">"statepoint-id"</span></tt> and
+<tt class="docutils literal"><span class="pre">"statepoint-num-patch-bytes"</span></tt>. If a call site is marked with a
+<tt class="docutils literal"><span class="pre">"statepoint-id"</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>. If a call site is marked
+with a <tt class="docutils literal"><span class="pre">"statepoint-num-patch-bytes"</span></tt> function attribute and its
+value is a positive integer, then that value is used as the ‘num patch
+bytes’ parameter of the newly constructed <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt>. The
+<tt class="docutils literal"><span class="pre">"statepoint-id"</span></tt> and <tt class="docutils literal"><span class="pre">"statepoint-num-patch-bytes"</span></tt> attributes
+are not propagated to the <tt class="docutils literal"><span class="pre">gc.statepoint</span></tt> 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="id11"></span><h3><a class="toc-backref" href="#id24">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"><div class="highlight"><pre><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"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">foo</span></tt> and <tt class="docutils literal"><span class="pre">test</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.safepoint_poll</span></tt> 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 <tt class="docutils literal"><span class="pre">gc.statepoints</span></tt>, 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="#id25">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="problem-areas-and-active-work">
+<h2><a class="toc-backref" href="#id26">Problem Areas and Active Work</a><a class="headerlink" href="#problem-areas-and-active-work" title="Permalink to this headline">¶</a></h2>
+<ol class="arabic simple">
+<li>Support for languages which allow unmanaged pointers to garbage collected
+objects (i.e. pass a pointer to an object to a C routine) via pinning.</li>
+<li>Support for garbage collected objects allocated on the stack. Specifically,
+allocas are always assumed to be in address space 0 and we need a
+cast/promotion operator to let rewriting identify them.</li>
+<li>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.</li>
+<li>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.</li>
+<li>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.</li>
+</ol>
+</div>
+<div class="section" id="bugs-and-enhancements">
+<h2><a class="toc-backref" href="#id27">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">
+ <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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/SystemLibrary.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/SystemLibrary.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/SystemLibrary.html (added)
+++ www-releases/trunk/6.0.1/docs/SystemLibrary.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,312 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>System Library — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="Source Level Debugging with LLVM" href="SourceLevelDebugging.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">
+ <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="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">
+
+ <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="abstract">
+<h2>Abstract<a class="headerlink" href="#abstract" title="Permalink to this headline">¶</a></h2>
+<p>This document provides some details on LLVM’s System Library, located in the
+source at <tt class="docutils literal"><span class="pre">lib/System</span></tt> and <tt class="docutils literal"><span class="pre">include/llvm/System</span></tt>. 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 System 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">include/llvm/System</span></tt>.</p>
+<p>Note that the System 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 System Library was 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 System Library. Adherence to these rules
+should help the System Library achieve its goal of shielding LLVM from the
+variations in operating system interfaces and doing so efficiently. The
+following sections define the rules needed to fulfill this objective.</p>
+<div 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt>, no LLVM source code should directly <tt class="docutils literal"><span class="pre">#include</span></tt> a
+system header. Care has been taken to remove all such <tt class="docutils literal"><span class="pre">#includes</span></tt> from LLVM
+while <tt class="docutils literal"><span class="pre">lib/System</span></tt> was being developed. Specifically this means that header
+files like “<tt class="docutils literal"><span class="pre">unistd.h</span></tt>”, “<tt class="docutils literal"><span class="pre">windows.h</span></tt>”, “<tt class="docutils literal"><span class="pre">stdio.h</span></tt>”, and “<tt class="docutils literal"><span class="pre">string.h</span></tt>”
+are forbidden to be included by LLVM source code outside the implementation of
+<tt class="docutils literal"><span class="pre">lib/System</span></tt>.</p>
+<p>To obtain system-dependent functionality, existing interfaces to the system
+found in <tt class="docutils literal"><span class="pre">include/llvm/System</span></tt> should be used. If an appropriate interface is
+not available, it should be added to <tt class="docutils literal"><span class="pre">include/llvm/System</span></tt> and implemented in
+<tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 System Library must shield LLVM from <strong>all</strong> system headers. To obtain
+system level functionality, LLVM source must <tt class="docutils literal"><span class="pre">#include</span> <span class="pre">"llvm/System/Thing.h"</span></tt>
+and nothing else. This means that <tt class="docutils literal"><span class="pre">Thing.h</span></tt> cannot expose any system header
+files. This protects LLVM from accidentally using system specific functionality
+and only allows it via the <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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
+<tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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: <tt class="docutils literal"><span class="pre">getenv</span></tt>, <tt class="docutils literal"><span class="pre">fork</span></tt>, <tt class="docutils literal"><span class="pre">execve</span></tt>, and <tt class="docutils literal"><span class="pre">wait</span></tt>. The
+correct thing for <tt class="docutils literal"><span class="pre">lib/System</span></tt> to provide is a function, say
+<tt class="docutils literal"><span class="pre">ExecuteProgramAndWait</span></tt>, 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 System 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt>
+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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 System Library interfaces can be called quite frequently by LLVM. In order
+to make those calls as efficient as possible, we discourage the use of virtual
+methods. There is no need to use inheritance for implementation differences, it
+just adds complexity. The <tt class="docutils literal"><span class="pre">#include</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt>)
+must not be exposed through the <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">stat</span></tt> system call is notorious for having variations in the
+data it provides. <tt class="docutils literal"><span class="pre">lib/System</span></tt> must not declare <tt class="docutils literal"><span class="pre">stat</span></tt> 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 <tt class="docutils literal"><span class="pre">stat</span></tt> but that is strictly an implementation detail. The interface
+provided by the System Library must be implemented on all platforms (even those
+without <tt class="docutils literal"><span class="pre">stat</span></tt>).</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 <tt class="docutils literal"><span class="pre">lib/System</span></tt>) must
+not be exposed through the <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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><tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 “<tt class="docutils literal"><span class="pre">OpenFileForWriting</span></tt>”
+function. For many operating systems, if the file doesn’t exist, attempting to
+open the file will produce an error. However, <tt class="docutils literal"><span class="pre">lib/System</span></tt> should not simply
+throw that error if it occurs because its a soft error. The problem is that the
+interface function, <tt class="docutils literal"><span class="pre">OpenFileForWriting</span></tt> is too low level. It should be
+<tt class="docutils literal"><span class="pre">OpenOrCreateFileForWriting</span></tt>. 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> interface functions may be declared with C++
+<tt class="docutils literal"><span class="pre">throw()</span></tt> 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: <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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 System Library interface are separated by their general
+class of operating system. Currently only Unix and Win32 classes are defined
+but more could be added for other operating system classifications. To
+distinguish which implementation to compile, the code in <tt class="docutils literal"><span class="pre">lib/System</span></tt> uses
+the <tt class="docutils literal"><span class="pre">LLVM_ON_UNIX</span></tt> and <tt class="docutils literal"><span class="pre">LLVM_ON_WIN32</span></tt> <tt class="docutils literal"><span class="pre">#defines</span></tt> provided via configure
+through the <tt class="docutils literal"><span class="pre">llvm/Config/config.h</span></tt> file. Each source file in <tt class="docutils literal"><span class="pre">lib/System</span></tt>,
+after implementing the generic (operating system independent) functionality
+needs to include the correct implementation using a set of
+<tt class="docutils literal"><span class="pre">#if</span> <span class="pre">defined(LLVM_ON_XYZ)</span></tt> directives. For example, if we had
+<tt class="docutils literal"><span class="pre">lib/System/File.cpp</span></tt>, we’d expect to see in that file:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="cp">#if defined(LLVM_ON_UNIX)</span>
+<span class="cp">#include "Unix/File.cpp"</span>
+<span class="cp">#endif</span>
+<span class="cp">#if defined(LLVM_ON_WIN32)</span>
+<span class="cp">#include "Win32/File.cpp"</span>
+<span class="cp">#endif</span>
+</pre></div>
+</div>
+<p>The implementation in <tt class="docutils literal"><span class="pre">lib/System/Unix/File.cpp</span></tt> should handle all Unix
+variants. The implementation in <tt class="docutils literal"><span class="pre">lib/System/Win32/File.cpp</span></tt> should handle all
+Win32 variants. What this does is quickly differentiate 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 <tt class="docutils literal"><span class="pre">#ifdef</span></tt>.</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 <tt class="docutils literal"><span class="pre">lib/System</span></tt> 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,
+<tt class="docutils literal"><span class="pre">lib/System</span></tt> 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">
+ <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="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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGen/BackEnds.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGen/BackEnds.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGen/BackEnds.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGen/BackEnds.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,504 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen BackEnds — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="up" title="TableGen" href="index.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">
+ <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><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <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="#ctags" id="id17">CTags</a></li>
+<li><a class="reference internal" href="#x86evex2vex" id="id18">X86EVEX2VEX</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#clang-backends" id="id19">Clang BackEnds</a><ul>
+<li><a class="reference internal" href="#clangattrclasses" id="id20">ClangAttrClasses</a></li>
+<li><a class="reference internal" href="#clangattrparserstringswitches" id="id21">ClangAttrParserStringSwitches</a></li>
+<li><a class="reference internal" href="#clangattrimpl" id="id22">ClangAttrImpl</a></li>
+<li><a class="reference internal" href="#clangattrlist" id="id23">ClangAttrList</a></li>
+<li><a class="reference internal" href="#clangattrpchread" id="id24">ClangAttrPCHRead</a></li>
+<li><a class="reference internal" href="#clangattrpchwrite" id="id25">ClangAttrPCHWrite</a></li>
+<li><a class="reference internal" href="#clangattrspellings" id="id26">ClangAttrSpellings</a></li>
+<li><a class="reference internal" href="#clangattrspellinglistindex" id="id27">ClangAttrSpellingListIndex</a></li>
+<li><a class="reference internal" href="#clangattrvisitor" id="id28">ClangAttrVisitor</a></li>
+<li><a class="reference internal" href="#clangattrtemplateinstantiate" id="id29">ClangAttrTemplateInstantiate</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrlist" id="id30">ClangAttrParsedAttrList</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrimpl" id="id31">ClangAttrParsedAttrImpl</a></li>
+<li><a class="reference internal" href="#clangattrparsedattrkinds" id="id32">ClangAttrParsedAttrKinds</a></li>
+<li><a class="reference internal" href="#clangattrdump" id="id33">ClangAttrDump</a></li>
+<li><a class="reference internal" href="#clangdiagsdefs" id="id34">ClangDiagsDefs</a></li>
+<li><a class="reference internal" href="#clangdiaggroups" id="id35">ClangDiagGroups</a></li>
+<li><a class="reference internal" href="#clangdiagsindexname" id="id36">ClangDiagsIndexName</a></li>
+<li><a class="reference internal" href="#clangcommentnodes" id="id37">ClangCommentNodes</a></li>
+<li><a class="reference internal" href="#clangdeclnodes" id="id38">ClangDeclNodes</a></li>
+<li><a class="reference internal" href="#clangstmtnodes" id="id39">ClangStmtNodes</a></li>
+<li><a class="reference internal" href="#clangsacheckers" id="id40">ClangSACheckers</a></li>
+<li><a class="reference internal" href="#clangcommenthtmltags" id="id41">ClangCommentHTMLTags</a></li>
+<li><a class="reference internal" href="#clangcommenthtmltagsproperties" id="id42">ClangCommentHTMLTagsProperties</a></li>
+<li><a class="reference internal" href="#clangcommenthtmlnamedcharacterreferences" id="id43">ClangCommentHTMLNamedCharacterReferences</a></li>
+<li><a class="reference internal" href="#clangcommentcommandinfo" id="id44">ClangCommentCommandInfo</a></li>
+<li><a class="reference internal" href="#clangcommentcommandlist" id="id45">ClangCommentCommandList</a></li>
+<li><a class="reference internal" href="#armneon" id="id46">ArmNeon</a></li>
+<li><a class="reference internal" href="#armneonsema" id="id47">ArmNeonSema</a></li>
+<li><a class="reference internal" href="#armneontest" id="id48">ArmNeonTest</a></li>
+<li><a class="reference internal" href="#attrdocs" id="id49">AttrDocs</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#how-to-write-a-back-end" id="id50">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++"><div class="highlight"><pre><span class="cp">#define GET_REGINFO_TARGET_DESC</span>
+<span class="cp">#include "ARMGenRegisterInfo.inc"</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++"><div class="highlight"><pre><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 "ARMGenAsmMatcher.inc"</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 <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt> binary will be executed on the root
+TableGen file <tt class="docutils literal"><span class="pre"><Target>.td</span></tt>, 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 <tt class="docutils literal"><span class="pre"><Target>CodeEmitter::function()</span></tt>.</p>
+<p><strong>Usage</strong>: Used to include directly at the end of <tt class="docutils literal"><span class="pre"><Target>MCCodeEmitter.cpp</span></tt>.</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 <tt class="docutils literal"><span class="pre"><Target>BaseRegisterInfo</span></tt> and <tt class="docutils literal"><span class="pre"><Target>MCTargetDesc</span></tt> (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 <tt class="docutils literal"><span class="pre"><Target>BaseInstrInfo</span></tt> and <tt class="docutils literal"><span class="pre"><Target>MCTargetDesc</span></tt> (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 <tt class="docutils literal"><span class="pre"><Target>InstPrinter::printInstruction()</span></tt>, among
+other things.</p>
+<p><strong>Usage</strong>: Included directly into <tt class="docutils literal"><span class="pre">InstPrinter/<Target>InstPrinter.cpp</span></tt>.</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 <tt class="docutils literal"><span class="pre">AsmMatcherEmitter.cpp</span></tt> file.</p>
+<p><strong>Output</strong>: Assembler parsers’ matcher functions, declarations, etc.</p>
+<p><strong>Usage</strong>: Used in back-ends’ <tt class="docutils literal"><span class="pre">AsmParser/<Target>AsmParser.cpp</span></tt> 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
+<tt class="docutils literal"><span class="pre">DisassemblerEmitter.cpp</span></tt> file.</p>
+<p><strong>Output</strong>: Decoding tables, static decoding functions, etc.</p>
+<p><strong>Usage</strong>: Directly included in <tt class="docutils literal"><span class="pre">Disassembler/<Target>Disassembler.cpp</span></tt>
+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 <tt class="docutils literal"><span class="pre"><Target>AsmPrinter::emitPseudoExpansionLowering()</span></tt>.</p>
+<p><strong>Usage</strong>: Included directly into <tt class="docutils literal"><span class="pre"><Target>AsmPrinter.cpp</span></tt>.</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 <tt class="docutils literal"><span class="pre"><Target>ISelDAGToDAG.cpp</span></tt> inside the target’s
+implementation of <tt class="docutils literal"><span class="pre">SelectionDAGISel</span></tt>.</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 <tt class="docutils literal"><span class="pre"><Target>InstrInfo.cpp</span></tt>.</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 <tt class="docutils literal"><span class="pre">Predicate</span></tt> and <tt class="docutils literal"><span class="pre">FastEmit</span></tt> methods.</p>
+<p><strong>Usage</strong>: Implements private methods of the targets’ implementation
+of <tt class="docutils literal"><span class="pre">FastISel</span></tt> 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 <tt class="docutils literal"><span class="pre"><Target>Subtarget</span></tt> and
+<tt class="docutils literal"><span class="pre">MCTargetDesc/<Target>MCTargetDesc</span></tt> 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="ctags">
+<h3><a class="toc-backref" href="#id17">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="#id18">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="#id19">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="#id20">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 <tt class="docutils literal"><span class="pre">Attr.td</span></tt> that has not set <tt class="docutils literal"><span class="pre">ASTNode</span> <span class="pre">=</span> <span class="pre">0</span></tt>.
+This file is included as part of <tt class="docutils literal"><span class="pre">Attr.h</span></tt>.</p>
+</div>
+<div class="section" id="clangattrparserstringswitches">
+<h3><a class="toc-backref" href="#id21">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 <tt class="docutils literal"><span class="pre">CLANG_ATTR_ARG_CONTEXT_LIST</span></tt>, or
+<tt class="docutils literal"><span class="pre">CLANG_ATTR_IDENTIFIER_ARG_LIST</span></tt>), 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="#id22">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 <tt class="docutils literal"><span class="pre">Attr.td</span></tt> that has not set <tt class="docutils literal"><span class="pre">ASTNode</span> <span class="pre">=</span> <span class="pre">0</span></tt>.
+This file is included as part of <tt class="docutils literal"><span class="pre">AttrImpl.cpp</span></tt>.</p>
+</div>
+<div class="section" id="clangattrlist">
+<h3><a class="toc-backref" href="#id23">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, <tt class="docutils literal"><span class="pre">AttrKinds.h</span></tt> includes this
+file to generate the list of <tt class="docutils literal"><span class="pre">attr::Kind</span></tt> 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 <tt class="docutils literal"><span class="pre">Attr.td</span></tt> and is used to implement the <tt class="docutils literal"><span class="pre">classof</span></tt>
+functionality required for <tt class="docutils literal"><span class="pre">dyn_cast</span></tt> and similar APIs.</p>
+</div>
+<div class="section" id="clangattrpchread">
+<h3><a class="toc-backref" href="#id24">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 <tt class="docutils literal"><span class="pre">ASTReader::ReadAttributes</span></tt> function.</p>
+</div>
+<div class="section" id="clangattrpchwrite">
+<h3><a class="toc-backref" href="#id25">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 <tt class="docutils literal"><span class="pre">ASTWriter::WriteAttributes</span></tt> function.</p>
+</div>
+<div class="section" id="clangattrspellings">
+<h3><a class="toc-backref" href="#id26">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
+<tt class="docutils literal"><span class="pre">__has_attribute</span></tt> feature test macro.</p>
+</div>
+<div class="section" id="clangattrspellinglistindex">
+<h3><a class="toc-backref" href="#id27">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
+<tt class="docutils literal"><span class="pre">AttributeList::getAttributeSpellingListIndex</span></tt>.</p>
+</div>
+<div class="section" id="clangattrvisitor">
+<h3><a class="toc-backref" href="#id28">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="#id29">ClangAttrTemplateInstantiate</a><a class="headerlink" href="#clangattrtemplateinstantiate" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates AttrTemplateInstantiate.inc, which implements the
+<tt class="docutils literal"><span class="pre">instantiateTemplateAttribute</span></tt> 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="#id30">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
+<tt class="docutils literal"><span class="pre">AttributeList::Kind</span></tt> parsed attribute enumeration.</p>
+</div>
+<div class="section" id="clangattrparsedattrimpl">
+<h3><a class="toc-backref" href="#id31">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
+<tt class="docutils literal"><span class="pre">AttributeList.cpp</span></tt> to implement several functions on the <tt class="docutils literal"><span class="pre">AttributeList</span></tt>
+class. This functionality is implemented via the <tt class="docutils literal"><span class="pre">AttrInfoMap</span> <span class="pre">ParsedAttrInfo</span></tt>
+array, which contains one element per parsed attribute object.</p>
+</div>
+<div class="section" id="clangattrparsedattrkinds">
+<h3><a class="toc-backref" href="#id32">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
+<tt class="docutils literal"><span class="pre">AttributeList::getKind</span></tt> function, mapping a string (and syntax) to a parsed
+attribute <tt class="docutils literal"><span class="pre">AttributeList::Kind</span></tt> enumeration.</p>
+</div>
+<div class="section" id="clangattrdump">
+<h3><a class="toc-backref" href="#id33">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 <tt class="docutils literal"><span class="pre">ASTDumper::dumpAttr</span></tt>.</p>
+</div>
+<div class="section" id="clangdiagsdefs">
+<h3><a class="toc-backref" href="#id34">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="#id35">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="#id36">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="#id37">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="#id38">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="#id39">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="#id40">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="#id41">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="#id42">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="#id43">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="#id44">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="#id45">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="#id46">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="#id47">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="#id48">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="#id49">AttrDocs</a><a class="headerlink" href="#attrdocs" title="Permalink to this headline">¶</a></h3>
+<p><strong>Purpose</strong>: Creates <tt class="docutils literal"><span class="pre">AttributeReference.rst</span></tt> from <tt class="docutils literal"><span class="pre">AttrDocs.td</span></tt>, and is
+used for documenting user-facing attributes.</p>
+</div>
+</div>
+<div class="section" id="how-to-write-a-back-end">
+<h2><a class="toc-backref" href="#id50">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 <tt class="docutils literal"><span class="pre">-print-enums</span></tt> as an example. This
+should highlight the APIs in <tt class="docutils literal"><span class="pre">TableGen/Record.h</span></tt>.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="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><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGen/Deficiencies.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGen/Deficiencies.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGen/Deficiencies.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGen/Deficiencies.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,129 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen Deficiencies — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="up" title="TableGen" href="index.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">
+ <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><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <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">
+ <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><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGen/LangIntro.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGen/LangIntro.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGen/LangIntro.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGen/LangIntro.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,650 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen Language Introduction — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="up" title="TableGen" href="index.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">
+ <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><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <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"><em>TableGen Language Reference</em></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 “<tt class="docutils literal"><span class="pre">//</span></tt>” comments, which run to the end of the
+line, and it also supports <strong>nestable</strong> “<tt class="docutils literal"><span class="pre">/*</span> <span class="pre">*/</span></tt>” 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 <tt class="docutils literal"><span class="pre">bit</span></tt>) and very
+high-level types (such as <tt class="docutils literal"><span class="pre">dag</span></tt>). 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><tt class="docutils literal"><span class="pre">bit</span></tt></dt>
+<dd>A ‘bit’ is a boolean value that can hold either 0 or 1.</dd>
+<dt><tt class="docutils literal"><span class="pre">int</span></tt></dt>
+<dd>The ‘int’ type represents a simple 32-bit integer value, such as 5.</dd>
+<dt><tt class="docutils literal"><span class="pre">string</span></tt></dt>
+<dd>The ‘string’ type represents an ordered sequence of characters of arbitrary
+length.</dd>
+<dt><tt class="docutils literal"><span class="pre">code</span></tt></dt>
+<dd>The <cite>code</cite> type represents a code fragment, which can be single/multi-line
+string literal.</dd>
+<dt><tt class="docutils literal"><span class="pre">bits<n></span></tt></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><tt class="docutils literal"><span class="pre">list<ty></span></tt></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 <tt class="docutils literal"><span class="pre">list</span></tt> type, for example, to constrain the elements of the list to a
+common base class (e.g., a <tt class="docutils literal"><span class="pre">list<Register></span></tt> can only contain definitions
+derived from the “<tt class="docutils literal"><span class="pre">Register</span></tt>” class).</dd>
+<dt><tt class="docutils literal"><span class="pre">dag</span></tt></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><tt class="docutils literal"><span class="pre">?</span></tt></dt>
+<dd>uninitialized field</dd>
+<dt><tt class="docutils literal"><span class="pre">0b1001011</span></tt></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><tt class="docutils literal"><span class="pre">7</span></tt></dt>
+<dd>decimal integer value</dd>
+<dt><tt class="docutils literal"><span class="pre">0x7F</span></tt></dt>
+<dd>hexadecimal integer value</dd>
+<dt><tt class="docutils literal"><span class="pre">"foo"</span></tt></dt>
+<dd>a single-line string value, can be assigned to <tt class="docutils literal"><span class="pre">string</span></tt> or <tt class="docutils literal"><span class="pre">code</span></tt> variable.</dd>
+<dt><tt class="docutils literal"><span class="pre">[{</span> <span class="pre">...</span> <span class="pre">}]</span></tt></dt>
+<dd>usually called a “code fragment”, but is just a multiline string literal</dd>
+<dt><tt class="docutils literal"><span class="pre">[</span> <span class="pre">X,</span> <span class="pre">Y,</span> <span class="pre">Z</span> <span class="pre">]<type></span></tt></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><tt class="docutils literal"><span class="pre">{</span> <span class="pre">a,</span> <span class="pre">b,</span> <span class="pre">0b10</span> <span class="pre">}</span></tt></dt>
+<dd>initializer for a “bits<4>” value.
+1-bit from “a”, 1-bit from “b”, 2-bits from 0b10.</dd>
+<dt><tt class="docutils literal"><span class="pre">value</span></tt></dt>
+<dd>value reference</dd>
+<dt><tt class="docutils literal"><span class="pre">value{17}</span></tt></dt>
+<dd>access to one bit of a value</dd>
+<dt><tt class="docutils literal"><span class="pre">value{15-17}</span></tt></dt>
+<dd>access to an ordered sequence of bits of a value, in particular <tt class="docutils literal"><span class="pre">value{15-17}</span></tt>
+produces an order that is the reverse of <tt class="docutils literal"><span class="pre">value{17-15}</span></tt>.</dd>
+<dt><tt class="docutils literal"><span class="pre">DEF</span></tt></dt>
+<dd>reference to a record definition</dd>
+<dt><tt class="docutils literal"><span class="pre">CLASS<val</span> <span class="pre">list></span></tt></dt>
+<dd>reference to a new anonymous definition of CLASS with the specified template
+arguments.</dd>
+<dt><tt class="docutils literal"><span class="pre">X.Y</span></tt></dt>
+<dd>reference to the subfield of a value</dd>
+<dt><tt class="docutils literal"><span class="pre">list[4-7,17,2-3]</span></tt></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><tt class="docutils literal"><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></tt></p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><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></tt></dt>
+<dd>Replicate <body> or <def>, replacing instances of <var> with each value
+in <list>. <var> is scoped at the level of the <tt class="docutils literal"><span class="pre">foreach</span></tt> loop and must
+not conflict with any other object introduced in <body> or <def>. Currently
+only <tt class="docutils literal"><span class="pre">def</span></tt>s are expanded within <body>.</dd>
+</dl>
+<p><tt class="docutils literal"><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></tt></p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><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></tt></dt>
+<dd>Loop over ranges of integers. The braces are required for multiple ranges.</dd>
+<dt><tt class="docutils literal"><span class="pre">(DEF</span> <span class="pre">a,</span> <span class="pre">b)</span></tt></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 <tt class="docutils literal"><span class="pre">`dag</span></tt>‘ values.</dd>
+<dt><tt class="docutils literal"><span class="pre">!listconcat(a,</span> <span class="pre">b,</span> <span class="pre">...)</span></tt></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><tt class="docutils literal"><span class="pre">!strconcat(a,</span> <span class="pre">b,</span> <span class="pre">...)</span></tt></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><tt class="docutils literal"><span class="pre">str1#str2</span></tt></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><tt class="docutils literal"><span class="pre">!cast<type>(a)</span></tt></dt>
+<dd>A symbol of type <em>type</em> obtained by looking up the string ‘a’ in the symbol
+table. If the type of ‘a’ does not match <em>type</em>, TableGen aborts with an
+error. !cast<string> is a special case in that the argument must be an
+object defined by a ‘def’ construct.</dd>
+<dt><tt class="docutils literal"><span class="pre">!subst(a,</span> <span class="pre">b,</span> <span class="pre">c)</span></tt></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><tt class="docutils literal"><span class="pre">!foreach(a,</span> <span class="pre">b,</span> <span class="pre">c)</span></tt></dt>
+<dd>For each member of dag or list ‘b’ apply operator ‘c.’ ‘a’ is a dummy
+variable that should be declared as a member variable of an instantiated
+class. This operation is analogous to $(foreach) in GNU make.</dd>
+<dt><tt class="docutils literal"><span class="pre">!head(a)</span></tt></dt>
+<dd>The first element of list ‘a.’</dd>
+<dt><tt class="docutils literal"><span class="pre">!tail(a)</span></tt></dt>
+<dd>The 2nd-N elements of list ‘a.’</dd>
+<dt><tt class="docutils literal"><span class="pre">!empty(a)</span></tt></dt>
+<dd>An integer {0,1} indicating whether list ‘a’ is empty.</dd>
+<dt><tt class="docutils literal"><span class="pre">!if(a,b,c)</span></tt></dt>
+<dd>‘b’ if the result of ‘int’ or ‘bit’ operator ‘a’ is nonzero, ‘c’ otherwise.</dd>
+<dt><tt class="docutils literal"><span class="pre">!eq(a,b)</span></tt></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><tt class="docutils literal"><span class="pre">!shl(a,b)</span></tt> <tt class="docutils literal"><span class="pre">!srl(a,b)</span></tt> <tt class="docutils literal"><span class="pre">!sra(a,b)</span></tt> <tt class="docutils literal"><span class="pre">!add(a,b)</span></tt> <tt class="docutils literal"><span class="pre">!and(a,b)</span></tt></dt>
+<dd>The usual binary and arithmetic 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 “<tt class="docutils literal"><span class="pre">7</span></tt>”
+to a “<tt class="docutils literal"><span class="pre">bits<4></span></tt>” 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"><em>introduction</em></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 <tt class="docutils literal"><span class="pre">def</span></tt> or <tt class="docutils literal"><span class="pre">class</span></tt> 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 (“<tt class="docutils literal"><span class="pre">:</span></tt>”). 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 (“<tt class="docutils literal"><span class="pre">{}</span></tt>”); otherwise,
+the record ends with a semicolon.</p>
+<p>Here is a simple TableGen file:</p>
+<div class="highlight-text"><div class="highlight"><pre>class C { bit V = 1; }
+def X : C;
+def Y : C {
+ string Greeting = "hello";
+}
+</pre></div>
+</div>
+<p>This example defines two definitions, <tt class="docutils literal"><span class="pre">X</span></tt> and <tt class="docutils literal"><span class="pre">Y</span></tt>, both of which derive from
+the <tt class="docutils literal"><span class="pre">C</span></tt> class. Because of this, they both get the <tt class="docutils literal"><span class="pre">V</span></tt> bit value. The <tt class="docutils literal"><span class="pre">Y</span></tt>
+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
+‘<tt class="docutils literal"><span class="pre">let</span></tt>‘ keyword followed by a value name, an equal sign (“<tt class="docutils literal"><span class="pre">=</span></tt>”), and a new
+value. For example, a new class could be added to the example above, redefining
+the <tt class="docutils literal"><span class="pre">V</span></tt> field for all of its subclasses:</p>
+<div class="highlight-text"><div class="highlight"><pre>class D : C { let V = 0; }
+def Z : D;
+</pre></div>
+</div>
+<p>In this case, the <tt class="docutils literal"><span class="pre">Z</span></tt> definition will have a zero value for its <tt class="docutils literal"><span class="pre">V</span></tt> value,
+despite the fact that it derives (indirectly) from the <tt class="docutils literal"><span class="pre">C</span></tt> class, because the
+<tt class="docutils literal"><span class="pre">D</span></tt> class overrode its value.</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"><div class="highlight"><pre>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 “<tt class="docutils literal"><span class="pre">Value</span></tt>” 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt> on the example prints the following definitions:</p>
+<div class="highlight-text"><div class="highlight"><pre>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: “<tt class="docutils literal"><span class="pre">reg</span> <span class="pre">=</span> <span class="pre">reg</span> <span class="pre">op</span> <span class="pre">reg</span></tt>” and “<tt class="docutils literal"><span class="pre">reg</span> <span class="pre">=</span> <span class="pre">reg</span> <span class="pre">op</span> <span class="pre">imm</span></tt>”
+(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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">ADD_rr</span></tt>, <tt class="docutils literal"><span class="pre">ADD_ri</span></tt>, <tt class="docutils literal"><span class="pre">SUB_rr</span></tt>, 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">defm</span></tt> can also be used inside a multiclass providing several levels of
+multiclass instantiations.</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">defm</span></tt> 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"><div class="highlight"><pre>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 ‘<tt class="docutils literal"><span class="pre">include</span></tt>‘ token, which textually substitutes the
+specified file in place of the include directive. The filename should be
+specified as a double quoted string immediately after the ‘<tt class="docutils literal"><span class="pre">include</span></tt>‘ keyword.
+Example:</p>
+<div class="highlight-text"><div class="highlight"><pre>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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">CALL*</span></tt> 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"><div class="highlight"><pre>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 ‘<tt class="docutils literal"><span class="pre">foreach</span></tt>‘ block, which textually replicates the loop
+body, substituting iterator values for iterator references in the body.
+Example:</p>
+<div class="highlight-text"><div class="highlight"><pre>foreach i = [0, 1, 2, 3] in {
+ def R#i : Register<...>;
+ def F#i : Register<...>;
+}
+</pre></div>
+</div>
+<p>This will create objects <tt class="docutils literal"><span class="pre">R0</span></tt>, <tt class="docutils literal"><span class="pre">R1</span></tt>, <tt class="docutils literal"><span class="pre">R2</span></tt> and <tt class="docutils literal"><span class="pre">R3</span></tt>. <tt class="docutils literal"><span class="pre">foreach</span></tt> blocks
+may be nested. If there is only one item in the body the braces may be
+elided:</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">(implicit</span> <span class="pre">a)</span></tt></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">
+ <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><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGen/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGen/LangRef.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGen/LangRef.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGen/LangRef.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,441 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen Language Reference — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.html" />
+ <link rel="up" title="TableGen" href="index.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">
+ <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><a href="index.html" accesskey="U">TableGen</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <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"><tt class="docutils literal"><span class="pre">class</span></tt>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"><tt class="docutils literal"><span class="pre">def</span></tt></a></li>
+<li><a class="reference internal" href="#defm" id="id20"><tt class="docutils literal"><span class="pre">defm</span></tt></a></li>
+<li><a class="reference internal" href="#foreach" id="id21"><tt class="docutils literal"><span class="pre">foreach</span></tt></a></li>
+<li><a class="reference internal" href="#top-level-let" id="id22">Top-Level <tt class="docutils literal"><span class="pre">let</span></tt></a></li>
+<li><a class="reference internal" href="#multiclass" id="id23"><tt class="docutils literal"><span class="pre">multiclass</span></tt></a></li>
+</ul>
+</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"><em>introduction to TableGen</em></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 (<tt class="docutils literal"><span class="pre">//</span> <span class="pre">...</span></tt>) and nestable C-style (<tt class="docutils literal"><span class="pre">/*</span> <span class="pre">...</span> <span class="pre">*/</span></tt>)
+comments.</p>
+<p>The following is a listing of the basic punctuation tokens:</p>
+<div class="highlight-python"><pre>- + [ ] { } ( ) < > : ; . = ? #</pre>
+</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"><tt class="xref docutils literal"><span class="pre">DecimalInteger</span></tt></a> | <a class="reference internal" href="#grammar-token-HexInteger"><tt class="xref docutils literal"><span class="pre">HexInteger</span></tt></a> | <a class="reference internal" href="#grammar-token-BinInteger"><tt class="xref docutils literal"><span class="pre">BinInteger</span></tt></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"><tt class="xref std std-token docutils literal"><span class="pre">DecimalInteger</span></tt></a> token <em>includes</em> the
+<tt class="docutils literal"><span class="pre">+</span></tt> or <tt class="docutils literal"><span class="pre">-</span></tt>, as opposed to having <tt class="docutils literal"><span class="pre">+</span></tt> and <tt class="docutils literal"><span class="pre">-</span></tt> be unary operators as
+most languages do.</p>
+<p>Also note that <a class="reference internal" href="#grammar-token-BinInteger"><tt class="xref std std-token docutils literal"><span class="pre">BinInteger</span></tt></a> creates a value of type <tt class="docutils literal"><span class="pre">bits<n></span></tt>
+(where <tt class="docutils literal"><span class="pre">n</span></tt> 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"><tt class="xref docutils literal"><span class="pre">ualpha</span></tt></a> (<a class="reference internal" href="#grammar-token-ualpha"><tt class="xref docutils literal"><span class="pre">ualpha</span></tt></a> | "0"..."9")*
+<strong id="grammar-token-TokVarName">TokVarName </strong> ::= "$" <a class="reference internal" href="#grammar-token-ualpha"><tt class="xref docutils literal"><span class="pre">ualpha</span></tt></a> (<a class="reference internal" href="#grammar-token-ualpha"><tt class="xref docutils literal"><span class="pre">ualpha</span></tt></a> | "0"..."9")*
+</pre>
+<p>Note that unlike most languages, TableGen allows <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref std std-token docutils literal"><span class="pre">TokIdentifier</span></tt></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"><tt class="xref std std-token docutils literal"><span class="pre">TokCodeFragment</span></tt></a> is essentially a multiline string literal
+delimited by <tt class="docutils literal"><span class="pre">[{</span></tt> and <tt class="docutils literal"><span class="pre">}]</span></tt>.</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-python"><pre>\\ \' \" \t \n</pre>
+</div>
+</div>
+<p>TableGen also has the following keywords:</p>
+<div class="highlight-python"><pre>bit bits class code dag
+def foreach defm field in
+int let list multiclass string</pre>
+</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
+</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 <tt class="docutils literal"><span class="pre">include</span></tt> 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"><tt class="xref docutils literal"><span class="pre">TokString</span></tt></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"><tt class="xref docutils literal"><span class="pre">Object</span></tt></a>*
+<strong id="grammar-token-Object">Object </strong> ::= <a class="reference internal" href="#grammar-token-Class"><tt class="xref docutils literal"><span class="pre">Class</span></tt></a> | <a class="reference internal" href="#grammar-token-Def"><tt class="xref docutils literal"><span class="pre">Def</span></tt></a> | <a class="reference internal" href="#grammar-token-Defm"><tt class="xref docutils literal"><span class="pre">Defm</span></tt></a> | <a class="reference internal" href="#grammar-token-Let"><tt class="xref docutils literal"><span class="pre">Let</span></tt></a> | <a class="reference internal" href="#grammar-token-MultiClass"><tt class="xref docutils literal"><span class="pre">MultiClass</span></tt></a> | <a class="reference internal" href="#grammar-token-Foreach"><tt class="xref docutils literal"><span class="pre">Foreach</span></tt></a>
+</pre>
+<div class="section" id="classes">
+<h3><a class="toc-backref" href="#id14"><tt class="docutils literal"><span class="pre">class</span></tt>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"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> [<a class="reference internal" href="#grammar-token-TemplateArgList"><tt class="xref docutils literal"><span class="pre">TemplateArgList</span></tt></a>] <a class="reference internal" href="#grammar-token-ObjectBody"><tt class="xref docutils literal"><span class="pre">ObjectBody</span></tt></a>
+</pre>
+<p>A <tt class="docutils literal"><span class="pre">class</span></tt> 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 <tt class="docutils literal"><span class="pre">class</span></tt> 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"><tt class="xref std std-token docutils literal"><span class="pre">TemplateArgList</span></tt></a> is present.</li>
+<li>The <a class="reference internal" href="#grammar-token-Body"><tt class="xref std std-token docutils literal"><span class="pre">Body</span></tt></a> in the <a class="reference internal" href="#grammar-token-ObjectBody"><tt class="xref std std-token docutils literal"><span class="pre">ObjectBody</span></tt></a> is present and is not empty.</li>
+<li>The <a class="reference internal" href="#grammar-token-BaseClassList"><tt class="xref std std-token docutils literal"><span class="pre">BaseClassList</span></tt></a> in the <a class="reference internal" href="#grammar-token-ObjectBody"><tt class="xref std std-token docutils literal"><span class="pre">ObjectBody</span></tt></a> is present.</li>
+</ol>
+<p>You can declare an empty class by giving and empty <a class="reference internal" href="#grammar-token-TemplateArgList"><tt class="xref std std-token docutils literal"><span class="pre">TemplateArgList</span></tt></a>
+and an empty <a class="reference internal" href="#grammar-token-ObjectBody"><tt class="xref std std-token docutils literal"><span class="pre">ObjectBody</span></tt></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>
+<pre>
+<strong id="grammar-token-TemplateArgList">TemplateArgList</strong> ::= "<" <a class="reference internal" href="#grammar-token-Declaration"><tt class="xref docutils literal"><span class="pre">Declaration</span></tt></a> ("," <a class="reference internal" href="#grammar-token-Declaration"><tt class="xref docutils literal"><span class="pre">Declaration</span></tt></a>)* ">"
+</pre>
+</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"><tt class="xref docutils literal"><span class="pre">Type</span></tt></a> <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> ["=" <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></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"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a> ">"
+ | "list" "<" <a class="reference internal" href="#grammar-token-Type"><tt class="xref docutils literal"><span class="pre">Type</span></tt></a> ">"
+ | <a class="reference internal" href="#grammar-token-ClassID"><tt class="xref docutils literal"><span class="pre">ClassID</span></tt></a>
+<strong id="grammar-token-ClassID">ClassID</strong> ::= <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a>
+</pre>
+<p>Both <tt class="docutils literal"><span class="pre">string</span></tt> and <tt class="docutils literal"><span class="pre">code</span></tt> correspond to the string type; the difference
+is purely to indicate programmer intention.</p>
+<p>The <a class="reference internal" href="#grammar-token-ClassID"><tt class="xref std std-token docutils literal"><span class="pre">ClassID</span></tt></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"><tt class="xref docutils literal"><span class="pre">SimpleValue</span></tt></a> <a class="reference internal" href="#grammar-token-ValueSuffix"><tt class="xref docutils literal"><span class="pre">ValueSuffix</span></tt></a>*
+<strong id="grammar-token-ValueSuffix">ValueSuffix</strong> ::= "{" <a class="reference internal" href="#grammar-token-RangeList"><tt class="xref docutils literal"><span class="pre">RangeList</span></tt></a> "}"
+ | "[" <a class="reference internal" href="#grammar-token-RangeList"><tt class="xref docutils literal"><span class="pre">RangeList</span></tt></a> "]"
+ | "." <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a>
+<strong id="grammar-token-RangeList">RangeList </strong> ::= <a class="reference internal" href="#grammar-token-RangePiece"><tt class="xref docutils literal"><span class="pre">RangePiece</span></tt></a> ("," <a class="reference internal" href="#grammar-token-RangePiece"><tt class="xref docutils literal"><span class="pre">RangePiece</span></tt></a>)*
+<strong id="grammar-token-RangePiece">RangePiece </strong> ::= <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a>
+ | <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a> "-" <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a>
+ | <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a> <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></a>
+</pre>
+<p>The peculiar last form of <a class="reference internal" href="#grammar-token-RangePiece"><tt class="xref std std-token docutils literal"><span class="pre">RangePiece</span></tt></a> is due to the fact that the
+“<tt class="docutils literal"><span class="pre">-</span></tt>” is included in the <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref std std-token docutils literal"><span class="pre">TokInteger</span></tt></a>, hence <tt class="docutils literal"><span class="pre">1-5</span></tt> gets lexed as
+two consecutive <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref std std-token docutils literal"><span class="pre">TokInteger</span></tt></a>‘s, with values <tt class="docutils literal"><span class="pre">1</span></tt> and <tt class="docutils literal"><span class="pre">-5</span></tt>,
+instead of “1”, “-”, and “5”.
+The <a class="reference internal" href="#grammar-token-RangeList"><tt class="xref std std-token docutils literal"><span class="pre">RangeList</span></tt></a> can be thought of as specifying “list slice” in some
+contexts.</p>
+<p><a class="reference internal" href="#grammar-token-SimpleValue"><tt class="xref std std-token docutils literal"><span class="pre">SimpleValue</span></tt></a> has a number of forms:</p>
+<pre>
+<strong id="grammar-token-SimpleValue">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></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 <tt class="docutils literal"><span class="pre">def</span></tt>, such as the use of <tt class="docutils literal"><span class="pre">Bar</span></tt> in:</p>
+<div class="highlight-python"><pre>def Bar : SomeClass {
+ int X = 5;
+}
+
+def Foo {
+ SomeClass Baz = Bar;
+}</pre>
+</div>
+</li>
+<li><p class="first">value local to a <tt class="docutils literal"><span class="pre">def</span></tt>, such as the use of <tt class="docutils literal"><span class="pre">Bar</span></tt> in:</p>
+<div class="highlight-python"><pre>def Foo {
+ int Bar = 5;
+ int Baz = Bar;
+}</pre>
+</div>
+</li>
+<li><p class="first">a template arg of a <tt class="docutils literal"><span class="pre">class</span></tt>, such as the use of <tt class="docutils literal"><span class="pre">Bar</span></tt> in:</p>
+<div class="highlight-python"><pre>class Foo<int Bar> {
+ int Baz = Bar;
+}</pre>
+</div>
+</li>
+<li><p class="first">value local to a <tt class="docutils literal"><span class="pre">multiclass</span></tt>, such as the use of <tt class="docutils literal"><span class="pre">Bar</span></tt> in:</p>
+<div class="highlight-python"><pre>multiclass Foo {
+ int Bar = 5;
+ int Baz = Bar;
+}</pre>
+</div>
+</li>
+<li><p class="first">a template arg to a <tt class="docutils literal"><span class="pre">multiclass</span></tt>, such as the use of <tt class="docutils literal"><span class="pre">Bar</span></tt> in:</p>
+<div class="highlight-python"><pre>multiclass Foo<int Bar> {
+ int Baz = Bar;
+}</pre>
+</div>
+</li>
+</ul>
+<pre>
+<strong id="id1">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-TokInteger"><tt class="xref docutils literal"><span class="pre">TokInteger</span></tt></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"><tt class="xref docutils literal"><span class="pre">TokString</span></tt></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"><tt class="xref docutils literal"><span class="pre">TokCodeFragment</span></tt></a>
+</pre>
+<p>The value is the string value of the code fragment.</p>
+<pre>
+<strong id="id4">SimpleValue</strong> ::= "?"
+</pre>
+<p><tt class="docutils literal"><span class="pre">?</span></tt> represents an “unset” initializer.</p>
+<pre>
+<strong id="id5">SimpleValue</strong> ::= "{" <a class="reference internal" href="#grammar-token-ValueList"><tt class="xref docutils literal"><span class="pre">ValueList</span></tt></a> "}"
+<strong id="grammar-token-ValueList">ValueList </strong> ::= [<a class="reference internal" href="#grammar-token-ValueListNE"><tt class="xref docutils literal"><span class="pre">ValueListNE</span></tt></a>]
+<strong id="grammar-token-ValueListNE">ValueListNE</strong> ::= <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></a> ("," <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></a>)*
+</pre>
+<p>This represents a sequence of bits, as would be used to initialize a
+<tt class="docutils literal"><span class="pre">bits<n></span></tt> field (where <tt class="docutils literal"><span class="pre">n</span></tt> is the number of bits).</p>
+<pre>
+<strong id="id6">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-ClassID"><tt class="xref docutils literal"><span class="pre">ClassID</span></tt></a> "<" <a class="reference internal" href="#grammar-token-ValueListNE"><tt class="xref docutils literal"><span class="pre">ValueListNE</span></tt></a> ">"
+</pre>
+<p>This generates a new anonymous record definition (as would be created by an
+unnamed <tt class="docutils literal"><span class="pre">def</span></tt> 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"><tt class="xref docutils literal"><span class="pre">ValueList</span></tt></a> "]" ["<" <a class="reference internal" href="#grammar-token-Type"><tt class="xref docutils literal"><span class="pre">Type</span></tt></a> ">"]
+</pre>
+<p>A list initializer. The optional <a class="reference internal" href="#grammar-token-Type"><tt class="xref std std-token docutils literal"><span class="pre">Type</span></tt></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"><tt class="xref docutils literal"><span class="pre">DagArg</span></tt></a> <a class="reference internal" href="#grammar-token-DagArgList"><tt class="xref docutils literal"><span class="pre">DagArgList</span></tt></a> ")"
+<strong id="grammar-token-DagArgList">DagArgList </strong> ::= <a class="reference internal" href="#grammar-token-DagArg"><tt class="xref docutils literal"><span class="pre">DagArg</span></tt></a> ("," <a class="reference internal" href="#grammar-token-DagArg"><tt class="xref docutils literal"><span class="pre">DagArg</span></tt></a>)*
+<strong id="grammar-token-DagArg">DagArg </strong> ::= <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></a> [":" <a class="reference internal" href="#grammar-token-TokVarName"><tt class="xref docutils literal"><span class="pre">TokVarName</span></tt></a>] | <a class="reference internal" href="#grammar-token-TokVarName"><tt class="xref docutils literal"><span class="pre">TokVarName</span></tt></a>
+</pre>
+<p>The initial <a class="reference internal" href="#grammar-token-DagArg"><tt class="xref std std-token docutils literal"><span class="pre">DagArg</span></tt></a> is called the “operator” of the dag.</p>
+<pre>
+<strong id="id9">SimpleValue</strong> ::= <a class="reference internal" href="#grammar-token-BangOperator"><tt class="xref docutils literal"><span class="pre">BangOperator</span></tt></a> ["<" <a class="reference internal" href="#grammar-token-Type"><tt class="xref docutils literal"><span class="pre">Type</span></tt></a> ">"] "(" <a class="reference internal" href="#grammar-token-ValueListNE"><tt class="xref docutils literal"><span class="pre">ValueListNE</span></tt></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"><tt class="xref docutils literal"><span class="pre">BaseClassList</span></tt></a> <a class="reference internal" href="#grammar-token-Body"><tt class="xref docutils literal"><span class="pre">Body</span></tt></a>
+<strong id="grammar-token-BaseClassList">BaseClassList </strong> ::= [":" <a class="reference internal" href="#grammar-token-BaseClassListNE"><tt class="xref docutils literal"><span class="pre">BaseClassListNE</span></tt></a>]
+<strong id="grammar-token-BaseClassListNE">BaseClassListNE</strong> ::= <a class="reference internal" href="#grammar-token-SubClassRef"><tt class="xref docutils literal"><span class="pre">SubClassRef</span></tt></a> ("," <a class="reference internal" href="#grammar-token-SubClassRef"><tt class="xref docutils literal"><span class="pre">SubClassRef</span></tt></a>)*
+<strong id="grammar-token-SubClassRef">SubClassRef </strong> ::= (<a class="reference internal" href="#grammar-token-ClassID"><tt class="xref docutils literal"><span class="pre">ClassID</span></tt></a> | <a class="reference internal" href="#grammar-token-MultiClassID"><tt class="xref docutils literal"><span class="pre">MultiClassID</span></tt></a>) ["<" <a class="reference internal" href="#grammar-token-ValueList"><tt class="xref docutils literal"><span class="pre">ValueList</span></tt></a> ">"]
+<strong id="grammar-token-DefmID">DefmID </strong> ::= <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a>
+</pre>
+<p>The version with the <a class="reference internal" href="#grammar-token-MultiClassID"><tt class="xref std std-token docutils literal"><span class="pre">MultiClassID</span></tt></a> is only valid in the
+<a class="reference internal" href="#grammar-token-BaseClassList"><tt class="xref std std-token docutils literal"><span class="pre">BaseClassList</span></tt></a> of a <tt class="docutils literal"><span class="pre">defm</span></tt>.
+The <a class="reference internal" href="#grammar-token-MultiClassID"><tt class="xref std std-token docutils literal"><span class="pre">MultiClassID</span></tt></a> should be the name of a <tt class="docutils literal"><span class="pre">multiclass</span></tt>.</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"><tt class="xref docutils literal"><span class="pre">Declaration</span></tt></a> ";"
+ | "let" <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> [<a class="reference internal" href="#grammar-token-RangeList"><tt class="xref docutils literal"><span class="pre">RangeList</span></tt></a>] "=" <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></a> ";"
+</pre>
+<p>The <tt class="docutils literal"><span class="pre">let</span></tt> form allows overriding the value of an inherited field.</p>
+</div>
+<div class="section" id="def">
+<h3><a class="toc-backref" href="#id19"><tt class="docutils literal"><span class="pre">def</span></tt></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-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> <a class="reference internal" href="#grammar-token-ObjectBody"><tt class="xref docutils literal"><span class="pre">ObjectBody</span></tt></a>
+</pre>
+<p>Defines a record whose name is given by the <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref std std-token docutils literal"><span class="pre">TokIdentifier</span></tt></a>. The
+fields of the record are inherited from the base classes and defined in the
+body.</p>
+<p>Special handling occurs if this <tt class="docutils literal"><span class="pre">def</span></tt> appears inside a <tt class="docutils literal"><span class="pre">multiclass</span></tt> or
+a <tt class="docutils literal"><span class="pre">foreach</span></tt>.</p>
+</div>
+<div class="section" id="defm">
+<h3><a class="toc-backref" href="#id20"><tt class="docutils literal"><span class="pre">defm</span></tt></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-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> ":" <a class="reference internal" href="#grammar-token-BaseClassListNE"><tt class="xref docutils literal"><span class="pre">BaseClassListNE</span></tt></a> ";"
+</pre>
+<p>Note that in the <a class="reference internal" href="#grammar-token-BaseClassList"><tt class="xref std std-token docutils literal"><span class="pre">BaseClassList</span></tt></a>, all of the <tt class="docutils literal"><span class="pre">multiclass</span></tt>‘s must
+precede any <tt class="docutils literal"><span class="pre">class</span></tt>‘s that appear.</p>
+</div>
+<div class="section" id="foreach">
+<h3><a class="toc-backref" href="#id21"><tt class="docutils literal"><span class="pre">foreach</span></tt></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-Declaration"><tt class="xref docutils literal"><span class="pre">Declaration</span></tt></a> "in" "{" <a class="reference internal" href="#grammar-token-Object"><tt class="xref docutils literal"><span class="pre">Object</span></tt></a>* "}"
+ | "foreach" <a class="reference internal" href="#grammar-token-Declaration"><tt class="xref docutils literal"><span class="pre">Declaration</span></tt></a> "in" <a class="reference internal" href="#grammar-token-Object"><tt class="xref docutils literal"><span class="pre">Object</span></tt></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>
+</div>
+<div class="section" id="top-level-let">
+<h3><a class="toc-backref" href="#id22">Top-Level <tt class="docutils literal"><span class="pre">let</span></tt></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"><tt class="xref docutils literal"><span class="pre">LetList</span></tt></a> "in" "{" <a class="reference internal" href="#grammar-token-Object"><tt class="xref docutils literal"><span class="pre">Object</span></tt></a>* "}"
+ | "let" <a class="reference internal" href="#grammar-token-LetList"><tt class="xref docutils literal"><span class="pre">LetList</span></tt></a> "in" <a class="reference internal" href="#grammar-token-Object"><tt class="xref docutils literal"><span class="pre">Object</span></tt></a>
+<strong id="grammar-token-LetList">LetList</strong> ::= <a class="reference internal" href="#grammar-token-LetItem"><tt class="xref docutils literal"><span class="pre">LetItem</span></tt></a> ("," <a class="reference internal" href="#grammar-token-LetItem"><tt class="xref docutils literal"><span class="pre">LetItem</span></tt></a>)*
+<strong id="grammar-token-LetItem">LetItem</strong> ::= <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> [<a class="reference internal" href="#grammar-token-RangeList"><tt class="xref docutils literal"><span class="pre">RangeList</span></tt></a>] "=" <a class="reference internal" href="#grammar-token-Value"><tt class="xref docutils literal"><span class="pre">Value</span></tt></a>
+</pre>
+<p>This is effectively equivalent to <tt class="docutils literal"><span class="pre">let</span></tt> 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="#id23"><tt class="docutils literal"><span class="pre">multiclass</span></tt></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"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a> [<a class="reference internal" href="#grammar-token-TemplateArgList"><tt class="xref docutils literal"><span class="pre">TemplateArgList</span></tt></a>]
+ [":" <a class="reference internal" href="#grammar-token-BaseMultiClassList"><tt class="xref docutils literal"><span class="pre">BaseMultiClassList</span></tt></a>] "{" <a class="reference internal" href="#grammar-token-MultiClassObject"><tt class="xref docutils literal"><span class="pre">MultiClassObject</span></tt></a>+ "}"
+<strong id="grammar-token-BaseMultiClassList">BaseMultiClassList</strong> ::= <a class="reference internal" href="#grammar-token-MultiClassID"><tt class="xref docutils literal"><span class="pre">MultiClassID</span></tt></a> ("," <a class="reference internal" href="#grammar-token-MultiClassID"><tt class="xref docutils literal"><span class="pre">MultiClassID</span></tt></a>)*
+<strong id="grammar-token-MultiClassID">MultiClassID </strong> ::= <a class="reference internal" href="#grammar-token-TokIdentifier"><tt class="xref docutils literal"><span class="pre">TokIdentifier</span></tt></a>
+<strong id="grammar-token-MultiClassObject">MultiClassObject </strong> ::= <a class="reference internal" href="#grammar-token-Def"><tt class="xref docutils literal"><span class="pre">Def</span></tt></a> | <a class="reference internal" href="#grammar-token-Defm"><tt class="xref docutils literal"><span class="pre">Defm</span></tt></a> | <a class="reference internal" href="#grammar-token-Let"><tt class="xref docutils literal"><span class="pre">Let</span></tt></a> | <a class="reference internal" href="#grammar-token-Foreach"><tt class="xref docutils literal"><span class="pre">Foreach</span></tt></a>
+</pre>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="../genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="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><a href="index.html" >TableGen</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGen/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGen/index.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGen/index.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGen/index.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,366 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="../_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '../',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="../_static/jquery.js"></script>
+ <script type="text/javascript" src="../_static/underscore.js"></script>
+ <script type="text/javascript" src="../_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="../index.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">
+ <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">
+
+ <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"><em>The LLVM Target-Independent Code Generator</em></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 <tt class="docutils literal"><span class="pre">llvm/utils/emacs</span></tt> and
+<tt class="docutils literal"><span class="pre">llvm/utils/vim</span></tt> 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, <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt>
+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 ‘<tt class="docutils literal"><span class="pre">llvm-tblgen</span> <span class="pre">-help</span></tt>‘ 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
+<tt class="docutils literal"><span class="pre">-print-enums</span></tt> option:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </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,
+
+<span class="nv">$ </span>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.</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.</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 <tt class="docutils literal"><span class="pre">X86.td</span></tt> file prints
+this (at the time of this writing):</p>
+<div class="highlight-text"><div class="highlight"><pre>...
+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 <tt class="docutils literal"><span class="pre">add</span></tt> instruction
+of the x86 architecture. <tt class="docutils literal"><span class="pre">def</span> <span class="pre">ADD32rr</span></tt> defines a record named
+<tt class="docutils literal"><span class="pre">ADD32rr</span></tt>, 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">I</span></tt> (extended from the custom
+class <tt class="docutils literal"><span class="pre">X86Inst</span></tt>), 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>
+<p>Each <tt class="docutils literal"><span class="pre">def</span></tt> record has a special entry called “NAME”. This is the name of the
+record (“<tt class="docutils literal"><span class="pre">ADD32rr</span></tt>” above). In the general case <tt class="docutils literal"><span class="pre">def</span></tt> names can be formed
+from various kinds of string processing expressions and <tt class="docutils literal"><span class="pre">NAME</span></tt> resolves to the
+final value obtained after resolving all of those expressions. The user may
+refer to <tt class="docutils literal"><span class="pre">NAME</span></tt> anywhere she desires to use the ultimate name of the <tt class="docutils literal"><span class="pre">def</span></tt>.
+<tt class="docutils literal"><span class="pre">NAME</span></tt> should not be defined anywhere else in user code to avoid conflicts.</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 ‘<tt class="docutils literal"><span class="pre">def</span></tt>‘ keyword.</p>
+<div class="highlight-text"><div class="highlight"><pre>def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
+ "Enable ARMv8 FP">;
+</pre></div>
+</div>
+<p>In this example, FeatureFPARMv8 is <tt class="docutils literal"><span class="pre">SubtargetFeature</span></tt> 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 <tt class="docutils literal"><span class="pre">include/llvm/Target</span></tt>.</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"><div class="highlight"><pre>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"><div class="highlight"><pre>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"><em>TableGen Language Introduction</em></a> for more generic
+information on the usage of the language, and the
+<a class="reference internal" href="LangRef.html"><em>TableGen Language Reference</em></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 <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt> 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">
+ <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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TableGenFundamentals.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TableGenFundamentals.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TableGenFundamentals.html (added)
+++ www-releases/trunk/6.0.1/docs/TableGenFundamentals.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,105 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>TableGen Fundamentals — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.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">
+ <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">
+
+ <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"><em>TableGen</em></a>. Please, change your links to
+that page.</p>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TestSuiteMakefileGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TestSuiteMakefileGuide.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TestSuiteMakefileGuide.html (added)
+++ www-releases/trunk/6.0.1/docs/TestSuiteMakefileGuide.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,414 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM test-suite Guide — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="up" title="LLVM Testing Infrastructure Guide" href="TestingGuide.html" />
+ <link rel="next" title="LLVM Tutorial: Table of Contents" href="tutorial/index.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">
+ <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="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><a href="TestingGuide.html" accesskey="U">LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+
+
+ <div class="document">
+ <div class="documentwrapper">
+ <div class="body">
+
+ <div class="section" id="llvm-test-suite-guide">
+<h1>LLVM test-suite Guide<a class="headerlink" href="#llvm-test-suite-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="id1">Overview</a></li>
+<li><a class="reference internal" href="#test-suite-structure" id="id2">Test suite Structure</a></li>
+<li><a class="reference internal" href="#running-the-test-suite-via-cmake" id="id3">Running the test suite via CMake</a></li>
+<li><a class="reference internal" href="#running-the-test-suite-via-makefiles-deprecated" id="id4">Running the test suite via Makefiles (deprecated)</a><ul>
+<li><a class="reference internal" href="#configuring-external-tests" id="id5">Configuring External Tests</a></li>
+<li><a class="reference internal" href="#running-different-tests" id="id6">Running different tests</a></li>
+<li><a class="reference internal" href="#generating-test-output" id="id7">Generating test output</a></li>
+<li><a class="reference internal" href="#writing-custom-tests-for-the-test-suite" id="id8">Writing custom tests for the test suite</a></li>
+</ul>
+</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>This document describes the features of the Makefile-based LLVM
+test-suite as well as the cmake based replacement. This way of interacting
+with the test-suite is deprecated in favor of running the test-suite using LNT,
+but may continue to prove useful for some users. See the Testing
+Guide’s <a class="reference internal" href="TestingGuide.html#test-suite-quickstart"><em>test-suite Quickstart</em></a> section for more
+information.</p>
+</div>
+<div class="section" id="test-suite-structure">
+<h2><a class="toc-backref" href="#id2">Test suite Structure</a><a class="headerlink" href="#test-suite-structure" title="Permalink to this headline">¶</a></h2>
+<p>The <tt class="docutils literal"><span class="pre">test-suite</span></tt> module contains a number of programs that can be
+compiled with LLVM and executed. These programs are compiled using the
+native compiler and various LLVM backends. The output from the program
+compiled with the native compiler is assumed correct; the results from
+the other programs are compared to the native program output and pass if
+they match.</p>
+<p>When executing tests, it is usually a good idea to start out with a
+subset of the available tests or programs. This makes test run times
+smaller at first and later on this is useful to investigate individual
+test failures. To run some test only on a subset of programs, simply
+change directory to the programs you want tested and run <tt class="docutils literal"><span class="pre">gmake</span></tt>
+there. Alternatively, you can run a different test using the <tt class="docutils literal"><span class="pre">TEST</span></tt>
+variable to change what tests or run on the selected programs (see below
+for more info).</p>
+<p>In addition for testing correctness, the <tt class="docutils literal"><span class="pre">test-suite</span></tt> directory also
+performs timing tests of various LLVM optimizations. It also records
+compilation times for the compilers and the JIT. This information can be
+used to compare the effectiveness of LLVM’s optimizations and code
+generation.</p>
+<p><tt class="docutils literal"><span class="pre">test-suite</span></tt> tests are divided into three types of tests: MultiSource,
+SingleSource, and External.</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/SingleSource</span></tt></p>
+<p>The SingleSource directory contains test programs that are only a
+single source file in size. These are usually small benchmark
+programs or small programs that calculate a particular value. Several
+such programs are grouped together in each directory.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/MultiSource</span></tt></p>
+<p>The MultiSource directory contains subdirectories which contain
+entire programs with multiple source files. Large benchmarks and
+whole applications go here.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/External</span></tt></p>
+<p>The External directory contains Makefiles for building code that is
+external to (i.e., not distributed with) LLVM. The most prominent
+members of this directory are the SPEC 95 and SPEC 2000 benchmark
+suites. The <tt class="docutils literal"><span class="pre">External</span></tt> directory does not contain these actual
+tests, but only the Makefiles that know how to properly compile these
+programs from somewhere else. The presence and location of these
+external programs is configured by the test-suite <tt class="docutils literal"><span class="pre">configure</span></tt>
+script.</p>
+</li>
+</ul>
+<p>Each tree is then subdivided into several categories, including
+applications, benchmarks, regression tests, code that is strange
+grammatically, etc. These organizations should be relatively self
+explanatory.</p>
+<p>Some tests are known to fail. Some are bugs that we have not fixed yet;
+others are features that we haven’t added yet (or may never add). In the
+regression tests, the result for such tests will be XFAIL (eXpected
+FAILure). In this way, you can tell the difference between an expected
+and unexpected failure.</p>
+<p>The tests in the test suite have no such feature at this time. If the
+test passes, only warnings and other miscellaneous output will be
+generated. If a test fails, a large <program> FAILED message will be
+displayed. This will help you separate benign warnings from actual test
+failures.</p>
+</div>
+<div class="section" id="running-the-test-suite-via-cmake">
+<h2><a class="toc-backref" href="#id3">Running the test suite via CMake</a><a class="headerlink" href="#running-the-test-suite-via-cmake" title="Permalink to this headline">¶</a></h2>
+<p>To run the test suite, you need to use the following steps:</p>
+<ol class="arabic">
+<li><p class="first">The test suite uses the lit test runner to run the test-suite,
+you need to have lit installed first. Check out LLVM and install lit:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+% <span class="nb">cd </span>llvm/utils/lit
+% sudo python setup.py install <span class="c"># Or without sudo, install in virtual-env.</span>
+running install
+running bdist_egg
+running egg_info
+writing lit.egg-info/PKG-INFO
+...
+% lit --version
+lit 0.5.0dev
+</pre></div>
+</div>
+</li>
+<li><p class="first">Check out the <tt class="docutils literal"><span class="pre">test-suite</span></tt> module with:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% svn co http://llvm.org/svn/llvm-project/test-suite/trunk <span class="nb">test</span>-suite
+</pre></div>
+</div>
+</li>
+<li><p class="first">Use CMake to configure the test suite in a new directory. You cannot build
+the test suite in the source tree.</p>
+<div class="highlight-bash"><div class="highlight"><pre>% mkdir <span class="nb">test</span>-suite-build
+% <span class="nb">cd test</span>-suite-build
+% cmake ../test-suite
+</pre></div>
+</div>
+</li>
+<li><p class="first">Build the benchmarks, using the makefiles CMake generated.</p>
+</li>
+</ol>
+<div class="highlight-bash"><div class="highlight"><pre>% make
+Scanning dependencies of target timeit-target
+<span class="o">[</span> 0%<span class="o">]</span> Building C object tools/CMakeFiles/timeit-target.dir/timeit.c.o
+<span class="o">[</span> 0%<span class="o">]</span> Linking C executable timeit-target
+<span class="o">[</span> 0%<span class="o">]</span> Built target timeit-target
+Scanning dependencies of target fpcmp-host
+<span class="o">[</span> 0%<span class="o">]</span> <span class="o">[</span>TEST_SUITE_HOST_CC<span class="o">]</span> Building host executable fpcmp
+<span class="o">[</span> 0%<span class="o">]</span> Built target fpcmp-host
+Scanning dependencies of target timeit-host
+<span class="o">[</span> 0%<span class="o">]</span> <span class="o">[</span>TEST_SUITE_HOST_CC<span class="o">]</span> Building host executable timeit
+<span class="o">[</span> 0%<span class="o">]</span> Built target timeit-host
+</pre></div>
+</div>
+<ol class="arabic simple">
+<li>Run the tests with lit:</li>
+</ol>
+<div class="highlight-bash"><div class="highlight"><pre>% lit -v -j 1 . -o results.json
+-- Testing: 474 tests, 1 threads --
+PASS: <span class="nb">test</span>-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test <span class="o">(</span>1 of 474<span class="o">)</span>
+********** TEST <span class="s1">'test-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test'</span> RESULTS **********
+compile_time: 0.2192
+exec_time: 0.0462
+<span class="nb">hash</span>: <span class="s2">"59620e187c6ac38b36382685ccd2b63b"</span>
+size: 83348
+**********
+PASS: <span class="nb">test</span>-suite :: MultiSource/Applications/ALAC/encode/alacconvert-encode.test <span class="o">(</span>2 of 474<span class="o">)</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="running-the-test-suite-via-makefiles-deprecated">
+<h2><a class="toc-backref" href="#id4">Running the test suite via Makefiles (deprecated)</a><a class="headerlink" href="#running-the-test-suite-via-makefiles-deprecated" 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"><tt class="docutils literal"><span class="pre">cd</span></tt> into the <tt class="docutils literal"><span class="pre">llvm/projects</span></tt> directory in your source tree.</p>
+</li>
+<li><p class="first">Check out the <tt class="docutils literal"><span class="pre">test-suite</span></tt> module with:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% svn co http://llvm.org/svn/llvm-project/test-suite/trunk <span class="nb">test</span>-suite
+</pre></div>
+</div>
+<p>This will get the test suite into <tt class="docutils literal"><span class="pre">llvm/projects/test-suite</span></tt>.</p>
+</li>
+<li><p class="first">Configure and build <tt class="docutils literal"><span class="pre">llvm</span></tt>.</p>
+</li>
+<li><p class="first">Configure and build <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt>.</p>
+</li>
+<li><p class="first">Install <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt> somewhere.</p>
+</li>
+<li><p class="first"><em>Re-configure</em> <tt class="docutils literal"><span class="pre">llvm</span></tt> 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 <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt>
+you just built in your path, or (2) specify the directory where your
+just-built <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt> is installed using
+<tt class="docutils literal"><span class="pre">--with-llvmgccdir=$LLVM_GCC_DIR</span></tt>.</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"><div class="highlight"><pre>% <span class="nb">cd</span> <span class="nv">$LLVM_OBJ_ROOT</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 <tt class="docutils literal"><span class="pre">$LLVM_GCC_DIR</span></tt> 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"><div class="highlight"><pre>% <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 class="section" id="configuring-external-tests">
+<h3><a class="toc-backref" href="#id5">Configuring External Tests</a><a class="headerlink" href="#configuring-external-tests" title="Permalink to this headline">¶</a></h3>
+<p>In order to run the External tests in the <tt class="docutils literal"><span class="pre">test-suite</span></tt> module, you
+must specify <em>–with-externals</em>. This must be done during the
+<em>re-configuration</em> step (see above), and the <tt class="docutils literal"><span class="pre">llvm</span></tt> re-configuration
+must recognize the previously-built <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt>. 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 <<tt class="docutils literal"><span class="pre">directory</span></tt>>. If
+<tt class="docutils literal"><span class="pre">directory</span></tt> is left unspecified, <tt class="docutils literal"><span class="pre">configure</span></tt> uses the default value
+<tt class="docutils literal"><span class="pre">/home/vadve/shared/benchmarks/speccpu2000/benchspec</span></tt>. 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
+<tt class="docutils literal"><span class="pre">configure</span></tt>.</p>
+</div>
+<div class="section" id="running-different-tests">
+<h3><a class="toc-backref" href="#id6">Running different tests</a><a class="headerlink" href="#running-different-tests" title="Permalink to this headline">¶</a></h3>
+<p>In addition to the regular “whole program” tests, the <tt class="docutils literal"><span class="pre">test-suite</span></tt>
+module also provides a mechanism for compiling the programs in different
+ways. If the variable TEST is defined on the <tt class="docutils literal"><span class="pre">gmake</span></tt> command line, the
+test system will include a Makefile named
+<tt class="docutils literal"><span class="pre">TEST.<value</span> <span class="pre">of</span> <span class="pre">TEST</span> <span class="pre">variable>.Makefile</span></tt>. This Makefile can modify
+build rules to yield different results.</p>
+<p>For example, the LLVM nightly tester uses <tt class="docutils literal"><span class="pre">TEST.nightly.Makefile</span></tt> to
+create the nightly test reports. To run the nightly tests, run
+<tt class="docutils literal"><span class="pre">gmake</span> <span class="pre">TEST=nightly</span></tt>.</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">
+<h3><a class="toc-backref" href="#id7">Generating test output</a><a class="headerlink" href="#generating-test-output" title="Permalink to this headline">¶</a></h3>
+<p>There are a number of ways to run the tests and generate output. The
+most simple one is simply running <tt class="docutils literal"><span class="pre">gmake</span></tt> 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 <tt class="docutils literal"><span class="pre">gmake</span> <span class="pre">TEST=sometest</span> <span class="pre">test</span></tt>, which runs the
+specified test and usually adds per-program summaries to the output
+(depending on which sometest you use). For example, the <tt class="docutils literal"><span class="pre">nightly</span></tt> 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 <tt class="docutils literal"><span class="pre">report</span></tt> and <tt class="docutils literal"><span class="pre">report.format</span></tt> targets (where
+<tt class="docutils literal"><span class="pre">format</span></tt> is one of <tt class="docutils literal"><span class="pre">html</span></tt>, <tt class="docutils literal"><span class="pre">csv</span></tt>, <tt class="docutils literal"><span class="pre">text</span></tt> or <tt class="docutils literal"><span class="pre">graphs</span></tt>). The
+exact contents of the report are dependent on which <tt class="docutils literal"><span class="pre">TEST</span></tt> you are
+running, but the text results are always shown at the end of the run and
+the results are always stored in the <tt class="docutils literal"><span class="pre">report.<type>.format</span></tt> file (when
+running with <tt class="docutils literal"><span class="pre">TEST=<type></span></tt>). The <tt class="docutils literal"><span class="pre">report</span></tt> also generate a file
+called <tt class="docutils literal"><span class="pre">report.<type>.raw.out</span></tt> containing the output of the entire
+test run.</p>
+</div>
+<div class="section" id="writing-custom-tests-for-the-test-suite">
+<h3><a class="toc-backref" href="#id8">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></h3>
+<p>Assuming you can run the test suite, (e.g.
+“<tt class="docutils literal"><span class="pre">gmake</span> <span class="pre">TEST=nightly</span> <span class="pre">report</span></tt>” 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
+“<tt class="docutils literal"><span class="pre">test-suite/TEST.XXX.Makefile</span></tt>” fragment (where XXX is the name of
+your test) and a “<tt class="docutils literal"><span class="pre">test-suite/TEST.XXX.report</span></tt>” 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"><div class="highlight"><pre>% <span class="nb">cd </span>llvm/projects/test-suite/MultiSource/Benchmarks <span class="c"># 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-python"><pre>Name | total | #exit |
+...
+FreeBench/analyzer/analyzer | 51 | 6 |
+FreeBench/fourinarow/fourinarow | 1 | 1 |
+FreeBench/neural/neural | 19 | 9 |
+FreeBench/pifft/pifft | 5 | 3 |
+MallocBench/cfrac/cfrac | 1 | * |
+MallocBench/espresso/espresso | 52 | 12 |
+MallocBench/gs/gs | 4 | * |
+Prolangs-C/TimberWolfMC/timberwolfmc | 302 | * |
+Prolangs-C/agrep/agrep | 33 | 12 |
+Prolangs-C/allroots/allroots | * | * |
+Prolangs-C/assembler/assembler | 47 | * |
+Prolangs-C/bison/mybison | 74 | * |
+...</pre>
+</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 <tt class="docutils literal"><span class="pre">test-suite/TEST.libcalls.*</span></tt>. The format is
+pretty simple: the Makefile indicates how to run the test (in this case,
+“<tt class="docutils literal"><span class="pre">opt</span> <span class="pre">-simplify-libcalls</span> <span class="pre">-stats</span></tt>”), 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>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="tutorial/index.html" title="LLVM Tutorial: Table of Contents"
+ >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><a href="TestingGuide.html" >LLVM Testing Infrastructure Guide</a> »</li>
+ </ul>
+ </div>
+ <div class="footer">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TestingGuide.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TestingGuide.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TestingGuide.html (added)
+++ www-releases/trunk/6.0.1/docs/TestingGuide.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,665 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>LLVM Testing Infrastructure Guide — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="LLVM test-suite Guide" href="TestSuiteMakefileGuide.html" />
+ <link rel="prev" title="Code Reviews with Phabricator" href="Phabricator.html" />
+<style type="text/css">
+ table.right { float: right; margin-left: 20px; }
+ table.right td { border: 1px solid #ccc; }
+</style>
+
+ </head>
+ <body>
+<div class="logo">
+ <a href="index.html">
+ <img src="_static/logo.png"
+ alt="LLVM Logo" width="250" height="88"/></a>
+</div>
+
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ accesskey="I">index</a></li>
+ <li class="right" >
+ <a href="TestSuiteMakefileGuide.html" title="LLVM 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">
+
+ <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="id5">Overview</a></li>
+<li><a class="reference internal" href="#requirements" id="id6">Requirements</a></li>
+<li><a class="reference internal" href="#llvm-testing-infrastructure-organization" id="id7">LLVM testing infrastructure organization</a><ul>
+<li><a class="reference internal" href="#regression-tests" id="id8">Regression tests</a></li>
+<li><a class="reference internal" href="#test-suite" id="id9"><tt class="docutils literal"><span class="pre">test-suite</span></tt></a></li>
+<li><a class="reference internal" href="#debugging-information-tests" id="id10">Debugging Information tests</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#quick-start" id="id11">Quick start</a><ul>
+<li><a class="reference internal" href="#id1" id="id12">Regression tests</a></li>
+<li><a class="reference internal" href="#id2" id="id13">Debugging Information tests</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#regression-test-structure" id="id14">Regression test structure</a><ul>
+<li><a class="reference internal" href="#writing-new-regression-tests" id="id15">Writing new regression tests</a></li>
+<li><a class="reference internal" href="#extra-files" id="id16">Extra files</a></li>
+<li><a class="reference internal" href="#fragile-tests" id="id17">Fragile tests</a></li>
+<li><a class="reference internal" href="#platform-specific-tests" id="id18">Platform-Specific Tests</a></li>
+<li><a class="reference internal" href="#constraining-test-execution" id="id19">Constraining test execution</a></li>
+<li><a class="reference internal" href="#substitutions" id="id20">Substitutions</a></li>
+<li><a class="reference internal" href="#options" id="id21">Options</a></li>
+<li><a class="reference internal" href="#other-features" id="id22">Other Features</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#test-suite-overview" id="id23"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Overview</a><ul>
+<li><a class="reference internal" href="#test-suite-quickstart" id="id24"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Quickstart</a></li>
+<li><a class="reference internal" href="#test-suite-makefiles" id="id25"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Makefiles</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="toctree-wrapper compound">
+</div>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id5">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="#id6">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>
+<p>If you intend to run the <a class="reference internal" href="#test-suite-overview"><em>test-suite</em></a>, you will also
+need a development version of zlib (zlib1g-dev is known to work on several Linux
+distributions).</p>
+</div>
+<div class="section" id="llvm-testing-infrastructure-organization">
+<h2><a class="toc-backref" href="#id7">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 two major categories of tests:
+regression tests and whole programs. The regression tests are contained
+inside the LLVM repository itself under <tt class="docutils literal"><span class="pre">llvm/test</span></tt> 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 <tt class="docutils literal"><span class="pre">test-suite</span></tt> 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="regression-tests">
+<h3><a class="toc-backref" href="#id8">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"><em>Lit</em></a> testing tool (which is part of LLVM), and
+are located in the <tt class="docutils literal"><span class="pre">llvm/test</span></tt> 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="#id9"><tt class="docutils literal"><span class="pre">test-suite</span></tt></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 <tt class="docutils literal"><span class="pre">test-suite</span></tt> Subversion module.</p>
+</div>
+<div class="section" id="debugging-information-tests">
+<h3><a class="toc-backref" href="#id10">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
+<tt class="docutils literal"><span class="pre">debuginfo-tests</span></tt> Subversion module.</p>
+</div>
+</div>
+<div class="section" id="quick-start">
+<h2><a class="toc-backref" href="#id11">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
+regressions tests are in the main “llvm” module under the directory
+<tt class="docutils literal"><span class="pre">llvm/test</span></tt> (so you get these tests for free with the main LLVM tree).
+Use <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check-all</span></tt> to run the regression tests after building LLVM.</p>
+<p>The more comprehensive test suite that includes whole programs in C and C++
+is in the <tt class="docutils literal"><span class="pre">test-suite</span></tt> module. See <a class="reference internal" href="#test-suite-quickstart"><em>test-suite Quickstart</em></a> for more information on running these tests.</p>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id12">Regression tests</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
+<p>To run all of the LLVM regression tests use the check-llvm target:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% make check-llvm
+</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"><div class="highlight"><pre>% make check-all
+</pre></div>
+</div>
+<p>To run the tests with Valgrind (Memcheck by default), use the <tt class="docutils literal"><span class="pre">LIT_ARGS</span></tt> make
+variable to pass the required options to lit. For example, you can use:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% 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 <tt class="docutils literal"><span class="pre">llvm-lit</span></tt>
+script which is built as part of LLVM. For example, to run the
+<tt class="docutils literal"><span class="pre">Integer/BitPacked.ll</span></tt> test by itself you can run:</p>
+<div class="highlight-bash"><div class="highlight"><pre>% 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"><div class="highlight"><pre>% llvm-lit ~/llvm/test/CodeGen/ARM
+</pre></div>
+</div>
+<p>For more information on using the <strong class="program">lit</strong> tool, see <tt class="docutils literal"><span class="pre">llvm-lit</span> <span class="pre">--help</span></tt>
+or the <a class="reference internal" href="CommandGuide/lit.html"><em>lit man page</em></a>.</p>
+</div>
+<div class="section" id="id2">
+<h3><a class="toc-backref" href="#id13">Debugging Information tests</a><a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h3>
+<p>To run debugging information tests simply checkout the tests inside
+clang/test directory.</p>
+<div class="highlight-bash"><div class="highlight"><pre>% <span class="nb">cd </span>clang/test
+% svn co http://llvm.org/svn/llvm-project/debuginfo-tests/trunk debuginfo-tests
+</pre></div>
+</div>
+<p>These tests are already set up to run as part of clang regression tests.</p>
+</div>
+</div>
+<div class="section" id="regression-test-structure">
+<h2><a class="toc-backref" href="#id14">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
+<tt class="docutils literal"><span class="pre">llvm/test</span></tt> 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="#id15">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 <tt class="docutils literal"><span class="pre">configure</span></tt>
+and is written to a file, <tt class="docutils literal"><span class="pre">test/lit.site.cfg</span></tt> in the build directory.
+The <tt class="docutils literal"><span class="pre">llvm/test</span></tt> Makefile does this work for you.</p>
+<p>In order for the regression tests to work, each directory of tests must
+have a <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt> 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 <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt> from
+another directory to get running. The standard <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt> simply
+specifies which files to look in for tests. Any directory that contains
+only directories does not need the <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt> file. Read the <a class="reference internal" href="CommandGuide/lit.html"><em>Lit
+documentation</em></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 <tt class="docutils literal"><span class="pre">RUN</span></tt> 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
+<tt class="docutils literal"><span class="pre">$(LLVM_OBJ_ROOT)/$(BuildMode)/bin)</span></tt>. 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 <tt class="docutils literal"><span class="pre">\</span></tt>. 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 <tt class="docutils literal"><span class="pre">\</span></tt> are concatenated until a RUN line that doesn’t end in
+<tt class="docutils literal"><span class="pre">\</span></tt> 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 <tt class="docutils literal"><span class="pre">.ll</span></tt> file:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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"><em>FileCheck tool</em></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="#id16">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 <tt class="docutils literal"><span class="pre">RUN:</span></tt>
+lines, the idiomatic place to put them is in a subdirectory <tt class="docutils literal"><span class="pre">Inputs</span></tt>.
+You can then refer to the extra files as <tt class="docutils literal"><span class="pre">%S/Inputs/foo.bar</span></tt>.</p>
+<p>For example, consider <tt class="docutils literal"><span class="pre">test/Linker/ident.ll</span></tt>. The directory structure is
+as follows:</p>
+<div class="highlight-python"><pre>test/
+ Linker/
+ ident.ll
+ Inputs/
+ ident.a.ll
+ ident.b.ll</pre>
+</div>
+<p>For convenience, these are the contents:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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-Anonymous">!0</span><span class="p">,</span> <span class="nv-Anonymous">!1</span><span class="p">}</span>
+<span class="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-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-Anonymous">!0</span><span class="p">}</span>
+<span class="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, <tt class="docutils literal"><span class="pre">ident.ll</span></tt> is just a dummy file that doesn’t
+actually participate in the test besides holding the <tt class="docutils literal"><span class="pre">RUN:</span></tt> lines.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Some existing tests use <tt class="docutils literal"><span class="pre">RUN:</span> <span class="pre">true</span></tt> in extra files instead of just
+putting the extra files in an <tt class="docutils literal"><span class="pre">Inputs/</span></tt> directory. This pattern is
+deprecated.</p>
+</div>
+</div>
+<div class="section" id="fragile-tests">
+<h3><a class="toc-backref" href="#id17">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 <tt class="docutils literal"><span class="pre">ModuleID</span></tt>:</p>
+<div class="highlight-console"><div class="highlight"><pre><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><tt class="docutils literal"><span class="pre">ModuleID</span></tt> can unexpectedly match against <tt class="docutils literal"><span class="pre">CHECK</span></tt> lines. For example:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">download</span></tt> directory.</p>
+<p>To make your tests robust, always use <tt class="docutils literal"><span class="pre">opt</span> <span class="pre">...</span> <span class="pre"><</span> <span class="pre">%s</span></tt> in the RUN line.
+<strong class="program">opt</strong> does not output a <tt class="docutils literal"><span class="pre">ModuleID</span></tt> when input comes from stdin.</p>
+</div>
+<div class="section" id="platform-specific-tests">
+<h3><a class="toc-backref" href="#id18">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 <tt class="docutils literal"><span class="pre">x86_64</span></tt> 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 <tt class="docutils literal"><span class="pre">test/CodeGen/ARM</span></tt> and so on. Those directories contain a special
+<tt class="docutils literal"><span class="pre">lit</span></tt> 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 <tt class="docutils literal"><span class="pre">test/CodeGen/ARM</span></tt>, the <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt> is:</p>
+<div class="highlight-python"><div class="highlight"><pre><span class="n">config</span><span class="o">.</span><span class="n">suffixes</span> <span class="o">=</span> <span class="p">[</span><span class="s">'.ll'</span><span class="p">,</span> <span class="s">'.c'</span><span class="p">,</span> <span class="s">'.cpp'</span><span class="p">,</span> <span class="s">'.test'</span><span class="p">]</span>
+<span class="k">if</span> <span class="ow">not</span> <span class="s">'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 <tt class="docutils literal"><span class="pre">AVX2</span></tt>.</p>
+<p>For instance, <tt class="docutils literal"><span class="pre">test/CodeGen/X86/psubus.ll</span></tt> tests three sub-architecture
+variants:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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"><div class="highlight"><pre><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="#id19">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 <tt class="docutils literal"><span class="pre">REQUIRES</span></tt>
+and <tt class="docutils literal"><span class="pre">UNSUPPORTED</span></tt> 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 <tt class="docutils literal"><span class="pre">XFAIL</span></tt> to mark a test as an expected failure.
+An <tt class="docutils literal"><span class="pre">XFAIL</span></tt> test will be successful if its execution fails, and
+will be a failure if its execution succeeds.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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><tt class="docutils literal"><span class="pre">REQUIRES</span></tt> and <tt class="docutils literal"><span class="pre">UNSUPPORTED</span></tt> and <tt class="docutils literal"><span class="pre">XFAIL</span></tt> all accept a comma-separated
+list of boolean expressions. The values in each expression may be:</p>
+<ul class="simple">
+<li>Features added to <tt class="docutils literal"><span class="pre">config.available_features</span></tt> by
+configuration files such as <tt class="docutils literal"><span class="pre">lit.cfg</span></tt>.</li>
+<li>Substrings of the target triple (<tt class="docutils literal"><span class="pre">UNSUPPORTED</span></tt> and <tt class="docutils literal"><span class="pre">XFAIL</span></tt> only).</li>
+</ul>
+<div class="line-block">
+<div class="line"><tt class="docutils literal"><span class="pre">REQUIRES</span></tt> enables the test if all expressions are true.</div>
+<div class="line"><tt class="docutils literal"><span class="pre">UNSUPPORTED</span></tt> disables the test if any expression is true.</div>
+<div class="line"><tt class="docutils literal"><span class="pre">XFAIL</span></tt> expects the test to fail if any expression is true.</div>
+</div>
+<p>As a special case, <tt class="docutils literal"><span class="pre">XFAIL:</span> <span class="pre">*</span></tt> is expected to fail everywhere.</p>
+<div class="highlight-llvm"><div class="highlight"><pre><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="#id20">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><tt class="docutils literal"><span class="pre">%%</span></tt></dt>
+<dd>Replaced by a single <tt class="docutils literal"><span class="pre">%</span></tt>. This allows escaping other substitutions.</dd>
+<dt><tt class="docutils literal"><span class="pre">%s</span></tt></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: <tt class="docutils literal"><span class="pre">/home/user/llvm/test/MC/ELF/foo_test.s</span></tt></p>
+</dd>
+<dt><tt class="docutils literal"><span class="pre">%S</span></tt></dt>
+<dd><p class="first">Directory path to the test case’s source.</p>
+<p class="last">Example: <tt class="docutils literal"><span class="pre">/home/user/llvm/test/MC/ELF</span></tt></p>
+</dd>
+<dt><tt class="docutils literal"><span class="pre">%t</span></tt></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: <tt class="docutils literal"><span class="pre">/home/user/llvm.build/test/MC/ELF/Output/foo_test.s.tmp</span></tt></p>
+</dd>
+<dt><tt class="docutils literal"><span class="pre">%T</span></tt></dt>
+<dd><p class="first">Directory of <tt class="docutils literal"><span class="pre">%t</span></tt>.</p>
+<p class="last">Example: <tt class="docutils literal"><span class="pre">/home/user/llvm.build/test/MC/ELF/Output</span></tt></p>
+</dd>
+</dl>
+<p><tt class="docutils literal"><span class="pre">%{pathsep}</span></tt></p>
+<blockquote>
+<div>Expands to the path separator, i.e. <tt class="docutils literal"><span class="pre">:</span></tt> (or <tt class="docutils literal"><span class="pre">;</span></tt> on Windows).</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">%/s,</span> <span class="pre">%/S,</span> <span class="pre">%/t,</span> <span class="pre">%/T:</span></tt></p>
+<blockquote>
+<div><p>Act like the corresponding substitution above but replace any <tt class="docutils literal"><span class="pre">\</span></tt>
+character with a <tt class="docutils literal"><span class="pre">/</span></tt>. This is useful to normalize path separators.</p>
+<blockquote>
+<div><p>Example: <tt class="docutils literal"><span class="pre">%s:</span> <span class="pre">C:\Desktop</span> <span class="pre">Files/foo_test.s.tmp</span></tt></p>
+<p>Example: <tt class="docutils literal"><span class="pre">%/s:</span> <span class="pre">C:/Desktop</span> <span class="pre">Files/foo_test.s.tmp</span></tt></p>
+</div></blockquote>
+</div></blockquote>
+<p><tt class="docutils literal"><span class="pre">%:s,</span> <span class="pre">%:S,</span> <span class="pre">%:t,</span> <span class="pre">%:T:</span></tt></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: <tt class="docutils literal"><span class="pre">%s:</span> <span class="pre">C:\Desktop</span> <span class="pre">Files\foo_test.s.tmp</span></tt></p>
+<p>Example: <tt class="docutils literal"><span class="pre">%:s:</span> <span class="pre">C\Desktop</span> <span class="pre">Files\foo_test.s.tmp</span></tt></p>
+</div></blockquote>
+</div></blockquote>
+<p><strong>LLVM-specific substitutions:</strong></p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><span class="pre">%shlibext</span></tt></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: <tt class="docutils literal"><span class="pre">.so</span></tt> (Linux), <tt class="docutils literal"><span class="pre">.dylib</span></tt> (OS X), <tt class="docutils literal"><span class="pre">.dll</span></tt> (Windows)</p>
+</dd>
+<dt><tt class="docutils literal"><span class="pre">%exeext</span></tt></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: <tt class="docutils literal"><span class="pre">.exe</span></tt> (Windows), empty on Linux.</p>
+</dd>
+<dt><tt class="docutils literal"><span class="pre">%(line)</span></tt>, <tt class="docutils literal"><span class="pre">%(line+<number>)</span></tt>, <tt class="docutils literal"><span class="pre">%(line-<number>)</span></tt></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><tt class="docutils literal"><span class="pre">%clang</span></tt></dt>
+<dd>Invokes the Clang driver.</dd>
+<dt><tt class="docutils literal"><span class="pre">%clang_cpp</span></tt></dt>
+<dd>Invokes the Clang driver for C++.</dd>
+<dt><tt class="docutils literal"><span class="pre">%clang_cl</span></tt></dt>
+<dd>Invokes the CL-compatible Clang driver.</dd>
+<dt><tt class="docutils literal"><span class="pre">%clangxx</span></tt></dt>
+<dd>Invokes the G++-compatible Clang driver.</dd>
+<dt><tt class="docutils literal"><span class="pre">%clang_cc1</span></tt></dt>
+<dd>Invokes the Clang frontend.</dd>
+<dt><tt class="docutils literal"><span class="pre">%itanium_abi_triple</span></tt>, <tt class="docutils literal"><span class="pre">%ms_abi_triple</span></tt></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
+<tt class="docutils literal"><span class="pre">i686-pc-win32</span></tt> target, <tt class="docutils literal"><span class="pre">%itanium_abi_triple</span></tt> will expand to
+<tt class="docutils literal"><span class="pre">i686-pc-mingw32</span></tt>. 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 <tt class="docutils literal"><span class="pre">test/lit.cfg</span></tt> or <tt class="docutils literal"><span class="pre">lit.local.cfg</span></tt>.</p>
+</div>
+<div class="section" id="options">
+<h3><a class="toc-backref" href="#id21">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><tt class="docutils literal"><span class="pre">llc</span></tt>, <tt class="docutils literal"><span class="pre">opt</span></tt>, ...</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><tt class="docutils literal"><span class="pre">run_long_tests</span></tt></dt>
+<dd>Enable the execution of long running tests.</dd>
+<dt><tt class="docutils literal"><span class="pre">llvm_site_config</span></tt></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="#id22">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><tt class="docutils literal"><span class="pre">not</span></tt></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
+<tt class="docutils literal"><span class="pre">PR[0-9]+</span></tt>. 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 class="section" id="test-suite-overview">
+<span id="id3"></span><h2><a class="toc-backref" href="#id23"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Overview</a><a class="headerlink" href="#test-suite-overview" title="Permalink to this headline">¶</a></h2>
+<p>The <tt class="docutils literal"><span class="pre">test-suite</span></tt> module contains a number of programs that can be
+compiled and executed. The <tt class="docutils literal"><span class="pre">test-suite</span></tt> includes reference outputs for
+all of the programs, so that the output of the executed program can be
+checked for correctness.</p>
+<p><tt class="docutils literal"><span class="pre">test-suite</span></tt> tests are divided into three types of tests: MultiSource,
+SingleSource, and External.</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/SingleSource</span></tt></p>
+<p>The SingleSource directory contains test programs that are only a
+single source file in size. These are usually small benchmark
+programs or small programs that calculate a particular value. Several
+such programs are grouped together in each directory.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/MultiSource</span></tt></p>
+<p>The MultiSource directory contains subdirectories which contain
+entire programs with multiple source files. Large benchmarks and
+whole applications go here.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">test-suite/External</span></tt></p>
+<p>The External directory contains Makefiles for building code that is
+external to (i.e., not distributed with) LLVM. The most prominent
+members of this directory are the SPEC 95 and SPEC 2000 benchmark
+suites. The <tt class="docutils literal"><span class="pre">External</span></tt> directory does not contain these actual
+tests, but only the Makefiles that know how to properly compile these
+programs from somewhere else. When using <tt class="docutils literal"><span class="pre">LNT</span></tt>, use the
+<tt class="docutils literal"><span class="pre">--test-externals</span></tt> option to include these tests in the results.</p>
+</li>
+</ul>
+<div class="section" id="test-suite-quickstart">
+<span id="id4"></span><h3><a class="toc-backref" href="#id24"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Quickstart</a><a class="headerlink" href="#test-suite-quickstart" title="Permalink to this headline">¶</a></h3>
+<p>The modern way of running the <tt class="docutils literal"><span class="pre">test-suite</span></tt> is focused on testing and
+benchmarking complete compilers using the
+<a class="reference external" href="http://llvm.org/docs/lnt">LNT</a> testing infrastructure.</p>
+<p>For more information on using LNT to execute the <tt class="docutils literal"><span class="pre">test-suite</span></tt>, please
+see the <a class="reference external" href="http://llvm.org/docs/lnt/quickstart.html">LNT Quickstart</a>
+documentation.</p>
+</div>
+<div class="section" id="test-suite-makefiles">
+<h3><a class="toc-backref" href="#id25"><tt class="docutils literal"><span class="pre">test-suite</span></tt> Makefiles</a><a class="headerlink" href="#test-suite-makefiles" title="Permalink to this headline">¶</a></h3>
+<p>Historically, the <tt class="docutils literal"><span class="pre">test-suite</span></tt> was executed using a complicated setup
+of Makefiles. The LNT based approach above is recommended for most
+users, but there are some testing scenarios which are not supported by
+the LNT approach. In addition, LNT currently uses the Makefile setup
+under the covers and so developers who are interested in how LNT works
+under the hood may want to understand the Makefile based setup.</p>
+<p>For more information on the <tt class="docutils literal"><span class="pre">test-suite</span></tt> Makefile setup, please see
+the <a class="reference internal" href="TestSuiteMakefileGuide.html"><em>Test Suite Makefile Guide</em></a>.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="TestSuiteMakefileGuide.html" title="LLVM 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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/TypeMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/TypeMetadata.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/TypeMetadata.html (added)
+++ www-releases/trunk/6.0.1/docs/TypeMetadata.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,386 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Type Metadata — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.html" />
+ <link rel="next" title="FaultMaps and implicit checks" href="FaultMaps.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">
+ <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="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">
+
+ <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 <tt class="docutils literal"><span class="pre">!type</span></tt> 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"><em>llvm.type.test</em></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++"><div class="highlight"><pre><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="n">B</span> <span class="o">:</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="n">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="n">D</span> <span class="o">:</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="n">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">
+<caption>Virtual Table Layout for A, B, C, D</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 <tt class="docutils literal"><span class="pre">&A::f</span></tt> 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 <tt class="docutils literal"><span class="pre">&B::f</span></tt> 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">
+<caption>Type Offsets for A, B, C, D</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-python"><pre>@_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>
+<p>With this type metadata, we can now use the <tt class="docutils literal"><span class="pre">llvm.type.test</span></tt> intrinsic to
+test whether a given pointer is compatible with a type identifier. Working
+backwards, if <tt class="docutils literal"><span class="pre">llvm.type.test</span></tt> 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 <tt class="docutils literal"><span class="pre">!"_ZST1A"</span></tt>, we know that the address can
+be only be one of <tt class="docutils literal"><span class="pre">_ZTV1A+16</span></tt>, <tt class="docutils literal"><span class="pre">_ZTV1B+16</span></tt> or <tt class="docutils literal"><span class="pre">_ZTV1D+16</span></tt> (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
+<tt class="docutils literal"><span class="pre">&A::f</span></tt>, <tt class="docutils literal"><span class="pre">&B::f</span></tt> or <tt class="docutils literal"><span class="pre">&D::f</span></tt>.</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 <tt class="docutils literal"><span class="pre">llvm.type.test</span></tt>, this will cause
+a link-time optimization pass, <tt class="docutils literal"><span class="pre">LowerTypeTests</span></tt>, 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 <tt class="docutils literal"><span class="pre">llvm.type.test</span></tt> 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="http://git.llvm.org/klaus/llvm/blob/master/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-python"><pre>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 class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="FaultMaps.html" title="FaultMaps and implicit checks"
+ >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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/Vectorizers.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/Vectorizers.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/Vectorizers.html (added)
+++ www-releases/trunk/6.0.1/docs/Vectorizers.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,504 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Auto-Vectorization in LLVM — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.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">
+ <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">
+
+ <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"><em>Loop Vectorizer</em></a>,
+which operates on Loops, and the <a class="reference internal" href="#slp-vectorizer"><em>SLP Vectorizer</em></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"><div class="highlight"><pre><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"><div class="highlight"><pre><span class="gp">$</span> clang -mllvm -force-vector-width<span class="o">=</span>8 ...
+<span class="gp">$</span> opt -loop-vectorize -force-vector-width<span class="o">=</span>8 ...
+</pre></div>
+</div>
+<p>Users can control the unroll factor using the command line flag “-force-vector-interleave”</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> clang -mllvm -force-vector-interleave<span class="o">=</span>2 ...
+<span class="gp">$</span> opt -loop-vectorize -force-vector-interleave<span class="o">=</span>2 ...
+</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 <tt class="docutils literal"><span class="pre">#pragma</span> <span class="pre">clang</span> <span class="pre">loop</span></tt> 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++"><div class="highlight"><pre><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++"><div class="highlight"><pre><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><tt class="docutils literal"><span class="pre">-Rpass=loop-vectorize</span></tt> identifies loops that were successfully vectorized.</p>
+<p><tt class="docutils literal"><span class="pre">-Rpass-missed=loop-vectorize</span></tt> identifies loops that failed vectorization and
+indicates if vectorization was specified.</p>
+<p><tt class="docutils literal"><span class="pre">-Rpass-analysis=loop-vectorize</span></tt> identifies the statements that caused
+vectorization to fail. If in addition <tt class="docutils literal"><span class="pre">-fsave-optimization-record</span></tt> 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++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">-Rpass-missed=loop-vectorized</span></tt> prints the remark:</p>
+<div class="highlight-console"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">-Rpass-analysis=loop-vectorize</span></tt> indicates that the
+switch statement cannot be vectorized.</p>
+<div class="highlight-console"><div class="highlight"><pre><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
+<tt class="docutils literal"><span class="pre">-gline-tables-only</span></tt> and <tt class="docutils literal"><span class="pre">-gcolumn-info</span></tt>. 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 <tt class="docutils literal"><span class="pre">start</span></tt> and <tt class="docutils literal"><span class="pre">finish</span></tt> 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++"><div class="highlight"><pre><span class="kt">void</span> <span class="n">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++"><div class="highlight"><pre><span class="kt">void</span> <span class="n">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 <tt class="docutils literal"><span class="pre">sum</span></tt> 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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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 <tt class="docutils literal"><span class="pre">i</span></tt> is saved into an
+array. The Loop Vectorizer knows to vectorize induction variables.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="kt">void</span> <span class="n">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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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="n">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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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++"><div class="highlight"><pre><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="n">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 Vectorize 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>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++"><div class="highlight"><pre><span class="kt">void</span> <span class="n">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++"><div class="highlight"><pre><span class="kt">int</span> <span class="n">foo</span><span class="p">(</span><span class="kt">int</span> <span class="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="http://llvm.org/viewvc/llvm-project/test-suite/trunk/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"><em>Vectorization Plan</em></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++"><div class="highlight"><pre><span class="kt">void</span> <span class="n">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"><div class="highlight"><pre><span class="gp">$</span> clang -fno-slp-vectorize file.c
+</pre></div>
+</div>
+<p>LLVM has a second basic block vectorization phase
+which is more compile-time intensive (The BB vectorizer). This optimization
+can be enabled through clang using the command line flag:</p>
+<div class="highlight-console"><div class="highlight"><pre><span class="gp">$</span> clang -fslp-vectorize-aggressive file.c
+</pre></div>
+</div>
+</div>
+</div>
+</div>
+
+
+ </div>
+ </div>
+ <div class="clearer"></div>
+ </div>
+ <div class="related">
+ <h3>Navigation</h3>
+ <ul>
+ <li class="right" style="margin-right: 10px">
+ <a href="genindex.html" title="General Index"
+ >index</a></li>
+ <li class="right" >
+ <a href="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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/6.0.1/docs/WritingAnLLVMBackend.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/6.0.1/docs/WritingAnLLVMBackend.html?rev=336152&view=auto
==============================================================================
--- www-releases/trunk/6.0.1/docs/WritingAnLLVMBackend.html (added)
+++ www-releases/trunk/6.0.1/docs/WritingAnLLVMBackend.html Mon Jul 2 16:21:43 2018
@@ -0,0 +1,1852 @@
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+
+ <title>Writing an LLVM Backend — LLVM 6 documentation</title>
+
+ <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: '',
+ VERSION: '6',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <link rel="top" title="LLVM 6 documentation" href="index.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">
+ <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">
+
+ <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 <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt></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 <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt></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
+<tt class="docutils literal"><span class="pre">llvm/lib/Target</span></tt> 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"><em>The LLVM Target-Independent Code Generator</em></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"><em>TableGen</em></a> — a document that describes the TableGen
+(<tt class="docutils literal"><span class="pre">tblgen</span></tt>) application that manages domain-specific information to support
+LLVM code generation. TableGen processes input from a target description
+file (<tt class="docutils literal"><span class="pre">.td</span></tt> suffix) and generates C++ code that can be used for code
+generation.</li>
+<li><a class="reference internal" href="WritingAnLLVMPass.html"><em>Writing an LLVM Pass</em></a> — The assembly printer is a <tt class="docutils literal"><span class="pre">FunctionPass</span></tt>, as
+are several <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> 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 (<tt class="docutils literal"><span class="pre">GAS</span></tt>), 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 <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class that describes
+characteristics of your target machine. Copy existing examples of specific
+<tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class and header files; for example, start with
+<tt class="docutils literal"><span class="pre">SparcTargetMachine.cpp</span></tt> and <tt class="docutils literal"><span class="pre">SparcTargetMachine.h</span></tt>, but change the file
+names for your target. Similarly, change code that references “<tt class="docutils literal"><span class="pre">Sparc</span></tt>” 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 <tt class="docutils literal"><span class="pre">RegisterInfo.td</span></tt> input file. You should also write
+additional code for a subclass of the <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> 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
+<tt class="docutils literal"><span class="pre">TargetInstrFormats.td</span></tt> and <tt class="docutils literal"><span class="pre">TargetInstrInfo.td</span></tt>. You should write
+additional code for a subclass of the <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt> 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 <tt class="docutils literal"><span class="pre">TargetInstrInfo.td</span></tt>. Write code for <tt class="docutils literal"><span class="pre">XXXISelDAGToDAG.cpp</span></tt>,
+where <tt class="docutils literal"><span class="pre">XXX</span></tt> identifies the specific target, to perform pattern matching and
+DAG-to-DAG instruction selection. Also write code in <tt class="docutils literal"><span class="pre">XXXISelLowering.cpp</span></tt>
+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 <tt class="docutils literal"><span class="pre">TargetInstrInfo.td</span></tt>. You
+should also write code for a subclass of <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> that performs the
+LLVM-to-assembly conversion and a trivial subclass of <tt class="docutils literal"><span class="pre">TargetAsmInfo</span></tt>.</li>
+<li>Optionally, add support for subtargets (i.e., variants with different
+capabilities). You should also write code for a subclass of the
+<tt class="docutils literal"><span class="pre">TargetSubtarget</span></tt> class, which allows you to use the <tt class="docutils literal"><span class="pre">-mcpu=</span></tt> and
+<tt class="docutils literal"><span class="pre">-mattr=</span></tt> command-line options.</li>
+<li>Optionally, add JIT support and create a machine code emitter (subclass of
+<tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt>) that is used to emit binary code directly into memory.</li>
+</ul>
+<p>In the <tt class="docutils literal"><span class="pre">.cpp</span></tt> and <tt class="docutils literal"><span class="pre">.h</span></tt>. 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"><em>LLVM Target-Independent Code Generator</em></a> document.</p>
+<p>First, you should create a subdirectory under <tt class="docutils literal"><span class="pre">lib/Target</span></tt> to hold all the
+files related to your target. If your target is called “Dummy”, create the
+directory <tt class="docutils literal"><span class="pre">lib/Target/Dummy</span></tt>.</p>
+<p>In this new directory, create a <tt class="docutils literal"><span class="pre">CMakeLists.txt</span></tt>. It is easiest to copy a
+<tt class="docutils literal"><span class="pre">CMakeLists.txt</span></tt> of another target and modify it. It should at least contain
+the <tt class="docutils literal"><span class="pre">LLVM_TARGET_DEFINITIONS</span></tt> variable. The library can be named <tt class="docutils literal"><span class="pre">LLVMDummy</span></tt>
+(for example, see the MIPS target). Alternatively, you can split the library
+into <tt class="docutils literal"><span class="pre">LLVMDummyCodeGen</span></tt> and <tt class="docutils literal"><span class="pre">LLVMDummyAsmPrinter</span></tt>, the latter of which
+should be implemented in a subdirectory below <tt class="docutils literal"><span class="pre">lib/Target/Dummy</span></tt> (for example,
+see the PowerPC target).</p>
+<p>Note that these two naming schemes are hardcoded into <tt class="docutils literal"><span class="pre">llvm-config</span></tt>. Using
+any other naming scheme will confuse <tt class="docutils literal"><span class="pre">llvm-config</span></tt> and produce a lot of
+(seemingly unrelated) linker errors when linking <tt class="docutils literal"><span class="pre">llc</span></tt>.</p>
+<p>To make your target actually do something, you need to implement a subclass of
+<tt class="docutils literal"><span class="pre">TargetMachine</span></tt>. This implementation should typically be in the file
+<tt class="docutils literal"><span class="pre">lib/Target/DummyTargetMachine.cpp</span></tt>, but any file in the <tt class="docutils literal"><span class="pre">lib/Target</span></tt>
+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 <tt class="docutils literal"><span class="pre">LLVMTargetMachine</span></tt>. (To create a target from scratch, create a
+subclass of <tt class="docutils literal"><span class="pre">TargetMachine</span></tt>.)</p>
+<p>To get LLVM to actually build and link your target, you need to run <tt class="docutils literal"><span class="pre">cmake</span></tt>
+with <tt class="docutils literal"><span class="pre">-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Dummy</span></tt>. 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 <tt class="docutils literal"><span class="pre">LLVM_ALL_TARGETS</span></tt> variable
+located in the main <tt class="docutils literal"><span class="pre">CMakeLists.txt</span></tt>.</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><tt class="docutils literal"><span class="pre">LLVMTargetMachine</span></tt> is designed as a base class for targets implemented with
+the LLVM target-independent code generator. The <tt class="docutils literal"><span class="pre">LLVMTargetMachine</span></tt> class
+should be specialized by a concrete target class that implements the various
+virtual methods. <tt class="docutils literal"><span class="pre">LLVMTargetMachine</span></tt> is defined as a subclass of
+<tt class="docutils literal"><span class="pre">TargetMachine</span></tt> in <tt class="docutils literal"><span class="pre">include/llvm/Target/TargetMachine.h</span></tt>. The
+<tt class="docutils literal"><span class="pre">TargetMachine</span></tt> class implementation (<tt class="docutils literal"><span class="pre">TargetMachine.cpp</span></tt>) also processes
+numerous command-line options.</p>
+<p>To create a concrete target-specific subclass of <tt class="docutils literal"><span class="pre">LLVMTargetMachine</span></tt>, start
+by copying an existing <tt class="docutils literal"><span class="pre">TargetMachine</span></tt> 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 <tt class="docutils literal"><span class="pre">SparcTargetMachine.h</span></tt> and
+<tt class="docutils literal"><span class="pre">SparcTargetMachine.cpp</span></tt>.</p>
+<p>For a target machine <tt class="docutils literal"><span class="pre">XXX</span></tt>, the implementation of <tt class="docutils literal"><span class="pre">XXXTargetMachine</span></tt> must
+have access methods to obtain objects that represent target components. These
+methods are named <tt class="docutils literal"><span class="pre">get*Info</span></tt>, and are intended to obtain the instruction set
+(<tt class="docutils literal"><span class="pre">getInstrInfo</span></tt>), register set (<tt class="docutils literal"><span class="pre">getRegisterInfo</span></tt>), stack frame layout
+(<tt class="docutils literal"><span class="pre">getFrameInfo</span></tt>), and similar information. <tt class="docutils literal"><span class="pre">XXXTargetMachine</span></tt> must also
+implement the <tt class="docutils literal"><span class="pre">getDataLayout</span></tt> 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 <tt class="docutils literal"><span class="pre">SparcTargetMachine.h</span></tt>
+declares prototypes for several <tt class="docutils literal"><span class="pre">get*Info</span></tt> and <tt class="docutils literal"><span class="pre">getDataLayout</span></tt> methods that
+simply return a class member.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">namespace</span> <span class="n">llvm</span> <span class="p">{</span>
+
+<span class="k">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="n">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="n">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="n">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="n">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="n">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="n">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="n">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="n">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><tt class="docutils literal"><span class="pre">getInstrInfo()</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">getRegisterInfo()</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">getFrameInfo()</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">getDataLayout()</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">getSubtargetImpl()</span></tt></li>
+</ul>
+<p>For some targets, you also need to support the following methods:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">getTargetLowering()</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">getJITInfo()</span></tt></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 <tt class="docutils literal"><span class="pre">XXXTargetMachine</span></tt> constructor should specify a
+<tt class="docutils literal"><span class="pre">TargetDescription</span></tt> string that determines the data layout for the target
+machine, including characteristics such as pointer size, alignment, and
+endianness. For example, the constructor for <tt class="docutils literal"><span class="pre">SparcTargetMachine</span></tt> contains
+the following:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">TargetDescription</span></tt> string.</p>
+<ul class="simple">
+<li>An upper-case “<tt class="docutils literal"><span class="pre">E</span></tt>” in the string indicates a big-endian target data model.
+A lower-case “<tt class="docutils literal"><span class="pre">e</span></tt>” indicates little-endian.</li>
+<li>“<tt class="docutils literal"><span class="pre">p:</span></tt>” is followed by pointer information: size, ABI alignment, and
+preferred alignment. If only two figures follow “<tt class="docutils literal"><span class="pre">p:</span></tt>”, 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: “<tt class="docutils literal"><span class="pre">i</span></tt>”, “<tt class="docutils literal"><span class="pre">f</span></tt>”, “<tt class="docutils literal"><span class="pre">v</span></tt>”, or
+“<tt class="docutils literal"><span class="pre">a</span></tt>” (corresponding to integer, floating point, vector, or aggregate).
+“<tt class="docutils literal"><span class="pre">i</span></tt>”, “<tt class="docutils literal"><span class="pre">v</span></tt>”, or “<tt class="docutils literal"><span class="pre">a</span></tt>” are followed by ABI alignment and preferred
+alignment. “<tt class="docutils literal"><span class="pre">f</span></tt>” 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 <tt class="docutils literal"><span class="pre">TargetRegistry</span></tt>, which is what
+other LLVM tools use to be able to lookup and use your target at runtime. The
+<tt class="docutils literal"><span class="pre">TargetRegistry</span></tt> 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 <tt class="docutils literal"><span class="pre">Target</span></tt> object which is used to
+represent the target during registration. Then, in the target’s <tt class="docutils literal"><span class="pre">TargetInfo</span></tt>
+library, the target should define that object and use the <tt class="docutils literal"><span class="pre">RegisterTarget</span></tt>
+template to register the target. For example, the Sparc registration code
+looks like this:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">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 <tt class="docutils literal"><span class="pre">TargetRegistry</span></tt> 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++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">XXXRegisterInfo</span></tt>
+(where <tt class="docutils literal"><span class="pre">XXX</span></tt> 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
+<tt class="docutils literal"><span class="pre">XXXRegisterInfo.td</span></tt> input files and placed in <tt class="docutils literal"><span class="pre">XXXGenRegisterInfo.h.inc</span></tt>
+and <tt class="docutils literal"><span class="pre">XXXGenRegisterInfo.inc</span></tt> output files. Some of the code in the
+implementation of <tt class="docutils literal"><span class="pre">XXXRegisterInfo</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXRegisterInfo.td</span></tt> file typically starts with register definitions for
+a target machine. The <tt class="docutils literal"><span class="pre">Register</span></tt> class (specified in <tt class="docutils literal"><span class="pre">Target.td</span></tt>) is used
+to define an object for each register. The specified string <tt class="docutils literal"><span class="pre">n</span></tt> becomes the
+<tt class="docutils literal"><span class="pre">Name</span></tt> of the register. The basic <tt class="docutils literal"><span class="pre">Register</span></tt> object does not have any
+subregisters and does not specify any aliases.</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">X86RegisterInfo.td</span></tt> file, there are register definitions
+that utilize the <tt class="docutils literal"><span class="pre">Register</span></tt> class, such as:</p>
+<div class="highlight-text"><div class="highlight"><pre>def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
+</pre></div>
+</div>
+<p>This defines the register <tt class="docutils literal"><span class="pre">AL</span></tt> and assigns it values (with <tt class="docutils literal"><span class="pre">DwarfRegNum</span></tt>)
+that are used by <tt class="docutils literal"><span class="pre">gcc</span></tt>, <tt class="docutils literal"><span class="pre">gdb</span></tt>, or a debug information writer to identify a
+register. For register <tt class="docutils literal"><span class="pre">AL</span></tt>, <tt class="docutils literal"><span class="pre">DwarfRegNum</span></tt> 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 <tt class="docutils literal"><span class="pre">X86RegisterInfo.td</span></tt> file, TableGen
+generates this code in the <tt class="docutils literal"><span class="pre">X86GenRegisterInfo.inc</span></tt> file:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt> object
+for each register. <tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt> is defined in
+<tt class="docutils literal"><span class="pre">include/llvm/Target/TargetRegisterInfo.h</span></tt> with the following fields:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 (<tt class="docutils literal"><span class="pre">.td</span></tt>) to determine text
+names for the register (in the <tt class="docutils literal"><span class="pre">AsmName</span></tt> and <tt class="docutils literal"><span class="pre">Name</span></tt> fields of
+<tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt>) and the relationships of other registers to the defined
+register (in the other <tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt> fields). In this example, other
+definitions establish the registers “<tt class="docutils literal"><span class="pre">AX</span></tt>”, “<tt class="docutils literal"><span class="pre">EAX</span></tt>”, and “<tt class="docutils literal"><span class="pre">RAX</span></tt>” as
+aliases for one another, so TableGen generates a null-terminated array
+(<tt class="docutils literal"><span class="pre">AL_AliasSet</span></tt>) for this register alias set.</p>
+<p>The <tt class="docutils literal"><span class="pre">Register</span></tt> class is commonly used as a base class for more complex
+classes. In <tt class="docutils literal"><span class="pre">Target.td</span></tt>, the <tt class="docutils literal"><span class="pre">Register</span></tt> class is the base for the
+<tt class="docutils literal"><span class="pre">RegisterWithSubRegs</span></tt> class that is used to define registers that need to
+specify subregisters in the <tt class="docutils literal"><span class="pre">SubRegs</span></tt> list, as shown here:</p>
+<div class="highlight-text"><div class="highlight"><pre>class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> {
+ let SubRegs = subregs;
+}
+</pre></div>
+</div>
+<p>In <tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt>, additional register classes are defined for SPARC:
+a <tt class="docutils literal"><span class="pre">Register</span></tt> subclass, <tt class="docutils literal"><span class="pre">SparcReg</span></tt>, and further subclasses: <tt class="docutils literal"><span class="pre">Ri</span></tt>, <tt class="docutils literal"><span class="pre">Rf</span></tt>,
+and <tt class="docutils literal"><span class="pre">Rd</span></tt>. SPARC registers are identified by 5-bit ID numbers, which is a
+feature common to these subclasses. Note the use of “<tt class="docutils literal"><span class="pre">let</span></tt>” expressions to
+override values that are initially defined in a superclass (such as <tt class="docutils literal"><span class="pre">SubRegs</span></tt>
+field in the <tt class="docutils literal"><span class="pre">Rd</span></tt> class).</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt> file, there are register definitions that
+utilize these subclasses of <tt class="docutils literal"><span class="pre">Register</span></tt>, such as:</p>
+<div class="highlight-text"><div class="highlight"><pre>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 (<tt class="docutils literal"><span class="pre">D0</span></tt> and <tt class="docutils literal"><span class="pre">D1</span></tt>) 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 <tt class="docutils literal"><span class="pre">TargetRegisterDesc</span></tt>.</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 <tt class="docutils literal"><span class="pre">RegisterClass</span></tt> class (specified in <tt class="docutils literal"><span class="pre">Target.td</span></tt>) 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
+<tt class="docutils literal"><span class="pre">XXXRegisterInfo.td</span></tt> that uses <tt class="docutils literal"><span class="pre">Target.td</span></tt> can construct register classes
+using the following class:</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">RegisterClass</span></tt>, 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 <tt class="docutils literal"><span class="pre">ValueType</span></tt> register type values that are
+defined in <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/ValueTypes.td</span></tt>. Defined values include
+integer types (such as <tt class="docutils literal"><span class="pre">i16</span></tt>, <tt class="docutils literal"><span class="pre">i32</span></tt>, and <tt class="docutils literal"><span class="pre">i1</span></tt> for Boolean),
+floating-point types (<tt class="docutils literal"><span class="pre">f32</span></tt>, <tt class="docutils literal"><span class="pre">f64</span></tt>), and vector types (for example,
+<tt class="docutils literal"><span class="pre">v8i16</span></tt> for an <tt class="docutils literal"><span class="pre">8</span> <span class="pre">x</span> <span class="pre">i16</span></tt> vector). All registers in a <tt class="docutils literal"><span class="pre">RegisterClass</span></tt>
+must have the same <tt class="docutils literal"><span class="pre">ValueType</span></tt>, 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 <tt class="docutils literal"><span class="pre">RegisterClass</span></tt> definition specifies the
+alignment required of the registers when they are stored or loaded to
+memory.</li>
+<li>The final argument, <tt class="docutils literal"><span class="pre">regList</span></tt>, specifies which registers are in this class.
+If an alternative allocation order method is not specified, then <tt class="docutils literal"><span class="pre">regList</span></tt>
+also defines the order of allocation used by the register allocator. Besides
+simply listing registers with <tt class="docutils literal"><span class="pre">(add</span> <span class="pre">R0,</span> <span class="pre">R1,</span> <span class="pre">...)</span></tt>, more advanced set
+operators are available. See <tt class="docutils literal"><span class="pre">include/llvm/Target/Target.td</span></tt> for more
+information.</li>
+</ul>
+<p>In <tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt>, three <tt class="docutils literal"><span class="pre">RegisterClass</span></tt> objects are defined:
+<tt class="docutils literal"><span class="pre">FPRegs</span></tt>, <tt class="docutils literal"><span class="pre">DFPRegs</span></tt>, and <tt class="docutils literal"><span class="pre">IntRegs</span></tt>. For all three register classes, the
+first argument defines the namespace with the string “<tt class="docutils literal"><span class="pre">SP</span></tt>”. <tt class="docutils literal"><span class="pre">FPRegs</span></tt>
+defines a group of 32 single-precision floating-point registers (<tt class="docutils literal"><span class="pre">F0</span></tt> to
+<tt class="docutils literal"><span class="pre">F31</span></tt>); <tt class="docutils literal"><span class="pre">DFPRegs</span></tt> defines a group of 16 double-precision registers
+(<tt class="docutils literal"><span class="pre">D0-D15</span></tt>).</p>
+<div class="highlight-text"><div class="highlight"><pre>// 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 <tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt> with TableGen generates several output files
+that are intended for inclusion in other source code that you write.
+<tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt> generates <tt class="docutils literal"><span class="pre">SparcGenRegisterInfo.h.inc</span></tt>, which should
+be included in the header file for the implementation of the SPARC register
+implementation that you write (<tt class="docutils literal"><span class="pre">SparcRegisterInfo.h</span></tt>). In
+<tt class="docutils literal"><span class="pre">SparcGenRegisterInfo.h.inc</span></tt> a new structure is defined called
+<tt class="docutils literal"><span class="pre">SparcGenRegisterInfo</span></tt> that uses <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt> as its base. It also
+specifies types, based upon the defined register classes: <tt class="docutils literal"><span class="pre">DFPRegsClass</span></tt>,
+<tt class="docutils literal"><span class="pre">FPRegsClass</span></tt>, and <tt class="docutils literal"><span class="pre">IntRegsClass</span></tt>.</p>
+<p><tt class="docutils literal"><span class="pre">SparcRegisterInfo.td</span></tt> also generates <tt class="docutils literal"><span class="pre">SparcGenRegisterInfo.inc</span></tt>, which is
+included at the bottom of <tt class="docutils literal"><span class="pre">SparcRegisterInfo.cpp</span></tt>, the SPARC register
+implementation. The code below shows only the generated integer registers and
+associated register classes. The order of registers in <tt class="docutils literal"><span class="pre">IntRegs</span></tt> reflects
+the order in the definition of <tt class="docutils literal"><span class="pre">IntRegs</span></tt> in the target description file.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">TargetRegisterInfo</span></tt></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 <tt class="docutils literal"><span class="pre">XXXRegisterInfo</span></tt>, which
+implements the interface described in <tt class="docutils literal"><span class="pre">TargetRegisterInfo.h</span></tt> (see
+<a class="reference internal" href="CodeGenerator.html#targetregisterinfo"><em>The TargetRegisterInfo class</em></a>). These functions return <tt class="docutils literal"><span class="pre">0</span></tt>, <tt class="docutils literal"><span class="pre">NULL</span></tt>, or
+<tt class="docutils literal"><span class="pre">false</span></tt>, unless overridden. Here is a list of functions that are overridden
+for the SPARC implementation in <tt class="docutils literal"><span class="pre">SparcRegisterInfo.cpp</span></tt>:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">getCalleeSavedRegs</span></tt> — Returns a list of callee-saved registers in the
+order of the desired callee-save stack frame offset.</li>
+<li><tt class="docutils literal"><span class="pre">getReservedRegs</span></tt> — Returns a bitset indexed by physical register
+numbers, indicating if a particular register is unavailable.</li>
+<li><tt class="docutils literal"><span class="pre">hasFP</span></tt> — Return a Boolean indicating if a function should have a
+dedicated frame pointer register.</li>
+<li><tt class="docutils literal"><span class="pre">eliminateCallFramePseudoInstr</span></tt> — If call frame setup or destroy pseudo
+instructions are used, this can be called to eliminate them.</li>
+<li><tt class="docutils literal"><span class="pre">eliminateFrameIndex</span></tt> — Eliminate abstract frame indices from
+instructions that may use them.</li>
+<li><tt class="docutils literal"><span class="pre">emitPrologue</span></tt> — Insert prologue code into the function.</li>
+<li><tt class="docutils literal"><span class="pre">emitEpilogue</span></tt> — 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
+<tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> with nodes that are instances of the <tt class="docutils literal"><span class="pre">SDNode</span></tt> class
+containing target instructions. An <tt class="docutils literal"><span class="pre">SDNode</span></tt> 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 <tt class="docutils literal"><span class="pre">include/llvm/CodeGen/SelectionDAGNodes.h</span></tt> file
+(values of the <tt class="docutils literal"><span class="pre">NodeType</span></tt> enum in the <tt class="docutils literal"><span class="pre">ISD</span></tt> namespace).</p>
+<p>TableGen uses the following target description (<tt class="docutils literal"><span class="pre">.td</span></tt>) input files to
+generate much of the code for instruction definition:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">Target.td</span></tt> — Where the <tt class="docutils literal"><span class="pre">Instruction</span></tt>, <tt class="docutils literal"><span class="pre">Operand</span></tt>, <tt class="docutils literal"><span class="pre">InstrInfo</span></tt>, and
+other fundamental classes are defined.</li>
+<li><tt class="docutils literal"><span class="pre">TargetSelectionDAG.td</span></tt> — Used by <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> instruction selection
+generators, contains <tt class="docutils literal"><span class="pre">SDTC*</span></tt> classes (selection DAG type constraint),
+definitions of <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> nodes (such as <tt class="docutils literal"><span class="pre">imm</span></tt>, <tt class="docutils literal"><span class="pre">cond</span></tt>, <tt class="docutils literal"><span class="pre">bb</span></tt>,
+<tt class="docutils literal"><span class="pre">add</span></tt>, <tt class="docutils literal"><span class="pre">fadd</span></tt>, <tt class="docutils literal"><span class="pre">sub</span></tt>), and pattern support (<tt class="docutils literal"><span class="pre">Pattern</span></tt>, <tt class="docutils literal"><span class="pre">Pat</span></tt>,
+<tt class="docutils literal"><span class="pre">PatFrag</span></tt>, <tt class="docutils literal"><span class="pre">PatLeaf</span></tt>, <tt class="docutils literal"><span class="pre">ComplexPattern</span></tt>.</li>
+<li><tt class="docutils literal"><span class="pre">XXXInstrFormats.td</span></tt> — Patterns for definitions of target-specific
+instructions.</li>
+<li><tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt> — 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 <tt class="docutils literal"><span class="pre">X86InstrSSE.td</span></tt>, and for Pentium with
+MMX, this file is <tt class="docutils literal"><span class="pre">X86InstrMMX.td</span></tt>.</li>
+</ul>
+<p>There is also a target-specific <tt class="docutils literal"><span class="pre">XXX.td</span></tt> file, where <tt class="docutils literal"><span class="pre">XXX</span></tt> is the name of
+the target. The <tt class="docutils literal"><span class="pre">XXX.td</span></tt> file includes the other <tt class="docutils literal"><span class="pre">.td</span></tt> input files, but
+its contents are only directly important for subtargets.</p>
+<p>You should describe a concrete target-specific class <tt class="docutils literal"><span class="pre">XXXInstrInfo</span></tt> that
+represents machine instructions supported by a target machine.
+<tt class="docutils literal"><span class="pre">XXXInstrInfo</span></tt> contains an array of <tt class="docutils literal"><span class="pre">XXXInstrDescriptor</span></tt> 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 <tt class="docutils literal"><span class="pre">Target.td</span></tt>) is mostly used as a base for
+more complex instruction classes.</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> node (<tt class="docutils literal"><span class="pre">SDNode</span></tt>) should contain an object representing a
+target-specific instruction that is defined in <tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt>. 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 <tt class="docutils literal"><span class="pre">ADDri</span></tt> and
+<tt class="docutils literal"><span class="pre">ADDrr</span></tt>.</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 <tt class="docutils literal"><span class="pre">CALL</span></tt>
+instruction. Format 2 is for branch on condition codes and <tt class="docutils literal"><span class="pre">SETHI</span></tt> (set high
+bits of a register) instructions. Format 3 is for other instructions.</p>
+<p>Each of these formats has corresponding classes in <tt class="docutils literal"><span class="pre">SparcInstrFormat.td</span></tt>.
+<tt class="docutils literal"><span class="pre">InstSP</span></tt> is a base class for other instruction classes. Additional base
+classes are specified for more precise formats: for example in
+<tt class="docutils literal"><span class="pre">SparcInstrFormat.td</span></tt>, <tt class="docutils literal"><span class="pre">F2_1</span></tt> is for <tt class="docutils literal"><span class="pre">SETHI</span></tt>, and <tt class="docutils literal"><span class="pre">F2_2</span></tt> is for
+branches. There are three other base classes: <tt class="docutils literal"><span class="pre">F3_1</span></tt> for register/register
+operations, <tt class="docutils literal"><span class="pre">F3_2</span></tt> for register/immediate operations, and <tt class="docutils literal"><span class="pre">F3_3</span></tt> for
+floating-point operations. <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt> also adds the base class
+<tt class="docutils literal"><span class="pre">Pseudo</span></tt> for synthetic SPARC instructions.</p>
+<p><tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt> largely consists of operand and instruction definitions
+for the SPARC target. In <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>, the following target
+description file entry, <tt class="docutils literal"><span class="pre">LDrr</span></tt>, defines the Load Integer instruction for a
+Word (the <tt class="docutils literal"><span class="pre">LD</span></tt> SPARC opcode) from a memory address to a register. The first
+parameter, the value 3 (<tt class="docutils literal"><span class="pre">11</span></tt><sub>2</sub>), is the operation value for this
+category of operation. The second parameter (<tt class="docutils literal"><span class="pre">000000</span></tt><sub>2</sub>) is the
+specific operation value for <tt class="docutils literal"><span class="pre">LD</span></tt>/Load Word. The third parameter is the
+output destination, which is a register operand and defined in the <tt class="docutils literal"><span class="pre">Register</span></tt>
+target description file (<tt class="docutils literal"><span class="pre">IntRegs</span></tt>).</p>
+<div class="highlight-text"><div class="highlight"><pre>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
+<tt class="docutils literal"><span class="pre">MEMrr</span></tt> that is defined earlier in <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>:</p>
+<div class="highlight-text"><div class="highlight"><pre>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"><em>The LLVM Target-Independent Code Generator</em></a>.
+This parameter is detailed in the next section, <a class="reference internal" href="#instruction-selector"><em>Instruction Selector</em></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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">.td</span></tt> files, the <tt class="docutils literal"><span class="pre">multiclass</span></tt> directive enables the
+creation of templates to define several instruction classes at once (using the
+<tt class="docutils literal"><span class="pre">defm</span></tt> directive). For example in <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>, the <tt class="docutils literal"><span class="pre">multiclass</span></tt>
+pattern <tt class="docutils literal"><span class="pre">F3_12</span></tt> is defined to create 2 instruction classes each time
+<tt class="docutils literal"><span class="pre">F3_12</span></tt> is invoked:</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">defm</span></tt> directive is used for the <tt class="docutils literal"><span class="pre">XOR</span></tt> and <tt class="docutils literal"><span class="pre">ADD</span></tt>
+instructions, as seen below, it creates four instruction objects: <tt class="docutils literal"><span class="pre">XORrr</span></tt>,
+<tt class="docutils literal"><span class="pre">XORri</span></tt>, <tt class="docutils literal"><span class="pre">ADDrr</span></tt>, and <tt class="docutils literal"><span class="pre">ADDri</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>defm XOR : F3_12<"xor", 0b000011, xor>;
+defm ADD : F3_12<"add", 0b000000, add>;
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt> also includes definitions for condition codes that are
+referenced by branch instructions. The following definitions in
+<tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt> 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">Sparc.h</span></tt> also defines enums that correspond to the same SPARC
+condition codes. Care must be taken to ensure the values in <tt class="docutils literal"><span class="pre">Sparc.h</span></tt>
+correspond to the values in <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>. I.e., <tt class="docutils literal"><span class="pre">SPCC::ICC_NE</span> <span class="pre">=</span> <span class="pre">9</span></tt>,
+<tt class="docutils literal"><span class="pre">SPCC::FCC_U</span> <span class="pre">=</span> <span class="pre">23</span></tt> 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 <tt class="docutils literal"><span class="pre">XNORrr</span></tt> instruction as a <tt class="docutils literal"><span class="pre">F3_1</span></tt>
+format instruction having three operands.</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">SparcInstrFormats.td</span></tt> show the base class for
+<tt class="docutils literal"><span class="pre">F3_1</span></tt> is <tt class="docutils literal"><span class="pre">InstSP</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">InstSP</span></tt> leaves the <tt class="docutils literal"><span class="pre">op</span></tt> field unbound.</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">F3</span></tt> binds the <tt class="docutils literal"><span class="pre">op</span></tt> field and defines the <tt class="docutils literal"><span class="pre">rd</span></tt>, <tt class="docutils literal"><span class="pre">op3</span></tt>, and <tt class="docutils literal"><span class="pre">rs1</span></tt>
+fields. <tt class="docutils literal"><span class="pre">F3</span></tt> format instructions will bind the operands <tt class="docutils literal"><span class="pre">rd</span></tt>, <tt class="docutils literal"><span class="pre">op3</span></tt>, and
+<tt class="docutils literal"><span class="pre">rs1</span></tt> fields.</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">F3_1</span></tt> binds the <tt class="docutils literal"><span class="pre">op3</span></tt> field and defines the <tt class="docutils literal"><span class="pre">rs2</span></tt> fields. <tt class="docutils literal"><span class="pre">F3_1</span></tt>
+format instructions will bind the operands to the <tt class="docutils literal"><span class="pre">rd</span></tt>, <tt class="docutils literal"><span class="pre">rs1</span></tt>, and <tt class="docutils literal"><span class="pre">rs2</span></tt>
+fields. This results in the <tt class="docutils literal"><span class="pre">XNORrr</span></tt> instruction binding <tt class="docutils literal"><span class="pre">$dst</span></tt>, <tt class="docutils literal"><span class="pre">$b</span></tt>,
+and <tt class="docutils literal"><span class="pre">$c</span></tt> operands to the <tt class="docutils literal"><span class="pre">rd</span></tt>, <tt class="docutils literal"><span class="pre">rs1</span></tt>, and <tt class="docutils literal"><span class="pre">rs2</span></tt> 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"><div class="highlight"><pre>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++"><div class="highlight"><pre><span class="cp">#define GET_INSTRINFO_NAMED_OPS </span><span class="c1">// For getNamedOperandIdx() function</span>
+<span class="cp">#include "XXXGenInstrInfo.inc"</span>
+</pre></div>
+</div>
+<p>XXXInstrInfo.h:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="cp">#define GET_INSTRINFO_OPERAND_ENUM </span><span class="c1">// For OpName enum</span>
+<span class="cp">#include "XXXGenInstrInfo.inc"</span>
+
+<span class="k">namespace</span> <span class="n">XXX</span> <span class="p">{</span>
+ <span class="n">int16_t</span> <span class="n">getNamedOperandIdx</span><span class="p">(</span><span class="n">uint16_t</span> <span class="n">Opcode</span><span class="p">,</span> <span class="n">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 <tt class="docutils literal"><span class="pre">include/llvm/Target/Target.td</span></tt>, 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 <tt class="docutils literal"><span class="pre">brtarget</span></tt> and <tt class="docutils literal"><span class="pre">brtarget8</span></tt>, both
+instances of the TableGen <tt class="docutils literal"><span class="pre">Operand</span></tt> class, which represent branch target
+operands:</p>
+<div class="highlight-text"><div class="highlight"><pre>def brtarget : Operand<OtherVT>;
+def brtarget8 : Operand<OtherVT>;
+</pre></div>
+</div>
+<p>This results in:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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++"><div class="highlight"><pre><span class="cp">#define GET_INSTRINFO_OPERAND_TYPES_ENUM </span><span class="c1">// For OpTypes enum</span>
+<span class="cp">#include "XXXGenInstrInfo.inc"</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 <tt class="docutils literal"><span class="pre">CodeGenSchedModels</span></tt> class. This is distinct from the itinerary
+method of specifying machine resource use. The tool <tt class="docutils literal"><span class="pre">utils/schedcover.py</span></tt>
+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 <tt class="docutils literal"><span class="pre">schedcover.py</span></tt> on the
+output file:</p>
+<div class="highlight-shell"><pre>$ <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>
+<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 <tt class="docutils literal"><span class="pre">subtarget-emitter</span></tt> debug option:</p>
+<div class="highlight-shell"><pre>$ <build>/bin/llvm-tblgen -debug-only=subtarget-emitter -gen-subtarget \
+ -I <src>/lib/Target/<target> -I <src>/include \
+ -I <src>/lib/Target <src>/lib/Target/<target>/<target>.td \
+ -o <build>/lib/Target/<target>/<target>GenSubtargetInfo.inc.tmp \
+ > tblGenSubtarget.dbg 2>&1</pre>
+</div>
+<p>Where <tt class="docutils literal"><span class="pre"><build></span></tt> is the build directory, <tt class="docutils literal"><span class="pre">src</span></tt> is the source directory,
+and <tt class="docutils literal"><span class="pre"><target></span></tt> 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"><pre>$ VERBOSE=1 make ...</pre>
+</div>
+<p>and search for <tt class="docutils literal"><span class="pre">llvm-tblgen</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt> files
+according to the target-specific instruction set. Relation models are defined
+using <tt class="docutils literal"><span class="pre">InstrMapping</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXGenInstrInfo.inc</span></tt> 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"><em>How To Use Instruction Mappings</em></a>.</p>
+</div>
+<div class="section" id="implement-a-subclass-of-targetinstrinfo">
+<h3><a class="toc-backref" href="#id20">Implement a subclass of <tt class="docutils literal"><span class="pre">TargetInstrInfo</span></tt></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 <tt class="docutils literal"><span class="pre">XXXInstrInfo</span></tt>, which implements
+the interface described in <tt class="docutils literal"><span class="pre">TargetInstrInfo.h</span></tt> (see <a class="reference internal" href="CodeGenerator.html#targetinstrinfo"><em>The TargetInstrInfo class</em></a>).
+These functions return <tt class="docutils literal"><span class="pre">0</span></tt> or a Boolean or they assert, unless overridden.
+Here’s a list of functions that are overridden for the SPARC implementation in
+<tt class="docutils literal"><span class="pre">SparcInstrInfo.cpp</span></tt>:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">isLoadFromStackSlot</span></tt> — If the specified machine instruction is a direct
+load from a stack slot, return the register number of the destination and the
+<tt class="docutils literal"><span class="pre">FrameIndex</span></tt> of the stack slot.</li>
+<li><tt class="docutils literal"><span class="pre">isStoreToStackSlot</span></tt> — If the specified machine instruction is a direct
+store to a stack slot, return the register number of the destination and the
+<tt class="docutils literal"><span class="pre">FrameIndex</span></tt> of the stack slot.</li>
+<li><tt class="docutils literal"><span class="pre">copyPhysReg</span></tt> — Copy values between a pair of physical registers.</li>
+<li><tt class="docutils literal"><span class="pre">storeRegToStackSlot</span></tt> — Store a register value to a stack slot.</li>
+<li><tt class="docutils literal"><span class="pre">loadRegFromStackSlot</span></tt> — Load a register value from a stack slot.</li>
+<li><tt class="docutils literal"><span class="pre">storeRegToAddr</span></tt> — Store a register value to memory.</li>
+<li><tt class="docutils literal"><span class="pre">loadRegFromAddr</span></tt> — Load a register value from memory.</li>
+<li><tt class="docutils literal"><span class="pre">foldMemoryOperand</span></tt> — 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 <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> method in
+<tt class="docutils literal"><span class="pre">XXXInstrInfo</span></tt> may be implemented to examine conditional instructions and
+remove unnecessary instructions. <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> looks at the end of a
+machine basic block (MBB) for opportunities for improvement, such as branch
+folding and if conversion. The <tt class="docutils literal"><span class="pre">BranchFolder</span></tt> and <tt class="docutils literal"><span class="pre">IfConverter</span></tt> machine
+function passes (see the source files <tt class="docutils literal"><span class="pre">BranchFolding.cpp</span></tt> and
+<tt class="docutils literal"><span class="pre">IfConversion.cpp</span></tt> in the <tt class="docutils literal"><span class="pre">lib/CodeGen</span></tt> directory) call <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt>
+to improve the control flow graph that represents the instructions.</p>
+<p>Several implementations of <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> (for ARM, Alpha, and X86) can be
+examined as models for your own <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> implementation. Since SPARC
+does not implement a useful <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt>, the ARM target implementation is
+shown below.</p>
+<p><tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> returns a Boolean value and takes four parameters:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">MachineBasicBlock</span> <span class="pre">&MBB</span></tt> — The incoming block to be examined.</li>
+<li><tt class="docutils literal"><span class="pre">MachineBasicBlock</span> <span class="pre">*&TBB</span></tt> — A destination block that is returned. For a
+conditional branch that evaluates to true, <tt class="docutils literal"><span class="pre">TBB</span></tt> is the destination.</li>
+<li><tt class="docutils literal"><span class="pre">MachineBasicBlock</span> <span class="pre">*&FBB</span></tt> — For a conditional branch that evaluates to
+false, <tt class="docutils literal"><span class="pre">FBB</span></tt> is returned as the destination.</li>
+<li><tt class="docutils literal"><span class="pre">std::vector<MachineOperand></span> <span class="pre">&Cond</span></tt> — 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 <tt class="docutils literal"><span class="pre">TBB</span></tt>
+or <tt class="docutils literal"><span class="pre">FBB</span></tt>, so both parameters return <tt class="docutils literal"><span class="pre">NULL</span></tt>. The start of the
+<tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> (see code below for the ARM target) shows the function
+parameters and the code for the simplest case.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">false</span><span class="p">;</span>
+</pre></div>
+</div>
+<p>If a block ends with a single unconditional branch instruction, then
+<tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> (shown below) should return the destination of that branch in
+the <tt class="docutils literal"><span class="pre">TBB</span></tt> parameter.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">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 <tt class="docutils literal"><span class="pre">TBB</span></tt> parameter.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">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,
+<tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> (shown below) should return the destination of that
+conditional branch in the <tt class="docutils literal"><span class="pre">TBB</span></tt> parameter and a list of operands in the
+<tt class="docutils literal"><span class="pre">Cond</span></tt> parameter to evaluate the condition.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">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 <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> (shown below) should return the conditional
+branch destination (assuming it corresponds to a conditional evaluation of
+“<tt class="docutils literal"><span class="pre">true</span></tt>”) in the <tt class="docutils literal"><span class="pre">TBB</span></tt> parameter and the unconditional branch destination
+in the <tt class="docutils literal"><span class="pre">FBB</span></tt> (corresponding to a conditional evaluation of “<tt class="docutils literal"><span class="pre">false</span></tt>”). A
+list of operands to evaluate the condition should be returned in the <tt class="docutils literal"><span class="pre">Cond</span></tt>
+parameter.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="kc">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
+<tt class="docutils literal"><span class="pre">Cond</span></tt> parameter can be passed to methods of other instructions to create new
+branches or perform other operations. An implementation of <tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt>
+requires the helper methods <tt class="docutils literal"><span class="pre">RemoveBranch</span></tt> and <tt class="docutils literal"><span class="pre">InsertBranch</span></tt> to manage
+subsequent operations.</p>
+<p><tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> should return false indicating success in most circumstances.
+<tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> should only return true when the method is stumped about what
+to do, for example, if a block has three terminating branches.
+<tt class="docutils literal"><span class="pre">AnalyzeBranch</span></tt> 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 <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> to represent LLVM IR instructions, and nodes of
+the <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXISelDAGToDAG.cpp</span></tt> is used to match patterns and perform DAG-to-DAG
+instruction selection. Optionally, a pass may be defined (in
+<tt class="docutils literal"><span class="pre">XXXBranchSelector.cpp</span></tt>) to perform similar DAG-to-DAG operations for branch
+instructions. Later, the code in <tt class="docutils literal"><span class="pre">XXXISelLowering.cpp</span></tt> replaces or removes
+operations and data types not supported natively (legalizes) in a
+<tt class="docutils literal"><span class="pre">SelectionDAG</span></tt>.</p>
+<p>TableGen generates code for instruction selection using the following target
+description input files:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt> — Contains definitions of instructions in a
+target-specific instruction set, generates <tt class="docutils literal"><span class="pre">XXXGenDAGISel.inc</span></tt>, which is
+included in <tt class="docutils literal"><span class="pre">XXXISelDAGToDAG.cpp</span></tt>.</li>
+<li><tt class="docutils literal"><span class="pre">XXXCallingConv.td</span></tt> — Contains the calling and return value conventions
+for the target architecture, and it generates <tt class="docutils literal"><span class="pre">XXXGenCallingConv.inc</span></tt>,
+which is included in <tt class="docutils literal"><span class="pre">XXXISelLowering.cpp</span></tt>.</li>
+</ul>
+<p>The implementation of an instruction selection pass must include a header that
+declares the <tt class="docutils literal"><span class="pre">FunctionPass</span></tt> class or a subclass of <tt class="docutils literal"><span class="pre">FunctionPass</span></tt>. In
+<tt class="docutils literal"><span class="pre">XXXTargetMachine.cpp</span></tt>, a Pass Manager (PM) should add each instruction
+selection pass into the queue of passes to run.</p>
+<p>The LLVM static compiler (<tt class="docutils literal"><span class="pre">llc</span></tt>) is an excellent tool for visualizing the
+contents of DAGs. To display the <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> before or after specific
+processing phases, use the command line options for <tt class="docutils literal"><span class="pre">llc</span></tt>, described at
+<a class="reference internal" href="CodeGenerator.html#selectiondag-process"><em>SelectionDAG Instruction Selection Process</em></a>.</p>
+<p>To describe instruction selector behavior, you should add patterns for lowering
+LLVM code into a <tt class="docutils literal"><span class="pre">SelectionDAG</span></tt> as the last parameter of the instruction
+definitions in <tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt>. For example, in <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>,
+this entry defines a register store operation, and the last parameter describes
+a pattern with the store DAG operator.</p>
+<div class="highlight-text"><div class="highlight"><pre>def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
+ "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>;
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">ADDRrr</span></tt> is a memory mode that is also defined in <tt class="docutils literal"><span class="pre">SparcInstrInfo.td</span></tt>:</p>
+<div class="highlight-text"><div class="highlight"><pre>def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
+</pre></div>
+</div>
+<p>The definition of <tt class="docutils literal"><span class="pre">ADDRrr</span></tt> refers to <tt class="docutils literal"><span class="pre">SelectADDRrr</span></tt>, which is a function
+defined in an implementation of the Instructor Selector (such as
+<tt class="docutils literal"><span class="pre">SparcISelDAGToDAG.cpp</span></tt>).</p>
+<p>In <tt class="docutils literal"><span class="pre">lib/Target/TargetSelectionDAG.td</span></tt>, the DAG operator for store is defined
+below:</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt> also generates (in <tt class="docutils literal"><span class="pre">XXXGenDAGISel.inc</span></tt>) the
+<tt class="docutils literal"><span class="pre">SelectCode</span></tt> method that is used to call the appropriate processing method
+for an instruction. In this example, <tt class="docutils literal"><span class="pre">SelectCode</span></tt> calls <tt class="docutils literal"><span class="pre">Select_ISD_STORE</span></tt>
+for the <tt class="docutils literal"><span class="pre">ISD::STORE</span></tt> opcode.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">SDNode</span> <span class="o">*</span><span class="n">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="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 <tt class="docutils literal"><span class="pre">STrr</span></tt> is matched, so elsewhere in <tt class="docutils literal"><span class="pre">XXXGenDAGISel.inc</span></tt>,
+code for <tt class="docutils literal"><span class="pre">STrr</span></tt> is created for <tt class="docutils literal"><span class="pre">Select_ISD_STORE</span></tt>. The <tt class="docutils literal"><span class="pre">Emit_22</span></tt> method
+is also generated in <tt class="docutils literal"><span class="pre">XXXGenDAGISel.inc</span></tt> to complete the processing of this
+instruction.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">SDNode</span> <span class="o">*</span><span class="n">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 <tt class="docutils literal"><span class="pre">XXXTargetLowering</span></tt> implementation to
+convert unsupported types and operations to supported ones.</p>
+<p>In the constructor for the <tt class="docutils literal"><span class="pre">XXXTargetLowering</span></tt> class, first use the
+<tt class="docutils literal"><span class="pre">addRegisterClass</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXRegisterInfo.td</span></tt> and placed in
+<tt class="docutils literal"><span class="pre">XXXGenRegisterInfo.h.inc</span></tt>. For example, the implementation of the
+constructor for the SparcTargetLowering class (in <tt class="docutils literal"><span class="pre">SparcISelLowering.cpp</span></tt>)
+starts with the following code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">ISD</span></tt> namespace
+(<tt class="docutils literal"><span class="pre">include/llvm/CodeGen/SelectionDAGNodes.h</span></tt>) 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 <tt class="docutils literal"><span class="pre">XXXTargetLowering</span></tt> class,
+so the instruction selection process knows what to do. The <tt class="docutils literal"><span class="pre">TargetLowering</span></tt>
+class callback methods (declared in <tt class="docutils literal"><span class="pre">llvm/Target/TargetLowering.h</span></tt>) are:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">setOperationAction</span></tt> — General operation.</li>
+<li><tt class="docutils literal"><span class="pre">setLoadExtAction</span></tt> — Load with extension.</li>
+<li><tt class="docutils literal"><span class="pre">setTruncStoreAction</span></tt> — Truncating store.</li>
+<li><tt class="docutils literal"><span class="pre">setIndexedLoadAction</span></tt> — Indexed load.</li>
+<li><tt class="docutils literal"><span class="pre">setIndexedStoreAction</span></tt> — Indexed store.</li>
+<li><tt class="docutils literal"><span class="pre">setConvertAction</span></tt> — Type conversion.</li>
+<li><tt class="docutils literal"><span class="pre">setCondCodeAction</span></tt> — Support for a given condition code.</li>
+</ul>
+<p>Note: on older releases, <tt class="docutils literal"><span class="pre">setLoadXAction</span></tt> is used instead of
+<tt class="docutils literal"><span class="pre">setLoadExtAction</span></tt>. Also, on older releases, <tt class="docutils literal"><span class="pre">setCondCodeAction</span></tt> 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
+<tt class="docutils literal"><span class="pre">LegalAction</span></tt> type enum value: <tt class="docutils literal"><span class="pre">Promote</span></tt>, <tt class="docutils literal"><span class="pre">Expand</span></tt>, <tt class="docutils literal"><span class="pre">Custom</span></tt>, or
+<tt class="docutils literal"><span class="pre">Legal</span></tt>. <tt class="docutils literal"><span class="pre">SparcISelLowering.cpp</span></tt> contains examples of all four
+<tt class="docutils literal"><span class="pre">LegalAction</span></tt> 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 (<tt class="docutils literal"><span class="pre">i1</span></tt> type), so in
+<tt class="docutils literal"><span class="pre">SparcISelLowering.cpp</span></tt> the third parameter below, <tt class="docutils literal"><span class="pre">Promote</span></tt>, changes
+<tt class="docutils literal"><span class="pre">i1</span></tt> type values to a large type before loading.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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, <tt class="docutils literal"><span class="pre">Expand</span></tt>, to
+<tt class="docutils literal"><span class="pre">setOperationAction</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">SparcISelLowering.cpp</span></tt> code below, to perform a type conversion
+from a floating point value to a signed integer, first the
+<tt class="docutils literal"><span class="pre">setOperationAction</span></tt> should be called with <tt class="docutils literal"><span class="pre">Custom</span></tt> as the third parameter:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">LowerOperation</span></tt> method, for each <tt class="docutils literal"><span class="pre">Custom</span></tt> operation, a case
+statement should be added to indicate what function to call. In the following
+code, an <tt class="docutils literal"><span class="pre">FP_TO_SINT</span></tt> opcode will call the <tt class="docutils literal"><span class="pre">LowerFP_TO_SINT</span></tt> method:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="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 <tt class="docutils literal"><span class="pre">LowerFP_TO_SINT</span></tt> method is implemented, using an FP register to
+convert the floating-point value to an integer.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">static</span> <span class="n">SDValue</span> <span class="n">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 <tt class="docutils literal"><span class="pre">Legal</span></tt> <tt class="docutils literal"><span class="pre">LegalizeAction</span></tt> enum value simply indicates that an operation
+<strong>is</strong> natively supported. <tt class="docutils literal"><span class="pre">Legal</span></tt> represents the default condition, so it
+is rarely used. In <tt class="docutils literal"><span class="pre">SparcISelLowering.cpp</span></tt>, the action for <tt class="docutils literal"><span class="pre">CTPOP</span></tt> (an
+operation to count the bits set in an integer) is natively supported only for
+SPARC v9. The following code enables the <tt class="docutils literal"><span class="pre">Expand</span></tt> conversion technique for
+non-v9 SPARC implementations.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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, <tt class="docutils literal"><span class="pre">XXXGenCallingConv.td</span></tt> uses
+interfaces (such as <tt class="docutils literal"><span class="pre">CCIfType</span></tt> and <tt class="docutils literal"><span class="pre">CCAssignToReg</span></tt>) that are defined in
+<tt class="docutils literal"><span class="pre">lib/Target/TargetCallingConv.td</span></tt>. TableGen can take the target descriptor
+file <tt class="docutils literal"><span class="pre">XXXGenCallingConv.td</span></tt> and generate the header file
+<tt class="docutils literal"><span class="pre">XXXGenCallingConv.inc</span></tt>, which is typically included in
+<tt class="docutils literal"><span class="pre">XXXISelLowering.cpp</span></tt>. You can use the interfaces in
+<tt class="docutils literal"><span class="pre">TargetCallingConv.td</span></tt> 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 <tt class="docutils literal"><span class="pre">CCIfType</span></tt> and
+<tt class="docutils literal"><span class="pre">CCAssignToReg</span></tt> interfaces. If the <tt class="docutils literal"><span class="pre">CCIfType</span></tt> predicate is true (that is,
+if the current argument is of type <tt class="docutils literal"><span class="pre">f32</span></tt> or <tt class="docutils literal"><span class="pre">f64</span></tt>), then the action is
+performed. In this case, the <tt class="docutils literal"><span class="pre">CCAssignToReg</span></tt> action assigns the argument
+value to the first available register: either <tt class="docutils literal"><span class="pre">R0</span></tt> or <tt class="docutils literal"><span class="pre">R1</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">SparcCallingConv.td</span></tt> contains definitions for a target-specific return-value
+calling convention (<tt class="docutils literal"><span class="pre">RetCC_Sparc32</span></tt>) and a basic 32-bit C calling convention
+(<tt class="docutils literal"><span class="pre">CC_Sparc32</span></tt>). The definition of <tt class="docutils literal"><span class="pre">RetCC_Sparc32</span></tt> (shown below) indicates
+which registers are used for specified scalar return types. A single-precision
+float is returned to register <tt class="docutils literal"><span class="pre">F0</span></tt>, and a double-precision float goes to
+register <tt class="docutils literal"><span class="pre">D0</span></tt>. A 32-bit integer is returned in register <tt class="docutils literal"><span class="pre">I0</span></tt> or <tt class="docutils literal"><span class="pre">I1</span></tt>.</p>
+<div class="highlight-text"><div class="highlight"><pre>def RetCC_Sparc32 : CallingConv<[
+ CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
+ CCIfType<[f32], CCAssignToReg<[F0]>>,
+ CCIfType<[f64], CCAssignToReg<[D0]>>
+]>;
+</pre></div>
+</div>
+<p>The definition of <tt class="docutils literal"><span class="pre">CC_Sparc32</span></tt> in <tt class="docutils literal"><span class="pre">SparcCallingConv.td</span></tt> introduces
+<tt class="docutils literal"><span class="pre">CCAssignToStack</span></tt>, 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"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">CCDelegateTo</span></tt> 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 <tt class="docutils literal"><span class="pre">X86CallingConv.td</span></tt>), the definition of
+<tt class="docutils literal"><span class="pre">RetCC_X86_32_C</span></tt> ends with <tt class="docutils literal"><span class="pre">CCDelegateTo</span></tt>. After the current value is
+assigned to the register <tt class="docutils literal"><span class="pre">ST0</span></tt> or <tt class="docutils literal"><span class="pre">ST1</span></tt>, the <tt class="docutils literal"><span class="pre">RetCC_X86Common</span></tt> is
+invoked.</p>
+<div class="highlight-text"><div class="highlight"><pre>def RetCC_X86_32_C : CallingConv<[
+ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
+ CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
+ CCDelegateTo<RetCC_X86Common>
+]>;
+</pre></div>
+</div>
+<p><tt class="docutils literal"><span class="pre">CCIfCC</span></tt> 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
+<tt class="docutils literal"><span class="pre">X86CallingConv.td</span></tt>), if the <tt class="docutils literal"><span class="pre">Fast</span></tt> calling convention is in use, then
+<tt class="docutils literal"><span class="pre">RetCC_X86_32_Fast</span></tt> is invoked. If the <tt class="docutils literal"><span class="pre">SSECall</span></tt> calling convention is in
+use, then <tt class="docutils literal"><span class="pre">RetCC_X86_32_SSE</span></tt> is invoked.</p>
+<div class="highlight-text"><div class="highlight"><pre>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><tt class="docutils literal"><span class="pre">CCIf</span> <span class="pre"><predicate,</span> <span class="pre">action></span></tt> — If the predicate matches, apply the action.</li>
+<li><tt class="docutils literal"><span class="pre">CCIfInReg</span> <span class="pre"><action></span></tt> — If the argument is marked with the “<tt class="docutils literal"><span class="pre">inreg</span></tt>”
+attribute, then apply the action.</li>
+<li><tt class="docutils literal"><span class="pre">CCIfNest</span> <span class="pre"><action></span></tt> — If the argument is marked with the “<tt class="docutils literal"><span class="pre">nest</span></tt>”
+attribute, then apply the action.</li>
+<li><tt class="docutils literal"><span class="pre">CCIfNotVarArg</span> <span class="pre"><action></span></tt> — If the current function does not take a
+variable number of arguments, apply the action.</li>
+<li><tt class="docutils literal"><span class="pre">CCAssignToRegWithShadow</span> <span class="pre"><registerList,</span> <span class="pre">shadowList></span></tt> — similar to
+<tt class="docutils literal"><span class="pre">CCAssignToReg</span></tt>, but with a shadow list of registers.</li>
+<li><tt class="docutils literal"><span class="pre">CCPassByVal</span> <span class="pre"><size,</span> <span class="pre">align></span></tt> — Assign value to a stack slot with the
+minimum specified size and alignment.</li>
+<li><tt class="docutils literal"><span class="pre">CCPromoteToType</span> <span class="pre"><type></span></tt> — Promote the current value to the specified
+type.</li>
+<li><tt class="docutils literal"><span class="pre">CallingConv</span> <span class="pre"><[actions]></span></tt> — 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 <tt class="docutils literal"><span class="pre">XXXInstrInfo.td</span></tt> file. (See
+<a class="reference internal" href="#instruction-set"><em>Instruction Set</em></a>.) TableGen will produce an output file
+(<tt class="docutils literal"><span class="pre">XXXGenAsmWriter.inc</span></tt>) with an implementation of the <tt class="docutils literal"><span class="pre">printInstruction</span></tt>
+method for the <tt class="docutils literal"><span class="pre">XXXAsmPrinter</span></tt> class.</li>
+<li>Write <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo.h</span></tt>, which contains the bare-bones declaration of
+the <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo</span></tt> class (a subclass of <tt class="docutils literal"><span class="pre">TargetAsmInfo</span></tt>).</li>
+<li>Write <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo.cpp</span></tt>, which contains target-specific values for
+<tt class="docutils literal"><span class="pre">TargetAsmInfo</span></tt> properties and sometimes new implementations for methods.</li>
+<li>Write <tt class="docutils literal"><span class="pre">XXXAsmPrinter.cpp</span></tt>, which implements the <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> class that
+performs the LLVM-to-assembly conversion.</li>
+</ul>
+<p>The code in <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo.h</span></tt> is usually a trivial declaration of the
+<tt class="docutils literal"><span class="pre">XXXTargetAsmInfo</span></tt> class for use in <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo.cpp</span></tt>. Similarly,
+<tt class="docutils literal"><span class="pre">XXXTargetAsmInfo.cpp</span></tt> usually has a few declarations of <tt class="docutils literal"><span class="pre">XXXTargetAsmInfo</span></tt>
+replacement values that override the default values in <tt class="docutils literal"><span class="pre">TargetAsmInfo.cpp</span></tt>.
+For example in <tt class="docutils literal"><span class="pre">SparcTargetAsmInfo.cpp</span></tt>:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 (<tt class="docutils literal"><span class="pre">X86TargetAsmInfo</span></tt>) is an example
+where the target specific <tt class="docutils literal"><span class="pre">TargetAsmInfo</span></tt> class uses an overridden methods:
+<tt class="docutils literal"><span class="pre">ExpandInlineAsm</span></tt>.</p>
+<p>A target-specific implementation of <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> is written in
+<tt class="docutils literal"><span class="pre">XXXAsmPrinter.cpp</span></tt>, which implements the <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> class that converts
+the LLVM to printable assembly. The implementation must include the following
+headers that have declarations for the <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> and
+<tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt> classes. The <tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt> is a subclass of
+<tt class="docutils literal"><span class="pre">FunctionPass</span></tt>.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="cp">#include "llvm/CodeGen/AsmPrinter.h"</span>
+<span class="cp">#include "llvm/CodeGen/MachineFunctionPass.h"</span>
+</pre></div>
+</div>
+<p>As a <tt class="docutils literal"><span class="pre">FunctionPass</span></tt>, <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt> first calls <tt class="docutils literal"><span class="pre">doInitialization</span></tt> to set
+up the <tt class="docutils literal"><span class="pre">AsmPrinter</span></tt>. In <tt class="docutils literal"><span class="pre">SparcAsmPrinter</span></tt>, a <tt class="docutils literal"><span class="pre">Mangler</span></tt> object is
+instantiated to process variable names.</p>
+<p>In <tt class="docutils literal"><span class="pre">XXXAsmPrinter.cpp</span></tt>, the <tt class="docutils literal"><span class="pre">runOnMachineFunction</span></tt> method (declared in
+<tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt>) must be implemented for <tt class="docutils literal"><span class="pre">XXXAsmPrinter</span></tt>. In
+<tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt>, the <tt class="docutils literal"><span class="pre">runOnFunction</span></tt> method invokes
+<tt class="docutils literal"><span class="pre">runOnMachineFunction</span></tt>. Target-specific implementations of
+<tt class="docutils literal"><span class="pre">runOnMachineFunction</span></tt> differ, but generally do the following to process each
+machine function:</p>
+<ul class="simple">
+<li>Call <tt class="docutils literal"><span class="pre">SetupMachineFunction</span></tt> to perform initialization.</li>
+<li>Call <tt class="docutils literal"><span class="pre">EmitConstantPool</span></tt> to print out (to the output stream) constants which
+have been spilled to memory.</li>
+<li>Call <tt class="docutils literal"><span class="pre">EmitJumpTableInfo</span></tt> 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 <tt class="docutils literal"><span class="pre">printInstruction</span></tt>)</li>
+</ul>
+<p>The <tt class="docutils literal"><span class="pre">XXXAsmPrinter</span></tt> implementation must also include the code generated by
+TableGen that is output in the <tt class="docutils literal"><span class="pre">XXXGenAsmWriter.inc</span></tt> file. The code in
+<tt class="docutils literal"><span class="pre">XXXGenAsmWriter.inc</span></tt> contains an implementation of the <tt class="docutils literal"><span class="pre">printInstruction</span></tt>
+method that may call these methods:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">printOperand</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">printMemOperand</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">printCCOperand</span></tt> (for conditional statements)</li>
+<li><tt class="docutils literal"><span class="pre">printDataDirective</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">printDeclare</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">printImplicitDef</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">printInlineAsm</span></tt></li>
+</ul>
+<p>The implementations of <tt class="docutils literal"><span class="pre">printDeclare</span></tt>, <tt class="docutils literal"><span class="pre">printImplicitDef</span></tt>,
+<tt class="docutils literal"><span class="pre">printInlineAsm</span></tt>, and <tt class="docutils literal"><span class="pre">printLabel</span></tt> in <tt class="docutils literal"><span class="pre">AsmPrinter.cpp</span></tt> are generally
+adequate for printing assembly and do not need to be overridden.</p>
+<p>The <tt class="docutils literal"><span class="pre">printOperand</span></tt> method is implemented with a long <tt class="docutils literal"><span class="pre">switch</span></tt>/<tt class="docutils literal"><span class="pre">case</span></tt>
+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 <tt class="docutils literal"><span class="pre">printMemOperand</span></tt> method
+should be implemented to generate the proper output. Similarly,
+<tt class="docutils literal"><span class="pre">printCCOperand</span></tt> should be used to print a conditional operand.</p>
+<p><tt class="docutils literal"><span class="pre">doFinalization</span></tt> should be overridden in <tt class="docutils literal"><span class="pre">XXXAsmPrinter</span></tt>, and it should be
+called to shut down the assembly printer. During <tt class="docutils literal"><span class="pre">doFinalization</span></tt>, 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
+<tt class="docutils literal"><span class="pre">XXXSubtarget</span></tt> class for your architecture. This class should process the
+command-line options <tt class="docutils literal"><span class="pre">-mcpu=</span></tt> and <tt class="docutils literal"><span class="pre">-mattr=</span></tt>.</p>
+<p>TableGen uses definitions in the <tt class="docutils literal"><span class="pre">Target.td</span></tt> and <tt class="docutils literal"><span class="pre">Sparc.td</span></tt> files to
+generate code in <tt class="docutils literal"><span class="pre">SparcGenSubtarget.inc</span></tt>. In <tt class="docutils literal"><span class="pre">Target.td</span></tt>, shown below, the
+<tt class="docutils literal"><span class="pre">SubtargetFeature</span></tt> interface is defined. The first 4 string parameters of
+the <tt class="docutils literal"><span class="pre">SubtargetFeature</span></tt> 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">Sparc.td</span></tt> file, the <tt class="docutils literal"><span class="pre">SubtargetFeature</span></tt> is used to define the
+following features.</p>
+<div class="highlight-text"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">Sparc.td</span></tt>, the <tt class="docutils literal"><span class="pre">Proc</span></tt> 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"><div class="highlight"><pre>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 <tt class="docutils literal"><span class="pre">Target.td</span></tt> and <tt class="docutils literal"><span class="pre">Sparc.td</span></tt> files, the resulting
+<tt class="docutils literal"><span class="pre">SparcGenSubtarget.inc</span></tt> specifies enum values to identify the features,
+arrays of constants to represent the CPU features and CPU subtypes, and the
+<tt class="docutils literal"><span class="pre">ParseSubtargetFeatures</span></tt> method that parses the features string that sets
+specified subtarget options. The generated <tt class="docutils literal"><span class="pre">SparcGenSubtarget.inc</span></tt> file
+should be included in the <tt class="docutils literal"><span class="pre">SparcSubtarget.cpp</span></tt>. The target-specific
+implementation of the <tt class="docutils literal"><span class="pre">XXXSubtarget</span></tt> method should follow this pseudocode:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">XXXCodeEmitter.cpp</span></tt> file that contains a machine function pass
+that transforms target-machine instructions into relocatable machine
+code.</li>
+<li>Write an <tt class="docutils literal"><span class="pre">XXXJITInfo.cpp</span></tt> file that implements the JIT interfaces for
+target-specific code-generation activities, such as emitting machine code and
+stubs.</li>
+<li>Modify <tt class="docutils literal"><span class="pre">XXXTargetMachine</span></tt> so that it provides a <tt class="docutils literal"><span class="pre">TargetJITInfo</span></tt> object
+through its <tt class="docutils literal"><span class="pre">getJITInfo</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXGenCodeEmitter.inc</span></tt>, which
+contains the binary coding of machine instructions and the
+<tt class="docutils literal"><span class="pre">getBinaryCodeForInstr</span></tt> method to access those codes. Other JIT
+implementations do not.</p>
+<p>Both <tt class="docutils literal"><span class="pre">XXXJITInfo.cpp</span></tt> and <tt class="docutils literal"><span class="pre">XXXCodeEmitter.cpp</span></tt> must include the
+<tt class="docutils literal"><span class="pre">llvm/CodeGen/MachineCodeEmitter.h</span></tt> header file that defines the
+<tt class="docutils literal"><span class="pre">MachineCodeEmitter</span></tt> 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 <tt class="docutils literal"><span class="pre">XXXCodeEmitter.cpp</span></tt>, a target-specific of the <tt class="docutils literal"><span class="pre">Emitter</span></tt> class is
+implemented as a function pass (subclass of <tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt>). The
+target-specific implementation of <tt class="docutils literal"><span class="pre">runOnMachineFunction</span></tt> (invoked by
+<tt class="docutils literal"><span class="pre">runOnFunction</span></tt> in <tt class="docutils literal"><span class="pre">MachineFunctionPass</span></tt>) iterates through the
+<tt class="docutils literal"><span class="pre">MachineBasicBlock</span></tt> calls <tt class="docutils literal"><span class="pre">emitInstruction</span></tt> to process each instruction and
+emit binary code. <tt class="docutils literal"><span class="pre">emitInstruction</span></tt> is largely implemented with case
+statements on the instruction types defined in <tt class="docutils literal"><span class="pre">XXXInstrInfo.h</span></tt>. For
+example, in <tt class="docutils literal"><span class="pre">X86CodeEmitter.cpp</span></tt>, the <tt class="docutils literal"><span class="pre">emitInstruction</span></tt> method is built
+around the following <tt class="docutils literal"><span class="pre">switch</span></tt>/<tt class="docutils literal"><span class="pre">case</span></tt> statements:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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="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="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="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="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="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="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="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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM1r:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM3r:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM5r:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM7r:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM1m:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM3m:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM5m:</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="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">MRM7m:</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="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 <tt class="docutils literal"><span class="pre">X86CodeEmitter.cpp</span></tt>,
+for the <tt class="docutils literal"><span class="pre">X86II::AddRegFrm</span></tt> case, the first data emitted (by <tt class="docutils literal"><span class="pre">emitByte</span></tt>) is
+the opcode added to the register operand. Then an object representing the
+machine operand, <tt class="docutils literal"><span class="pre">MO1</span></tt>, is extracted. The helper methods such as
+<tt class="docutils literal"><span class="pre">isImmediate</span></tt>, <tt class="docutils literal"><span class="pre">isGlobalAddress</span></tt>, <tt class="docutils literal"><span class="pre">isExternalSymbol</span></tt>,
+<tt class="docutils literal"><span class="pre">isConstantPoolIndex</span></tt>, and <tt class="docutils literal"><span class="pre">isJumpTableIndex</span></tt> determine the operand type.
+(<tt class="docutils literal"><span class="pre">X86CodeEmitter.cpp</span></tt> also has private methods such as <tt class="docutils literal"><span class="pre">emitConstant</span></tt>,
+<tt class="docutils literal"><span class="pre">emitGlobalAddress</span></tt>, <tt class="docutils literal"><span class="pre">emitExternalSymbolAddress</span></tt>, <tt class="docutils literal"><span class="pre">emitConstPoolAddress</span></tt>,
+and <tt class="docutils literal"><span class="pre">emitJumpTableAddress</span></tt> that emit the data into the output stream.)</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">case</span> <span class="n">X86II</span><span class="o">::</span><span class="nl">AddRegFrm:</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="n">reloc_pcrel_word</span>
+ <span class="o">:</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="n">reloc_picrel_word</span> <span class="o">:</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="k">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="k">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, <tt class="docutils literal"><span class="pre">XXXCodeEmitter.cpp</span></tt> uses the variable <tt class="docutils literal"><span class="pre">rt</span></tt>, which
+is a <tt class="docutils literal"><span class="pre">RelocationType</span></tt> enum that may be used to relocate addresses (for
+example, a global address with a PIC base offset). The <tt class="docutils literal"><span class="pre">RelocationType</span></tt> enum
+for that target is defined in the short target-specific <tt class="docutils literal"><span class="pre">XXXRelocations.h</span></tt>
+file. The <tt class="docutils literal"><span class="pre">RelocationType</span></tt> is used by the <tt class="docutils literal"><span class="pre">relocate</span></tt> method defined in
+<tt class="docutils literal"><span class="pre">XXXJITInfo.cpp</span></tt> to rewrite addresses for referenced global symbols.</p>
+<p>For example, <tt class="docutils literal"><span class="pre">X86Relocations.h</span></tt> 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 <tt class="docutils literal"><span class="pre">reloc_pcrel_word</span></tt> and <tt class="docutils literal"><span class="pre">reloc_picrel_word</span></tt>,
+there is an additional initial adjustment.</p>
+<div class="highlight-c++"><div class="highlight"><pre><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><tt class="docutils literal"><span class="pre">XXXJITInfo.cpp</span></tt> implements the JIT interfaces for target-specific
+code-generation activities, such as emitting machine code and stubs. At
+minimum, a target-specific version of <tt class="docutils literal"><span class="pre">XXXJITInfo</span></tt> implements the following:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">getLazyResolverFunction</span></tt> — Initializes the JIT, gives the target a
+function that is used for compilation.</li>
+<li><tt class="docutils literal"><span class="pre">emitFunctionStub</span></tt> — Returns a native function with a specified address
+for a callback function.</li>
+<li><tt class="docutils literal"><span class="pre">relocate</span></tt> — 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><tt class="docutils literal"><span class="pre">getLazyResolverFunction</span></tt> is generally trivial to implement. It makes the
+incoming parameter as the global <tt class="docutils literal"><span class="pre">JITCompilerFunction</span></tt> and returns the
+callback function that will be used a function wrapper. For the Alpha target
+(in <tt class="docutils literal"><span class="pre">AlphaJITInfo.cpp</span></tt>), the <tt class="docutils literal"><span class="pre">getLazyResolverFunction</span></tt> implementation is
+simply:</p>
+<div class="highlight-c++"><div class="highlight"><pre><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 <tt class="docutils literal"><span class="pre">getLazyResolverFunction</span></tt> 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">
+ <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">
+ © Copyright 2003-2018, LLVM Project.
+ Last updated on 2018-07-02.
+ Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
+ </div>
+ </body>
+</html>
\ No newline at end of file
More information about the llvm-commits
mailing list