[www-releases] r290368 - Add 3.9.1 docs.

Tom Stellard via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 22 12:04:06 PST 2016


Added: www-releases/trunk/3.9.1/docs/HowToReleaseLLVM.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/HowToReleaseLLVM.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/HowToReleaseLLVM.html (added)
+++ www-releases/trunk/3.9.1/docs/HowToReleaseLLVM.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,567 @@
+
+<!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 Release LLVM To The Public — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="Advice on Packaging LLVM" href="Packaging.html" />
+    <link rel="prev" title="LLVMBuild Guide" href="LLVMBuild.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="Packaging.html" title="Advice on Packaging LLVM"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="LLVMBuild.html" title="LLVMBuild Guide"
+             accesskey="P">previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="how-to-release-llvm-to-the-public">
+<h1>How To Release LLVM To The Public<a class="headerlink" href="#how-to-release-llvm-to-the-public" 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="#release-timeline" id="id3">Release Timeline</a></li>
+<li><a class="reference internal" href="#release-process" id="id4">Release Process</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 information about successfully releasing LLVM —
+including subprojects: e.g., <tt class="docutils literal"><span class="pre">clang</span></tt> and <tt class="docutils literal"><span class="pre">dragonegg</span></tt> — to the public.  It
+is the Release Manager’s responsibility to ensure that a high quality build of
+LLVM is released.</p>
+<p>If you’re looking for the document on how to test the release candidates and
+create the binary packages, please refer to the <a class="reference internal" href="ReleaseProcess.html"><em>How To Validate a New Release</em></a> instead.</p>
+</div>
+<div class="section" id="release-timeline">
+<span id="timeline"></span><h2><a class="toc-backref" href="#id3">Release Timeline</a><a class="headerlink" href="#release-timeline" title="Permalink to this headline">¶</a></h2>
+<p>LLVM is released on a time based schedule — with major releases roughly
+every 6 months.  In between major releases there may be dot releases.
+The release manager will determine if and when to make a dot release based
+on feedback from the community.  Typically, dot releases should be made if
+there are large number of bug-fixes in the stable branch or a critical bug
+has been discovered that affects a large number of users.</p>
+<p>Unless otherwise stated, dot releases will follow the same procedure as
+major releases.</p>
+<p>The release process is roughly as follows:</p>
+<ul class="simple">
+<li>Set code freeze and branch creation date for 6 months after last code freeze
+date.  Announce release schedule to the LLVM community and update the website.</li>
+<li>Create release branch and begin release process.</li>
+<li>Send out release candidate sources for first round of testing.  Testing lasts
+7-10 days.  During the first round of testing, any regressions found should be
+fixed.  Patches are merged from mainline into the release branch.  Also, all
+features need to be completed during this time.  Any features not completed at
+the end of the first round of testing will be removed or disabled for the
+release.</li>
+<li>Generate and send out the second release candidate sources.  Only <em>critial</em>
+bugs found during this testing phase will be fixed.  Any bugs introduced by
+merged patches will be fixed.  If so a third round of testing is needed.</li>
+<li>The release notes are updated.</li>
+<li>Finally, release!</li>
+</ul>
+<p>The release process will be accelerated for dot releases.  If the first round
+of testing finds no critical bugs and no regressions since the last major release,
+then additional rounds of testing will not be required.</p>
+</div>
+<div class="section" id="release-process">
+<h2><a class="toc-backref" href="#id4">Release Process</a><a class="headerlink" href="#release-process" title="Permalink to this headline">¶</a></h2>
+<div class="contents local topic" id="id1">
+<ul class="simple">
+<li><a class="reference internal" href="#release-administrative-tasks" id="id5">Release Administrative Tasks</a><ul>
+<li><a class="reference internal" href="#create-release-branch" id="id6">Create Release Branch</a></li>
+<li><a class="reference internal" href="#update-llvm-version" id="id7">Update LLVM Version</a></li>
+<li><a class="reference internal" href="#tagging-the-llvm-release-candidates" id="id8">Tagging the LLVM Release Candidates</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#building-the-release" id="id9">Building the Release</a><ul>
+<li><a class="reference internal" href="#build-llvm" id="id10">Build LLVM</a></li>
+<li><a class="reference internal" href="#build-clang-binary-distribution" id="id11">Build Clang Binary Distribution</a></li>
+<li><a class="reference internal" href="#target-specific-build-details" id="id12">Target Specific Build Details</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#release-qualification-criteria" id="id13">Release Qualification Criteria</a><ul>
+<li><a class="reference internal" href="#qualify-llvm" id="id14">Qualify LLVM</a></li>
+<li><a class="reference internal" href="#qualify-clang" id="id15">Qualify Clang</a></li>
+<li><a class="reference internal" href="#specific-target-qualification-details" id="id16">Specific Target Qualification Details</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#community-testing" id="id17">Community Testing</a></li>
+<li><a class="reference internal" href="#release-patch-rules" id="id18">Release Patch Rules</a><ul>
+<li><a class="reference internal" href="#merging-patches" id="id19">Merging Patches</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#release-final-tasks" id="id20">Release Final Tasks</a><ul>
+<li><a class="reference internal" href="#update-documentation" id="id21">Update Documentation</a></li>
+<li><a class="reference internal" href="#tag-the-llvm-final-release" id="id22">Tag the LLVM Final Release</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#update-the-llvm-demo-page" id="id23">Update the LLVM Demo Page</a><ul>
+<li><a class="reference internal" href="#update-the-llvm-website" id="id24">Update the LLVM Website</a></li>
+<li><a class="reference internal" href="#announce-the-release" id="id25">Announce the Release</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="release-administrative-tasks">
+<h3><a class="toc-backref" href="#id5">Release Administrative Tasks</a><a class="headerlink" href="#release-administrative-tasks" title="Permalink to this headline">¶</a></h3>
+<p>This section describes a few administrative tasks that need to be done for the
+release process to begin.  Specifically, it involves:</p>
+<ul class="simple">
+<li>Creating the release branch,</li>
+<li>Setting version numbers, and</li>
+<li>Tagging release candidates for the release team to begin testing.</li>
+</ul>
+<div class="section" id="create-release-branch">
+<h4><a class="toc-backref" href="#id6">Create Release Branch</a><a class="headerlink" href="#create-release-branch" title="Permalink to this headline">¶</a></h4>
+<p>Branch the Subversion trunk using the following procedure:</p>
+<ol class="arabic">
+<li><p class="first">Remind developers that the release branching is imminent and to refrain from
+committing patches that might break the build.  E.g., new features, large
+patches for works in progress, an overhaul of the type system, an exciting
+new TableGen feature, etc.</p>
+</li>
+<li><p class="first">Verify that the current Subversion trunk is in decent shape by
+examining nightly tester and buildbot results.</p>
+</li>
+<li><p class="first">Create the release branch for <tt class="docutils literal"><span class="pre">llvm</span></tt>, <tt class="docutils literal"><span class="pre">clang</span></tt>, the <tt class="docutils literal"><span class="pre">test-suite</span></tt>, and
+<tt class="docutils literal"><span class="pre">dragonegg</span></tt> from the last known good revision.  The branch’s name is
+<tt class="docutils literal"><span class="pre">release_XY</span></tt>, where <tt class="docutils literal"><span class="pre">X</span></tt> is the major and <tt class="docutils literal"><span class="pre">Y</span></tt> the minor release
+numbers.  The branches should be created using the following commands:</p>
+<div class="highlight-python"><div class="highlight"><pre>$ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
+           https://llvm.org/svn/llvm-project/llvm/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
+           https://llvm.org/svn/llvm-project/cfe/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/dragonegg/trunk \
+           https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
+           https://llvm.org/svn/llvm-project/test-suite/branches/release_XY
+</pre></div>
+</div>
+</li>
+<li><p class="first">Advise developers that they may now check their patches into the Subversion
+tree again.</p>
+</li>
+<li><p class="first">The Release Manager should switch to the release branch, because all changes
+to the release will now be done in the branch.  The easiest way to do this is
+to grab a working copy using the following commands:</p>
+<div class="highlight-python"><div class="highlight"><pre>$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY dragonegg-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
+</pre></div>
+</div>
+</li>
+</ol>
+</div>
+<div class="section" id="update-llvm-version">
+<h4><a class="toc-backref" href="#id7">Update LLVM Version</a><a class="headerlink" href="#update-llvm-version" title="Permalink to this headline">¶</a></h4>
+<p>After creating the LLVM release branch, update the release branches’
+<tt class="docutils literal"><span class="pre">autoconf</span></tt> and <tt class="docutils literal"><span class="pre">configure.ac</span></tt> versions from ‘<tt class="docutils literal"><span class="pre">X.Ysvn</span></tt>‘ to ‘<tt class="docutils literal"><span class="pre">X.Y</span></tt>‘.
+Update it on mainline as well to be the next version (‘<tt class="docutils literal"><span class="pre">X.Y+1svn</span></tt>‘).
+Regenerate the configure scripts for both <tt class="docutils literal"><span class="pre">llvm</span></tt> and the <tt class="docutils literal"><span class="pre">test-suite</span></tt>.</p>
+<p>In addition, the version numbers of all the Bugzilla components must be updated
+for the next release.</p>
+</div>
+<div class="section" id="tagging-the-llvm-release-candidates">
+<h4><a class="toc-backref" href="#id8">Tagging the LLVM Release Candidates</a><a class="headerlink" href="#tagging-the-llvm-release-candidates" title="Permalink to this headline">¶</a></h4>
+<p>Tag release candidates using the tag.sh script in utils/release.</p>
+<div class="highlight-python"><div class="highlight"><pre>$ ./tag.sh -release X.Y.Z -rc $RC
+</pre></div>
+</div>
+<p>The Release Manager may supply pre-packaged source tarballs for users.  This can
+be done with the export.sh script in utils/release.</p>
+<div class="highlight-python"><div class="highlight"><pre>$ ./export.sh -release X.Y.Z -rc $RC
+</pre></div>
+</div>
+<p>This will generate source tarballs for each LLVM project being validated, which
+can be uploaded to the website for further testing.</p>
+</div>
+</div>
+<div class="section" id="building-the-release">
+<h3><a class="toc-backref" href="#id9">Building the Release</a><a class="headerlink" href="#building-the-release" title="Permalink to this headline">¶</a></h3>
+<p>The builds of <tt class="docutils literal"><span class="pre">llvm</span></tt>, <tt class="docutils literal"><span class="pre">clang</span></tt>, and <tt class="docutils literal"><span class="pre">dragonegg</span></tt> <em>must</em> be free of
+errors and warnings in Debug, Release+Asserts, and Release builds.  If all
+builds are clean, then the release passes Build Qualification.</p>
+<p>The <tt class="docutils literal"><span class="pre">make</span></tt> options for building the different modes:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="27%" />
+<col width="73%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Mode</th>
+<th class="head">Options</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>Debug</td>
+<td><tt class="docutils literal"><span class="pre">ENABLE_OPTIMIZED=0</span></tt></td>
+</tr>
+<tr class="row-odd"><td>Release+Asserts</td>
+<td><tt class="docutils literal"><span class="pre">ENABLE_OPTIMIZED=1</span></tt></td>
+</tr>
+<tr class="row-even"><td>Release</td>
+<td><tt class="docutils literal"><span class="pre">ENABLE_OPTIMIZED=1</span> <span class="pre">DISABLE_ASSERTIONS=1</span></tt></td>
+</tr>
+</tbody>
+</table>
+<div class="section" id="build-llvm">
+<h4><a class="toc-backref" href="#id10">Build LLVM</a><a class="headerlink" href="#build-llvm" title="Permalink to this headline">¶</a></h4>
+<p>Build <tt class="docutils literal"><span class="pre">Debug</span></tt>, <tt class="docutils literal"><span class="pre">Release+Asserts</span></tt>, and <tt class="docutils literal"><span class="pre">Release</span></tt> versions
+of <tt class="docutils literal"><span class="pre">llvm</span></tt> on all supported platforms.  Directions to build <tt class="docutils literal"><span class="pre">llvm</span></tt>
+are <a class="reference internal" href="GettingStarted.html"><em>here</em></a>.</p>
+</div>
+<div class="section" id="build-clang-binary-distribution">
+<h4><a class="toc-backref" href="#id11">Build Clang Binary Distribution</a><a class="headerlink" href="#build-clang-binary-distribution" title="Permalink to this headline">¶</a></h4>
+<p>Creating the <tt class="docutils literal"><span class="pre">clang</span></tt> binary distribution (Debug/Release+Asserts/Release)
+requires performing the following steps for each supported platform:</p>
+<ol class="arabic simple">
+<li>Build clang according to the directions <a class="reference external" href="http://clang.llvm.org/get_started.html">here</a>.</li>
+<li>Build both a Debug and Release version of clang.  The binary will be the
+Release build.</li>
+<li>Package <tt class="docutils literal"><span class="pre">clang</span></tt> (details to follow).</li>
+</ol>
+</div>
+<div class="section" id="target-specific-build-details">
+<h4><a class="toc-backref" href="#id12">Target Specific Build Details</a><a class="headerlink" href="#target-specific-build-details" title="Permalink to this headline">¶</a></h4>
+<p>The table below specifies which compilers are used for each Arch/OS combination
+when qualifying the build of <tt class="docutils literal"><span class="pre">llvm</span></tt>, <tt class="docutils literal"><span class="pre">clang</span></tt>, and <tt class="docutils literal"><span class="pre">dragonegg</span></tt>.</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="27%" />
+<col width="29%" />
+<col width="43%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Architecture</th>
+<th class="head">OS</th>
+<th class="head">compiler</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>x86-32</td>
+<td>Mac OS 10.5</td>
+<td>gcc 4.0.1</td>
+</tr>
+<tr class="row-odd"><td>x86-32</td>
+<td>Linux</td>
+<td>gcc 4.2.X, gcc 4.3.X</td>
+</tr>
+<tr class="row-even"><td>x86-32</td>
+<td>FreeBSD</td>
+<td>gcc 4.2.X</td>
+</tr>
+<tr class="row-odd"><td>x86-32</td>
+<td>mingw</td>
+<td>gcc 3.4.5</td>
+</tr>
+<tr class="row-even"><td>x86-64</td>
+<td>Mac OS 10.5</td>
+<td>gcc 4.0.1</td>
+</tr>
+<tr class="row-odd"><td>x86-64</td>
+<td>Linux</td>
+<td>gcc 4.2.X, gcc 4.3.X</td>
+</tr>
+<tr class="row-even"><td>x86-64</td>
+<td>FreeBSD</td>
+<td>gcc 4.2.X</td>
+</tr>
+<tr class="row-odd"><td>ARMv7</td>
+<td>Linux</td>
+<td>gcc 4.6.X, gcc 4.7.X</td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="section" id="release-qualification-criteria">
+<h3><a class="toc-backref" href="#id13">Release Qualification Criteria</a><a class="headerlink" href="#release-qualification-criteria" title="Permalink to this headline">¶</a></h3>
+<p>A release is qualified when it has no regressions from the previous release (or
+baseline).  Regressions are related to correctness first and performance second.
+(We may tolerate some minor performance regressions if they are deemed
+necessary for the general quality of the compiler.)</p>
+<p><strong>Regressions are new failures in the set of tests that are used to qualify
+each product and only include things on the list.  Every release will have
+some bugs in it.  It is the reality of developing a complex piece of
+software.  We need a very concrete and definitive release criteria that
+ensures we have monotonically improving quality on some metric.  The metric we
+use is described below.  This doesn’t mean that we don’t care about other
+criteria, but these are the criteria which we found to be most important and
+which must be satisfied before a release can go out.</strong></p>
+<div class="section" id="qualify-llvm">
+<h4><a class="toc-backref" href="#id14">Qualify LLVM</a><a class="headerlink" href="#qualify-llvm" title="Permalink to this headline">¶</a></h4>
+<p>LLVM is qualified when it has a clean test run without a front-end.  And it has
+no regressions when using either <tt class="docutils literal"><span class="pre">clang</span></tt> or <tt class="docutils literal"><span class="pre">dragonegg</span></tt> with the
+<tt class="docutils literal"><span class="pre">test-suite</span></tt> from the previous release.</p>
+</div>
+<div class="section" id="qualify-clang">
+<h4><a class="toc-backref" href="#id15">Qualify Clang</a><a class="headerlink" href="#qualify-clang" title="Permalink to this headline">¶</a></h4>
+<p><tt class="docutils literal"><span class="pre">Clang</span></tt> is qualified when front-end specific tests in the <tt class="docutils literal"><span class="pre">llvm</span></tt> regression
+test suite all pass, clang’s own test suite passes cleanly, and there are no
+regressions in the <tt class="docutils literal"><span class="pre">test-suite</span></tt>.</p>
+</div>
+<div class="section" id="specific-target-qualification-details">
+<h4><a class="toc-backref" href="#id16">Specific Target Qualification Details</a><a class="headerlink" href="#specific-target-qualification-details" title="Permalink to this headline">¶</a></h4>
+<table border="1" class="docutils">
+<colgroup>
+<col width="19%" />
+<col width="18%" />
+<col width="22%" />
+<col width="40%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Architecture</th>
+<th class="head">OS</th>
+<th class="head">clang baseline</th>
+<th class="head">tests</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>x86-32</td>
+<td>Linux</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite (including spec)</td>
+</tr>
+<tr class="row-odd"><td>x86-32</td>
+<td>FreeBSD</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite</td>
+</tr>
+<tr class="row-even"><td>x86-32</td>
+<td>mingw</td>
+<td>none</td>
+<td>QT</td>
+</tr>
+<tr class="row-odd"><td>x86-64</td>
+<td>Mac OS 10.X</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite (including spec)</td>
+</tr>
+<tr class="row-even"><td>x86-64</td>
+<td>Linux</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite (including spec)</td>
+</tr>
+<tr class="row-odd"><td>x86-64</td>
+<td>FreeBSD</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite</td>
+</tr>
+<tr class="row-even"><td>ARMv7A</td>
+<td>Linux</td>
+<td>last release</td>
+<td>llvm regression tests,
+clang regression tests,
+test-suite</td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="section" id="community-testing">
+<h3><a class="toc-backref" href="#id17">Community Testing</a><a class="headerlink" href="#community-testing" title="Permalink to this headline">¶</a></h3>
+<p>Once all testing has been completed and appropriate bugs filed, the release
+candidate tarballs are put on the website and the LLVM community is notified.
+Ask that all LLVM developers test the release in 2 ways:</p>
+<ol class="arabic simple">
+<li>Download <tt class="docutils literal"><span class="pre">llvm-X.Y</span></tt>, <tt class="docutils literal"><span class="pre">llvm-test-X.Y</span></tt>, and the appropriate <tt class="docutils literal"><span class="pre">clang</span></tt>
+binary.  Build LLVM.  Run <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> and the full LLVM test suite (<tt class="docutils literal"><span class="pre">make</span>
+<span class="pre">TEST=nightly</span> <span class="pre">report</span></tt>).</li>
+<li>Download <tt class="docutils literal"><span class="pre">llvm-X.Y</span></tt>, <tt class="docutils literal"><span class="pre">llvm-test-X.Y</span></tt>, and the <tt class="docutils literal"><span class="pre">clang</span></tt> sources.  Compile
+everything.  Run <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> and the full LLVM test suite (<tt class="docutils literal"><span class="pre">make</span>
+<span class="pre">TEST=nightly</span> <span class="pre">report</span></tt>).</li>
+</ol>
+<p>Ask LLVM developers to submit the test suite report and <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> results
+to the list.  Verify that there are no regressions from the previous release.
+The results are not used to qualify a release, but to spot other potential
+problems.  For unsupported targets, verify that <tt class="docutils literal"><span class="pre">make</span> <span class="pre">check</span></tt> is at least
+clean.</p>
+<p>During the first round of testing, all regressions must be fixed before the
+second release candidate is tagged.</p>
+<p>If this is the second round of testing, the testing is only to ensure that bug
+fixes previously merged in have not created new major problems. <em>This is not
+the time to solve additional and unrelated bugs!</em> If no patches are merged in,
+the release is determined to be ready and the release manager may move onto the
+next stage.</p>
+</div>
+<div class="section" id="release-patch-rules">
+<h3><a class="toc-backref" href="#id18">Release Patch Rules</a><a class="headerlink" href="#release-patch-rules" title="Permalink to this headline">¶</a></h3>
+<p>Below are the rules regarding patching the release branch:</p>
+<ol class="arabic simple">
+<li>Patches applied to the release branch may only be applied by the release
+manager.</li>
+<li>During the first round of testing, patches that fix regressions or that are
+small and relatively risk free (verified by the appropriate code owner) are
+applied to the branch.  Code owners are asked to be very conservative in
+approving patches for the branch.  We reserve the right to reject any patch
+that does not fix a regression as previously defined.</li>
+<li>During the remaining rounds of testing, only patches that fix critical
+regressions may be applied.</li>
+<li>For dot releases all patches must maintain both API and ABI compatibility with
+the previous major release.  Only bugfixes will be accepted.</li>
+</ol>
+<div class="section" id="merging-patches">
+<h4><a class="toc-backref" href="#id19">Merging Patches</a><a class="headerlink" href="#merging-patches" title="Permalink to this headline">¶</a></h4>
+<p>The <tt class="docutils literal"><span class="pre">utils/release/merge.sh</span></tt> script can be used to merge individual revisions
+into any one of the llvm projects. To merge revision <tt class="docutils literal"><span class="pre">$N</span></tt> into project
+<tt class="docutils literal"><span class="pre">$PROJ</span></tt>, do:</p>
+<ol class="arabic simple">
+<li><tt class="docutils literal"><span class="pre">svn</span> <span class="pre">co</span> <span class="pre">https://llvm.org/svn/llvm-project/$PROJ/branches/release_XX</span>
+<span class="pre">$PROJ.src</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">$PROJ.src/utils/release/merge.sh</span> <span class="pre">--proj</span> <span class="pre">$PROJ</span> <span class="pre">--rev</span> <span class="pre">$N</span></tt></li>
+<li>Run regression tests.</li>
+<li><tt class="docutils literal"><span class="pre">cd</span> <span class="pre">$PROJ.src</span></tt>. Run the <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">commit</span></tt> command printed out by <tt class="docutils literal"><span class="pre">merge.sh</span></tt>
+in step 2.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="release-final-tasks">
+<h3><a class="toc-backref" href="#id20">Release Final Tasks</a><a class="headerlink" href="#release-final-tasks" title="Permalink to this headline">¶</a></h3>
+<p>The final stages of the release process involves tagging the “final” release
+branch, updating documentation that refers to the release, and updating the
+demo page.</p>
+<div class="section" id="update-documentation">
+<h4><a class="toc-backref" href="#id21">Update Documentation</a><a class="headerlink" href="#update-documentation" title="Permalink to this headline">¶</a></h4>
+<p>Review the documentation and ensure that it is up to date.  The “Release Notes”
+must be updated to reflect new features, bug fixes, new known issues, and
+changes in the list of supported platforms.  The “Getting Started Guide” should
+be updated to reflect the new release version number tag available from
+Subversion and changes in basic system requirements.  Merge both changes from
+mainline into the release branch.</p>
+</div>
+<div class="section" id="tag-the-llvm-final-release">
+<span id="tag"></span><h4><a class="toc-backref" href="#id22">Tag the LLVM Final Release</a><a class="headerlink" href="#tag-the-llvm-final-release" title="Permalink to this headline">¶</a></h4>
+<p>Tag the final release sources using the tag.sh script in utils/release.</p>
+<div class="highlight-python"><div class="highlight"><pre>$ ./tag.sh -release X.Y.Z -final
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="update-the-llvm-demo-page">
+<h3><a class="toc-backref" href="#id23">Update the LLVM Demo Page</a><a class="headerlink" href="#update-the-llvm-demo-page" title="Permalink to this headline">¶</a></h3>
+<p>The LLVM demo page must be updated to use the new release.  This consists of
+using the new <tt class="docutils literal"><span class="pre">clang</span></tt> binary and building LLVM.</p>
+<div class="section" id="update-the-llvm-website">
+<h4><a class="toc-backref" href="#id24">Update the LLVM Website</a><a class="headerlink" href="#update-the-llvm-website" title="Permalink to this headline">¶</a></h4>
+<p>The website must be updated before the release announcement is sent out.  Here
+is what to do:</p>
+<ol class="arabic simple">
+<li>Check out the <tt class="docutils literal"><span class="pre">www</span></tt> module from Subversion.</li>
+<li>Create a new subdirectory <tt class="docutils literal"><span class="pre">X.Y</span></tt> in the releases directory.</li>
+<li>Commit the <tt class="docutils literal"><span class="pre">llvm</span></tt>, <tt class="docutils literal"><span class="pre">test-suite</span></tt>, <tt class="docutils literal"><span class="pre">clang</span></tt> source, <tt class="docutils literal"><span class="pre">clang</span> <span class="pre">binaries</span></tt>,
+<tt class="docutils literal"><span class="pre">dragonegg</span></tt> source, and <tt class="docutils literal"><span class="pre">dragonegg</span></tt> binaries in this new directory.</li>
+<li>Copy and commit the <tt class="docutils literal"><span class="pre">llvm/docs</span></tt> and <tt class="docutils literal"><span class="pre">LICENSE.txt</span></tt> files into this new
+directory.  The docs should be built with <tt class="docutils literal"><span class="pre">BUILD_FOR_WEBSITE=1</span></tt>.</li>
+<li>Commit the <tt class="docutils literal"><span class="pre">index.html</span></tt> to the <tt class="docutils literal"><span class="pre">release/X.Y</span></tt> directory to redirect (use
+from previous release).</li>
+<li>Update the <tt class="docutils literal"><span class="pre">releases/download.html</span></tt> file with the new release.</li>
+<li>Update the <tt class="docutils literal"><span class="pre">releases/index.html</span></tt> with the new release and link to release
+documentation.</li>
+<li>Finally, update the main page (<tt class="docutils literal"><span class="pre">index.html</span></tt> and sidebar) to point to the
+new release and release announcement.  Make sure this all gets committed back
+into Subversion.</li>
+</ol>
+</div>
+<div class="section" id="announce-the-release">
+<h4><a class="toc-backref" href="#id25">Announce the Release</a><a class="headerlink" href="#announce-the-release" title="Permalink to this headline">¶</a></h4>
+<p>Have Chris send out the release announcement when everything is finished.</p>
+</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="Packaging.html" title="Advice on Packaging LLVM"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="LLVMBuild.html" title="LLVMBuild Guide"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+ 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/HowToSetUpLLVMStyleRTTI.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/HowToSetUpLLVMStyleRTTI.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/HowToSetUpLLVMStyleRTTI.html (added)
+++ www-releases/trunk/3.9.1/docs/HowToSetUpLLVMStyleRTTI.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,474 @@
+
+<!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 set up LLVM-style RTTI for your class hierarchy — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="LLVM Programmer’s Manual" href="ProgrammersManual.html" />
+    <link rel="prev" title="Extending LLVM: Adding instructions, intrinsics, types, etc." href="ExtendingLLVM.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="ProgrammersManual.html" title="LLVM Programmer’s Manual"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="ExtendingLLVM.html" title="Extending LLVM: Adding instructions, intrinsics, types, etc."
+             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-set-up-llvm-style-rtti-for-your-class-hierarchy">
+<h1><a class="toc-backref" href="#id1">How to set up LLVM-style RTTI for your class hierarchy</a><a class="headerlink" href="#how-to-set-up-llvm-style-rtti-for-your-class-hierarchy" title="Permalink to this headline">¶</a></h1>
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#how-to-set-up-llvm-style-rtti-for-your-class-hierarchy" id="id1">How to set up LLVM-style RTTI for your class hierarchy</a><ul>
+<li><a class="reference internal" href="#background" id="id2">Background</a></li>
+<li><a class="reference internal" href="#basic-setup" id="id3">Basic Setup</a></li>
+<li><a class="reference internal" href="#concrete-bases-and-deeper-hierarchies" id="id4">Concrete Bases and Deeper Hierarchies</a><ul>
+<li><a class="reference internal" href="#a-bug-to-be-aware-of" id="id5">A Bug to be Aware Of</a></li>
+<li><a class="reference internal" href="#the-contract-of-classof" id="id6">The Contract of <tt class="docutils literal"><span class="pre">classof</span></tt></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#rules-of-thumb" id="id7">Rules of Thumb</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="background">
+<h2><a class="toc-backref" href="#id2">Background</a><a class="headerlink" href="#background" title="Permalink to this headline">¶</a></h2>
+<p>LLVM avoids using C++’s built in RTTI. Instead, it  pervasively uses its
+own hand-rolled form of RTTI which is much more efficient and flexible,
+although it requires a bit more work from you as a class author.</p>
+<p>A description of how to use LLVM-style RTTI from a client’s perspective is
+given in the <a class="reference external" href="ProgrammersManual.html#isa">Programmer’s Manual</a>. This
+document, in contrast, discusses the steps you need to take as a class
+hierarchy author to make LLVM-style RTTI available to your clients.</p>
+<p>Before diving in, make sure that you are familiar with the Object Oriented
+Programming concept of “<a class="reference external" href="http://en.wikipedia.org/wiki/Is-a">is-a</a>”.</p>
+</div>
+<div class="section" id="basic-setup">
+<h2><a class="toc-backref" href="#id3">Basic Setup</a><a class="headerlink" href="#basic-setup" title="Permalink to this headline">¶</a></h2>
+<p>This section describes how to set up the most basic form of LLVM-style RTTI
+(which is sufficient for 99.9% of the cases). We will set up LLVM-style
+RTTI for this class hierarchy:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Shape</span> <span class="p">{</span>
+<span class="nl">public:</span>
+  <span class="n">Shape</span><span class="p">()</span> <span class="p">{}</span>
+  <span class="k">virtual</span> <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">};</span>
+
+<span class="k">class</span> <span class="nc">Square</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+  <span class="kt">double</span> <span class="n">SideLength</span><span class="p">;</span>
+<span class="nl">public:</span>
+  <span class="n">Square</span><span class="p">(</span><span class="kt">double</span> <span class="n">S</span><span class="p">)</span> <span class="o">:</span> <span class="n">SideLength</span><span class="p">(</span><span class="n">S</span><span class="p">)</span> <span class="p">{}</span>
+  <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+<span class="p">};</span>
+
+<span class="k">class</span> <span class="nc">Circle</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+  <span class="kt">double</span> <span class="n">Radius</span><span class="p">;</span>
+<span class="nl">public:</span>
+  <span class="n">Circle</span><span class="p">(</span><span class="kt">double</span> <span class="n">R</span><span class="p">)</span> <span class="o">:</span> <span class="n">Radius</span><span class="p">(</span><span class="n">R</span><span class="p">)</span> <span class="p">{}</span>
+  <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The most basic working setup for LLVM-style RTTI requires the following
+steps:</p>
+<ol class="arabic">
+<li><p class="first">In the header where you declare <tt class="docutils literal"><span class="pre">Shape</span></tt>, you will want to <tt class="docutils literal"><span class="pre">#include</span>
+<span class="pre">"llvm/Support/Casting.h"</span></tt>, which declares LLVM’s RTTI templates. That
+way your clients don’t even have to think about it.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="cp">#include "llvm/Support/Casting.h"</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">In the base class, introduce an enum which discriminates all of the
+different concrete classes in the hierarchy, and stash the enum value
+somewhere in the base class.</p>
+<p>Here is the code after introducing this change:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">class</span> <span class="nc">Shape</span> <span class="p">{</span>
+ <span class="nl">public:</span>
+<span class="o">+</span>  <span class="c1">/// Discriminator for LLVM-style RTTI (dyn_cast<> et al.)</span>
+<span class="o">+</span>  <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+<span class="o">+</span>    <span class="n">SK_Square</span><span class="p">,</span>
+<span class="o">+</span>    <span class="n">SK_Circle</span>
+<span class="o">+</span>  <span class="p">};</span>
+<span class="o">+</span><span class="k">private</span><span class="o">:</span>
+<span class="o">+</span>  <span class="k">const</span> <span class="n">ShapeKind</span> <span class="n">Kind</span><span class="p">;</span>
+<span class="o">+</span><span class="k">public</span><span class="o">:</span>
+<span class="o">+</span>  <span class="n">ShapeKind</span> <span class="n">getKind</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="n">Kind</span><span class="p">;</span> <span class="p">}</span>
+<span class="o">+</span>
+   <span class="n">Shape</span><span class="p">()</span> <span class="p">{}</span>
+   <span class="k">virtual</span> <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="p">};</span>
+</pre></div>
+</div>
+<p>You will usually want to keep the <tt class="docutils literal"><span class="pre">Kind</span></tt> member encapsulated and
+private, but let the enum <tt class="docutils literal"><span class="pre">ShapeKind</span></tt> be public along with providing a
+<tt class="docutils literal"><span class="pre">getKind()</span></tt> method. This is convenient for clients so that they can do
+a <tt class="docutils literal"><span class="pre">switch</span></tt> over the enum.</p>
+<p>A common naming convention is that these enums are “kind”s, to avoid
+ambiguity with the words “type” or “class” which have overloaded meanings
+in many contexts within LLVM. Sometimes there will be a natural name for
+it, like “opcode”. Don’t bikeshed over this; when in doubt use <tt class="docutils literal"><span class="pre">Kind</span></tt>.</p>
+<p>You might wonder why the <tt class="docutils literal"><span class="pre">Kind</span></tt> enum doesn’t have an entry for
+<tt class="docutils literal"><span class="pre">Shape</span></tt>. The reason for this is that since <tt class="docutils literal"><span class="pre">Shape</span></tt> is abstract
+(<tt class="docutils literal"><span class="pre">computeArea()</span> <span class="pre">=</span> <span class="pre">0;</span></tt>), you will never actually have non-derived
+instances of exactly that class (only subclasses). See <a class="reference internal" href="#concrete-bases-and-deeper-hierarchies">Concrete Bases
+and Deeper Hierarchies</a> for information on how to deal with
+non-abstract bases. It’s worth mentioning here that unlike
+<tt class="docutils literal"><span class="pre">dynamic_cast<></span></tt>, LLVM-style RTTI can be used (and is often used) for
+classes that don’t have v-tables.</p>
+</li>
+<li><p class="first">Next, you need to make sure that the <tt class="docutils literal"><span class="pre">Kind</span></tt> gets initialized to the
+value corresponding to the dynamic type of the class. Typically, you will
+want to have it be an argument to the constructor of the base class, and
+then pass in the respective <tt class="docutils literal"><span class="pre">XXXKind</span></tt> from subclass constructors.</p>
+<p>Here is the code after that change:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">class</span> <span class="nc">Shape</span> <span class="p">{</span>
+ <span class="nl">public:</span>
+   <span class="c1">/// Discriminator for LLVM-style RTTI (dyn_cast<> et al.)</span>
+   <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+     <span class="n">SK_Square</span><span class="p">,</span>
+     <span class="n">SK_Circle</span>
+   <span class="p">};</span>
+ <span class="nl">private:</span>
+   <span class="k">const</span> <span class="n">ShapeKind</span> <span class="n">Kind</span><span class="p">;</span>
+ <span class="nl">public:</span>
+   <span class="n">ShapeKind</span> <span class="n">getKind</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="n">Kind</span><span class="p">;</span> <span class="p">}</span>
+
+<span class="o">-</span>  <span class="n">Shape</span><span class="p">()</span> <span class="p">{}</span>
+<span class="o">+</span>  <span class="n">Shape</span><span class="p">(</span><span class="n">ShapeKind</span> <span class="n">K</span><span class="p">)</span> <span class="o">:</span> <span class="n">Kind</span><span class="p">(</span><span class="n">K</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="k">virtual</span> <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="p">};</span>
+
+ <span class="k">class</span> <span class="nc">Square</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+   <span class="kt">double</span> <span class="n">SideLength</span><span class="p">;</span>
+ <span class="nl">public:</span>
+<span class="o">-</span>  <span class="n">Square</span><span class="p">(</span><span class="kt">double</span> <span class="n">S</span><span class="p">)</span> <span class="o">:</span> <span class="n">SideLength</span><span class="p">(</span><span class="n">S</span><span class="p">)</span> <span class="p">{}</span>
+<span class="o">+</span>  <span class="n">Square</span><span class="p">(</span><span class="kt">double</span> <span class="n">S</span><span class="p">)</span> <span class="o">:</span> <span class="n">Shape</span><span class="p">(</span><span class="n">SK_Square</span><span class="p">),</span> <span class="n">SideLength</span><span class="p">(</span><span class="n">S</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+ <span class="p">};</span>
+
+ <span class="k">class</span> <span class="nc">Circle</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+   <span class="kt">double</span> <span class="n">Radius</span><span class="p">;</span>
+ <span class="nl">public:</span>
+<span class="o">-</span>  <span class="n">Circle</span><span class="p">(</span><span class="kt">double</span> <span class="n">R</span><span class="p">)</span> <span class="o">:</span> <span class="n">Radius</span><span class="p">(</span><span class="n">R</span><span class="p">)</span> <span class="p">{}</span>
+<span class="o">+</span>  <span class="n">Circle</span><span class="p">(</span><span class="kt">double</span> <span class="n">R</span><span class="p">)</span> <span class="o">:</span> <span class="n">Shape</span><span class="p">(</span><span class="n">SK_Circle</span><span class="p">),</span> <span class="n">Radius</span><span class="p">(</span><span class="n">R</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+ <span class="p">};</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">Finally, you need to inform LLVM’s RTTI templates how to dynamically
+determine the type of a class (i.e. whether the <tt class="docutils literal"><span class="pre">isa<></span></tt>/<tt class="docutils literal"><span class="pre">dyn_cast<></span></tt>
+should succeed). The default “99.9% of use cases” way to accomplish this
+is through a small static member function <tt class="docutils literal"><span class="pre">classof</span></tt>. In order to have
+proper context for an explanation, we will display this code first, and
+then below describe each part:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">class</span> <span class="nc">Shape</span> <span class="p">{</span>
+ <span class="nl">public:</span>
+   <span class="c1">/// Discriminator for LLVM-style RTTI (dyn_cast<> et al.)</span>
+   <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+     <span class="n">SK_Square</span><span class="p">,</span>
+     <span class="n">SK_Circle</span>
+   <span class="p">};</span>
+ <span class="nl">private:</span>
+   <span class="k">const</span> <span class="n">ShapeKind</span> <span class="n">Kind</span><span class="p">;</span>
+ <span class="nl">public:</span>
+   <span class="n">ShapeKind</span> <span class="n">getKind</span><span class="p">()</span> <span class="k">const</span> <span class="p">{</span> <span class="k">return</span> <span class="n">Kind</span><span class="p">;</span> <span class="p">}</span>
+
+   <span class="n">Shape</span><span class="p">(</span><span class="n">ShapeKind</span> <span class="n">K</span><span class="p">)</span> <span class="o">:</span> <span class="n">Kind</span><span class="p">(</span><span class="n">K</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="k">virtual</span> <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
+ <span class="p">};</span>
+
+ <span class="k">class</span> <span class="nc">Square</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+   <span class="kt">double</span> <span class="n">SideLength</span><span class="p">;</span>
+ <span class="nl">public:</span>
+   <span class="n">Square</span><span class="p">(</span><span class="kt">double</span> <span class="n">S</span><span class="p">)</span> <span class="o">:</span> <span class="n">Shape</span><span class="p">(</span><span class="n">SK_Square</span><span class="p">),</span> <span class="n">SideLength</span><span class="p">(</span><span class="n">S</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+<span class="o">+</span>
+<span class="o">+</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">+</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">==</span> <span class="n">SK_Square</span><span class="p">;</span>
+<span class="o">+</span>  <span class="p">}</span>
+ <span class="p">};</span>
+
+ <span class="k">class</span> <span class="nc">Circle</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Shape</span> <span class="p">{</span>
+   <span class="kt">double</span> <span class="n">Radius</span><span class="p">;</span>
+ <span class="nl">public:</span>
+   <span class="n">Circle</span><span class="p">(</span><span class="kt">double</span> <span class="n">R</span><span class="p">)</span> <span class="o">:</span> <span class="n">Shape</span><span class="p">(</span><span class="n">SK_Circle</span><span class="p">),</span> <span class="n">Radius</span><span class="p">(</span><span class="n">R</span><span class="p">)</span> <span class="p">{}</span>
+   <span class="kt">double</span> <span class="n">computeArea</span><span class="p">()</span> <span class="n">override</span><span class="p">;</span>
+<span class="o">+</span>
+<span class="o">+</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">+</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">==</span> <span class="n">SK_Circle</span><span class="p">;</span>
+<span class="o">+</span>  <span class="p">}</span>
+ <span class="p">};</span>
+</pre></div>
+</div>
+<p>The job of <tt class="docutils literal"><span class="pre">classof</span></tt> is to dynamically determine whether an object of
+a base class is in fact of a particular derived class.  In order to
+downcast a type <tt class="docutils literal"><span class="pre">Base</span></tt> to a type <tt class="docutils literal"><span class="pre">Derived</span></tt>, there needs to be a
+<tt class="docutils literal"><span class="pre">classof</span></tt> in <tt class="docutils literal"><span class="pre">Derived</span></tt> which will accept an object of type <tt class="docutils literal"><span class="pre">Base</span></tt>.</p>
+<p>To be concrete, consider the following code:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="n">Shape</span> <span class="o">*</span><span class="n">S</span> <span class="o">=</span> <span class="p">...;</span>
+<span class="k">if</span> <span class="p">(</span><span class="n">isa</span><span class="o"><</span><span class="n">Circle</span><span class="o">></span><span class="p">(</span><span class="n">S</span><span class="p">))</span> <span class="p">{</span>
+  <span class="cm">/* do something ... */</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>The code of the <tt class="docutils literal"><span class="pre">isa<></span></tt> test in this code will eventually boil
+down—after template instantiation and some other machinery—to a
+check roughly like <tt class="docutils literal"><span class="pre">Circle::classof(S)</span></tt>. For more information, see
+<a class="reference internal" href="#classof-contract"><em>The Contract of classof</em></a>.</p>
+<p>The argument to <tt class="docutils literal"><span class="pre">classof</span></tt> should always be an <em>ancestor</em> class because
+the implementation has logic to allow and optimize away
+upcasts/up-<tt class="docutils literal"><span class="pre">isa<></span></tt>‘s automatically. It is as though every class
+<tt class="docutils literal"><span class="pre">Foo</span></tt> automatically has a <tt class="docutils literal"><span class="pre">classof</span></tt> like:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Foo</span> <span class="p">{</span>
+  <span class="p">[...]</span>
+  <span class="k">template</span> <span class="o"><</span><span class="k">class</span> <span class="nc">T</span><span class="o">></span>
+  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">T</span> <span class="o">*</span><span class="p">,</span>
+                      <span class="o">::</span><span class="n">std</span><span class="o">::</span><span class="n">enable_if</span><span class="o"><</span>
+                        <span class="o">::</span><span class="n">std</span><span class="o">::</span><span class="n">is_base_of</span><span class="o"><</span><span class="n">Foo</span><span class="p">,</span> <span class="n">T</span><span class="o">>::</span><span class="n">value</span>
+                      <span class="o">>::</span><span class="n">type</span><span class="o">*</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="nb">true</span><span class="p">;</span> <span class="p">}</span>
+  <span class="p">[...]</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>Note that this is the reason that we did not need to introduce a
+<tt class="docutils literal"><span class="pre">classof</span></tt> into <tt class="docutils literal"><span class="pre">Shape</span></tt>: all relevant classes derive from <tt class="docutils literal"><span class="pre">Shape</span></tt>,
+and <tt class="docutils literal"><span class="pre">Shape</span></tt> itself is abstract (has no entry in the <tt class="docutils literal"><span class="pre">Kind</span></tt> enum),
+so this notional inferred <tt class="docutils literal"><span class="pre">classof</span></tt> is all we need. See <a class="reference internal" href="#concrete-bases-and-deeper-hierarchies">Concrete
+Bases and Deeper Hierarchies</a> for more information about how to extend
+this example to more general hierarchies.</p>
+</li>
+</ol>
+<p>Although for this small example setting up LLVM-style RTTI seems like a lot
+of “boilerplate”, if your classes are doing anything interesting then this
+will end up being a tiny fraction of the code.</p>
+</div>
+<div class="section" id="concrete-bases-and-deeper-hierarchies">
+<h2><a class="toc-backref" href="#id4">Concrete Bases and Deeper Hierarchies</a><a class="headerlink" href="#concrete-bases-and-deeper-hierarchies" title="Permalink to this headline">¶</a></h2>
+<p>For concrete bases (i.e. non-abstract interior nodes of the inheritance
+tree), the <tt class="docutils literal"><span class="pre">Kind</span></tt> check inside <tt class="docutils literal"><span class="pre">classof</span></tt> needs to be a bit more
+complicated. The situation differs from the example above in that</p>
+<ul class="simple">
+<li>Since the class is concrete, it must itself have an entry in the <tt class="docutils literal"><span class="pre">Kind</span></tt>
+enum because it is possible to have objects with this class as a dynamic
+type.</li>
+<li>Since the class has children, the check inside <tt class="docutils literal"><span class="pre">classof</span></tt> must take them
+into account.</li>
+</ul>
+<p>Say that <tt class="docutils literal"><span class="pre">SpecialSquare</span></tt> and <tt class="docutils literal"><span class="pre">OtherSpecialSquare</span></tt> derive
+from <tt class="docutils literal"><span class="pre">Square</span></tt>, and so <tt class="docutils literal"><span class="pre">ShapeKind</span></tt> becomes:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+   <span class="n">SK_Square</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_SpecialSquare</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_OtherSpecialSquare</span><span class="p">,</span>
+   <span class="n">SK_Circle</span>
+ <span class="p">}</span>
+</pre></div>
+</div>
+<p>Then in <tt class="docutils literal"><span class="pre">Square</span></tt>, we would need to modify the <tt class="docutils literal"><span class="pre">classof</span></tt> like so:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="o">-</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">-</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">==</span> <span class="n">SK_Square</span><span class="p">;</span>
+<span class="o">-</span>  <span class="p">}</span>
+<span class="o">+</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">+</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">>=</span> <span class="n">SK_Square</span> <span class="o">&&</span>
+<span class="o">+</span>           <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o"><=</span> <span class="n">SK_OtherSpecialSquare</span><span class="p">;</span>
+<span class="o">+</span>  <span class="p">}</span>
+</pre></div>
+</div>
+<p>The reason that we need to test a range like this instead of just equality
+is that both <tt class="docutils literal"><span class="pre">SpecialSquare</span></tt> and <tt class="docutils literal"><span class="pre">OtherSpecialSquare</span></tt> “is-a”
+<tt class="docutils literal"><span class="pre">Square</span></tt>, and so <tt class="docutils literal"><span class="pre">classof</span></tt> needs to return <tt class="docutils literal"><span class="pre">true</span></tt> for them.</p>
+<p>This approach can be made to scale to arbitrarily deep hierarchies. The
+trick is that you arrange the enum values so that they correspond to a
+preorder traversal of the class hierarchy tree. With that arrangement, all
+subclass tests can be done with two comparisons as shown above. If you just
+list the class hierarchy like a list of bullet points, you’ll get the
+ordering right:</p>
+<div class="highlight-python"><div class="highlight"><pre>| Shape
+  | Square
+    | SpecialSquare
+    | OtherSpecialSquare
+  | Circle
+</pre></div>
+</div>
+<div class="section" id="a-bug-to-be-aware-of">
+<h3><a class="toc-backref" href="#id5">A Bug to be Aware Of</a><a class="headerlink" href="#a-bug-to-be-aware-of" title="Permalink to this headline">¶</a></h3>
+<p>The example just given opens the door to bugs where the <tt class="docutils literal"><span class="pre">classof</span></tt>s are
+not updated to match the <tt class="docutils literal"><span class="pre">Kind</span></tt> enum when adding (or removing) classes to
+(from) the hierarchy.</p>
+<p>Continuing the example above, suppose we add a <tt class="docutils literal"><span class="pre">SomewhatSpecialSquare</span></tt> as
+a subclass of <tt class="docutils literal"><span class="pre">Square</span></tt>, and update the <tt class="docutils literal"><span class="pre">ShapeKind</span></tt> enum like so:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+   <span class="n">SK_Square</span><span class="p">,</span>
+   <span class="n">SK_SpecialSquare</span><span class="p">,</span>
+   <span class="n">SK_OtherSpecialSquare</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_SomewhatSpecialSquare</span><span class="p">,</span>
+   <span class="n">SK_Circle</span>
+ <span class="p">}</span>
+</pre></div>
+</div>
+<p>Now, suppose that we forget to update <tt class="docutils literal"><span class="pre">Square::classof()</span></tt>, so it still
+looks like:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="k">static</span> <span class="kt">bool</span> <span class="nf">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+  <span class="c1">// BUG: Returns false when S->getKind() == SK_SomewhatSpecialSquare,</span>
+  <span class="c1">// even though SomewhatSpecialSquare "is a" Square.</span>
+  <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">>=</span> <span class="n">SK_Square</span> <span class="o">&&</span>
+         <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o"><=</span> <span class="n">SK_OtherSpecialSquare</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>As the comment indicates, this code contains a bug. A straightforward and
+non-clever way to avoid this is to introduce an explicit <tt class="docutils literal"><span class="pre">SK_LastSquare</span></tt>
+entry in the enum when adding the first subclass(es). For example, we could
+rewrite the example at the beginning of <a class="reference internal" href="#concrete-bases-and-deeper-hierarchies">Concrete Bases and Deeper
+Hierarchies</a> as:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+   <span class="n">SK_Square</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_SpecialSquare</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_OtherSpecialSquare</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_LastSquare</span><span class="p">,</span>
+   <span class="n">SK_Circle</span>
+ <span class="p">}</span>
+<span class="p">...</span>
+<span class="c1">// Square::classof()</span>
+<span class="o">-</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">-</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">==</span> <span class="n">SK_Square</span><span class="p">;</span>
+<span class="o">-</span>  <span class="p">}</span>
+<span class="o">+</span>  <span class="k">static</span> <span class="kt">bool</span> <span class="n">classof</span><span class="p">(</span><span class="k">const</span> <span class="n">Shape</span> <span class="o">*</span><span class="n">S</span><span class="p">)</span> <span class="p">{</span>
+<span class="o">+</span>    <span class="k">return</span> <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o">>=</span> <span class="n">SK_Square</span> <span class="o">&&</span>
+<span class="o">+</span>           <span class="n">S</span><span class="o">-></span><span class="n">getKind</span><span class="p">()</span> <span class="o"><=</span> <span class="n">SK_LastSquare</span><span class="p">;</span>
+<span class="o">+</span>  <span class="p">}</span>
+</pre></div>
+</div>
+<p>Then, adding new subclasses is easy:</p>
+<div class="highlight-c++"><div class="highlight"><pre> <span class="k">enum</span> <span class="n">ShapeKind</span> <span class="p">{</span>
+   <span class="n">SK_Square</span><span class="p">,</span>
+   <span class="n">SK_SpecialSquare</span><span class="p">,</span>
+   <span class="n">SK_OtherSpecialSquare</span><span class="p">,</span>
+<span class="o">+</span>  <span class="n">SK_SomewhatSpecialSquare</span><span class="p">,</span>
+   <span class="n">SK_LastSquare</span><span class="p">,</span>
+   <span class="n">SK_Circle</span>
+ <span class="p">}</span>
+</pre></div>
+</div>
+<p>Notice that <tt class="docutils literal"><span class="pre">Square::classof</span></tt> does not need to be changed.</p>
+</div>
+<div class="section" id="the-contract-of-classof">
+<span id="classof-contract"></span><h3><a class="toc-backref" href="#id6">The Contract of <tt class="docutils literal"><span class="pre">classof</span></tt></a><a class="headerlink" href="#the-contract-of-classof" title="Permalink to this headline">¶</a></h3>
+<p>To be more precise, let <tt class="docutils literal"><span class="pre">classof</span></tt> be inside a class <tt class="docutils literal"><span class="pre">C</span></tt>.  Then the
+contract for <tt class="docutils literal"><span class="pre">classof</span></tt> is “return <tt class="docutils literal"><span class="pre">true</span></tt> if the dynamic type of the
+argument is-a <tt class="docutils literal"><span class="pre">C</span></tt>”.  As long as your implementation fulfills this
+contract, you can tweak and optimize it as much as you want.</p>
+<p>For example, LLVM-style RTTI can work fine in the presence of
+multiple-inheritance by defining an appropriate <tt class="docutils literal"><span class="pre">classof</span></tt>.
+An example of this in practice is
+<a class="reference external" href="http://clang.llvm.org/doxygen/classclang_1_1Decl.html">Decl</a> vs.
+<a class="reference external" href="http://clang.llvm.org/doxygen/classclang_1_1DeclContext.html">DeclContext</a>
+inside Clang.
+The <tt class="docutils literal"><span class="pre">Decl</span></tt> hierarchy is done very similarly to the example setup
+demonstrated in this tutorial.
+The key part is how to then incorporate <tt class="docutils literal"><span class="pre">DeclContext</span></tt>: all that is needed
+is in <tt class="docutils literal"><span class="pre">bool</span> <span class="pre">DeclContext::classof(const</span> <span class="pre">Decl</span> <span class="pre">*)</span></tt>, which asks the question
+“Given a <tt class="docutils literal"><span class="pre">Decl</span></tt>, how can I determine if it is-a <tt class="docutils literal"><span class="pre">DeclContext</span></tt>?”.
+It answers this with a simple switch over the set of <tt class="docutils literal"><span class="pre">Decl</span></tt> “kinds”, and
+returning true for ones that are known to be <tt class="docutils literal"><span class="pre">DeclContext</span></tt>‘s.</p>
+</div>
+</div>
+<div class="section" id="rules-of-thumb">
+<h2><a class="toc-backref" href="#id7">Rules of Thumb</a><a class="headerlink" href="#rules-of-thumb" title="Permalink to this headline">¶</a></h2>
+<ol class="arabic simple">
+<li>The <tt class="docutils literal"><span class="pre">Kind</span></tt> enum should have one entry per concrete class, ordered
+according to a preorder traversal of the inheritance tree.</li>
+<li>The argument to <tt class="docutils literal"><span class="pre">classof</span></tt> should be a <tt class="docutils literal"><span class="pre">const</span> <span class="pre">Base</span> <span class="pre">*</span></tt>, where <tt class="docutils literal"><span class="pre">Base</span></tt>
+is some ancestor in the inheritance hierarchy. The argument should
+<em>never</em> be a derived class or the class itself: the template machinery
+for <tt class="docutils literal"><span class="pre">isa<></span></tt> already handles this case and optimizes it.</li>
+<li>For each class in the hierarchy that has no children, implement a
+<tt class="docutils literal"><span class="pre">classof</span></tt> that checks only against its <tt class="docutils literal"><span class="pre">Kind</span></tt>.</li>
+<li>For each class in the hierarchy that has children, implement a
+<tt class="docutils literal"><span class="pre">classof</span></tt> that checks a range of the first child’s <tt class="docutils literal"><span class="pre">Kind</span></tt> and the
+last child’s <tt class="docutils literal"><span class="pre">Kind</span></tt>.</li>
+</ol>
+</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="ProgrammersManual.html" title="LLVM Programmer’s Manual"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="ExtendingLLVM.html" title="Extending LLVM: Adding instructions, intrinsics, types, etc."
+             >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-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/HowToSubmitABug.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/HowToSubmitABug.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/HowToSubmitABug.html (added)
+++ www-releases/trunk/3.9.1/docs/HowToSubmitABug.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,279 @@
+
+<!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 submit an LLVM bug report — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="Sphinx Quickstart Template" href="SphinxQuickstartTemplate.html" />
+    <link rel="prev" title="yaml2obj" href="yaml2obj.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="SphinxQuickstartTemplate.html" title="Sphinx Quickstart Template"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="yaml2obj.html" title="yaml2obj"
+             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-submit-an-llvm-bug-report">
+<h1>How to submit an LLVM bug report<a class="headerlink" href="#how-to-submit-an-llvm-bug-report" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction-got-bugs">
+<h2>Introduction - Got bugs?<a class="headerlink" href="#introduction-got-bugs" title="Permalink to this headline">¶</a></h2>
+<p>If you’re working with LLVM and run into a bug, we definitely want to know
+about it.  This document describes what you can do to increase the odds of
+getting it fixed quickly.</p>
+<p>Basically you have to do two things at a minimum.  First, decide whether
+the bug <a class="reference internal" href="#crashes-the-compiler">crashes the compiler</a> (or an LLVM pass), or if the
+compiler is <a class="reference internal" href="#miscompiling">miscompiling</a> the program (i.e., the
+compiler successfully produces an executable, but it doesn’t run right).
+Based on what type of bug it is, follow the instructions in the linked
+section to narrow down the bug so that the person who fixes it will be able
+to find the problem more easily.</p>
+<p>Once you have a reduced test-case, go to <a class="reference external" href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking System</a> and fill out the form with the
+necessary details (note that you don’t need to pick a category, just use
+the “new-bugs” category if you’re not sure).  The bug description should
+contain the following information:</p>
+<ul class="simple">
+<li>All information necessary to reproduce the problem.</li>
+<li>The reduced test-case that triggers the bug.</li>
+<li>The location where you obtained LLVM (if not from our Subversion
+repository).</li>
+</ul>
+<p>Thanks for helping us make LLVM better!</p>
+</div>
+<div class="section" id="crashing-bugs">
+<span id="crashes-the-compiler"></span><h2>Crashing Bugs<a class="headerlink" href="#crashing-bugs" title="Permalink to this headline">¶</a></h2>
+<p>More often than not, bugs in the compiler cause it to crash—often due to
+an assertion failure of some sort. The most important piece of the puzzle
+is to figure out if it is crashing in the GCC front-end or if it is one of
+the LLVM libraries (e.g. the optimizer or code generator) that has
+problems.</p>
+<p>To figure out which component is crashing (the front-end, optimizer or code
+generator), run the <tt class="docutils literal"><span class="pre">clang</span></tt> command line as you were when the crash
+occurred, but with the following extra command line options:</p>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">-O0</span> <span class="pre">-emit-llvm</span></tt>: If <tt class="docutils literal"><span class="pre">clang</span></tt> still crashes when passed these
+options (which disable the optimizer and code generator), then the crash
+is in the front-end.  Jump ahead to the section on <a class="reference internal" href="#front-end"><em>front-end bugs</em></a>.</li>
+<li><tt class="docutils literal"><span class="pre">-emit-llvm</span></tt>: If <tt class="docutils literal"><span class="pre">clang</span></tt> crashes with this option (which disables
+the code generator), you found an optimizer bug.  Jump ahead to
+<a class="reference internal" href="#compile-time-optimization-bugs">compile-time optimization bugs</a>.</li>
+<li>Otherwise, you have a code generator crash. Jump ahead to <a class="reference internal" href="#code-generator-bugs">code
+generator bugs</a>.</li>
+</ul>
+<div class="section" id="front-end-bugs">
+<span id="front-end"></span><span id="front-end-bug"></span><h3>Front-end bugs<a class="headerlink" href="#front-end-bugs" title="Permalink to this headline">¶</a></h3>
+<p>If the problem is in the front-end, you should re-run the same <tt class="docutils literal"><span class="pre">clang</span></tt>
+command that resulted in the crash, but add the <tt class="docutils literal"><span class="pre">-save-temps</span></tt> option.
+The compiler will crash again, but it will leave behind a <tt class="docutils literal"><span class="pre">foo.i</span></tt> file
+(containing preprocessed C source code) and possibly <tt class="docutils literal"><span class="pre">foo.s</span></tt> for each
+compiled <tt class="docutils literal"><span class="pre">foo.c</span></tt> file. Send us the <tt class="docutils literal"><span class="pre">foo.i</span></tt> file, along with the options
+you passed to <tt class="docutils literal"><span class="pre">clang</span></tt>, and a brief description of the error it caused.</p>
+<p>The <a class="reference external" href="http://delta.tigris.org/">delta</a> tool helps to reduce the
+preprocessed file down to the smallest amount of code that still replicates
+the problem. You’re encouraged to use delta to reduce the code to make the
+developers’ lives easier. <a class="reference external" href="http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction">This website</a> has instructions
+on the best way to use delta.</p>
+</div>
+<div class="section" id="compile-time-optimization-bugs">
+<span id="id1"></span><h3>Compile-time optimization bugs<a class="headerlink" href="#compile-time-optimization-bugs" title="Permalink to this headline">¶</a></h3>
+<p>If you find that a bug crashes in the optimizer, compile your test-case to a
+<tt class="docutils literal"><span class="pre">.bc</span></tt> file by passing “<tt class="docutils literal"><span class="pre">-emit-llvm</span> <span class="pre">-O0</span> <span class="pre">-c</span> <span class="pre">-o</span> <span class="pre">foo.bc</span></tt>”.
+Then run:</p>
+<div class="highlight-bash"><div class="highlight"><pre>opt -O3 -debug-pass<span class="o">=</span>Arguments foo.bc -disable-output
+</pre></div>
+</div>
+<p>This command should do two things: it should print out a list of passes, and
+then it should crash in the same way as clang.  If it doesn’t crash, please
+follow the instructions for a <a class="reference internal" href="#front-end-bug">front-end bug</a>.</p>
+<p>If this does crash, then you should be able to debug this with the following
+bugpoint command:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint foo.bc <list of passes printed by opt>
+</pre></div>
+</div>
+<p>Please run this, then file a bug with the instructions and reduced .bc
+files that bugpoint emits.  If something goes wrong with bugpoint, please
+submit the “foo.bc” file and the list of passes printed by <tt class="docutils literal"><span class="pre">opt</span></tt>.</p>
+</div>
+<div class="section" id="code-generator-bugs">
+<span id="id2"></span><h3>Code generator bugs<a class="headerlink" href="#code-generator-bugs" title="Permalink to this headline">¶</a></h3>
+<p>If you find a bug that crashes clang in the code generator, compile your
+source file to a .bc file by passing “<tt class="docutils literal"><span class="pre">-emit-llvm</span> <span class="pre">-c</span> <span class="pre">-o</span> <span class="pre">foo.bc</span></tt>” to
+clang (in addition to the options you already pass).  Once your have
+foo.bc, one of the following commands should fail:</p>
+<ol class="arabic simple">
+<li><tt class="docutils literal"><span class="pre">llc</span> <span class="pre">foo.bc</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">llc</span> <span class="pre">foo.bc</span> <span class="pre">-relocation-model=pic</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">llc</span> <span class="pre">foo.bc</span> <span class="pre">-relocation-model=static</span></tt></li>
+</ol>
+<p>If none of these crash, please follow the instructions for a <a class="reference internal" href="#front-end-bug">front-end
+bug</a>.  If one of these do crash, you should be able to reduce this with
+one of the following bugpoint command lines (use the one corresponding to
+the command above that failed):</p>
+<ol class="arabic simple">
+<li><tt class="docutils literal"><span class="pre">bugpoint</span> <span class="pre">-run-llc</span> <span class="pre">foo.bc</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">bugpoint</span> <span class="pre">-run-llc</span> <span class="pre">foo.bc</span> <span class="pre">--tool-args</span> <span class="pre">-relocation-model=pic</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">bugpoint</span> <span class="pre">-run-llc</span> <span class="pre">foo.bc</span> <span class="pre">--tool-args</span> <span class="pre">-relocation-model=static</span></tt></li>
+</ol>
+<p>Please run this, then file a bug with the instructions and reduced .bc file
+that bugpoint emits.  If something goes wrong with bugpoint, please submit
+the “foo.bc” file and the option that llc crashes with.</p>
+</div>
+</div>
+<div class="section" id="miscompilations">
+<span id="miscompiling"></span><h2>Miscompilations<a class="headerlink" href="#miscompilations" title="Permalink to this headline">¶</a></h2>
+<p>If clang successfully produces an executable, but that executable
+doesn’t run right, this is either a bug in the code or a bug in the
+compiler.  The first thing to check is to make sure it is not using
+undefined behavior (e.g. reading a variable before it is defined). In
+particular, check to see if the program <a class="reference external" href="http://valgrind.org/">valgrind</a>‘s clean, passes purify, or some other memory
+checker tool. Many of the “LLVM bugs” that we have chased down ended up
+being bugs in the program being compiled, not LLVM.</p>
+<p>Once you determine that the program itself is not buggy, you should choose
+which code generator you wish to compile the program with (e.g. LLC or the JIT)
+and optionally a series of LLVM passes to run.  For example:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint -run-llc <span class="o">[</span>... optzn passes ...<span class="o">]</span> file-to-test.bc --args -- <span class="o">[</span>program arguments<span class="o">]</span>
+</pre></div>
+</div>
+<p>bugpoint will try to narrow down your list of passes to the one pass that
+causes an error, and simplify the bitcode file as much as it can to assist
+you. It will print a message letting you know how to reproduce the
+resulting error.</p>
+</div>
+<div class="section" id="incorrect-code-generation">
+<h2>Incorrect code generation<a class="headerlink" href="#incorrect-code-generation" title="Permalink to this headline">¶</a></h2>
+<p>Similarly to debugging incorrect compilation by mis-behaving passes, you
+can debug incorrect code generation by either LLC or the JIT, using
+<tt class="docutils literal"><span class="pre">bugpoint</span></tt>. The process <tt class="docutils literal"><span class="pre">bugpoint</span></tt> follows in this case is to try to
+narrow the code down to a function that is miscompiled by one or the other
+method, but since for correctness, the entire program must be run,
+<tt class="docutils literal"><span class="pre">bugpoint</span></tt> will compile the code it deems to not be affected with the C
+Backend, and then link in the shared object it generates.</p>
+<p>To debug the JIT:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint -run-jit -output<span class="o">=[</span>correct output file<span class="o">]</span> <span class="o">[</span>bitcode file<span class="o">]</span>  <span class="se">\</span>
+         --tool-args -- <span class="o">[</span>arguments to pass to lli<span class="o">]</span>              <span class="se">\</span>
+         --args -- <span class="o">[</span>program arguments<span class="o">]</span>
+</pre></div>
+</div>
+<p>Similarly, to debug the LLC, one would run:</p>
+<div class="highlight-bash"><div class="highlight"><pre>bugpoint -run-llc -output<span class="o">=[</span>correct output file<span class="o">]</span> <span class="o">[</span>bitcode file<span class="o">]</span>  <span class="se">\</span>
+         --tool-args -- <span class="o">[</span>arguments to pass to llc<span class="o">]</span>              <span class="se">\</span>
+         --args -- <span class="o">[</span>program arguments<span class="o">]</span>
+</pre></div>
+</div>
+<p><strong>Special note:</strong> if you are debugging MultiSource or SPEC tests that
+already exist in the <tt class="docutils literal"><span class="pre">llvm/test</span></tt> hierarchy, there is an easier way to
+debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which
+will pass the program options specified in the Makefiles:</p>
+<div class="highlight-bash"><div class="highlight"><pre><span class="nb">cd </span>llvm/test/../../program
+make bugpoint-jit
+</pre></div>
+</div>
+<p>At the end of a successful <tt class="docutils literal"><span class="pre">bugpoint</span></tt> run, you will be presented
+with two bitcode files: a <em>safe</em> file which can be compiled with the C
+backend and the <em>test</em> file which either LLC or the JIT
+mis-codegenerates, and thus causes the error.</p>
+<p>To reproduce the error that <tt class="docutils literal"><span class="pre">bugpoint</span></tt> found, it is sufficient to do
+the following:</p>
+<ol class="arabic">
+<li><p class="first">Regenerate the shared object from the safe bitcode file:</p>
+<div class="highlight-bash"><div class="highlight"><pre>llc -march<span class="o">=</span>c safe.bc -o safe.c
+gcc -shared safe.c -o safe.so
+</pre></div>
+</div>
+</li>
+<li><p class="first">If debugging LLC, compile test bitcode native and link with the shared
+object:</p>
+<div class="highlight-bash"><div class="highlight"><pre>llc test.bc -o test.s
+gcc test.s safe.so -o test.llc
+./test.llc <span class="o">[</span>program options<span class="o">]</span>
+</pre></div>
+</div>
+</li>
+<li><p class="first">If debugging the JIT, load the shared object and supply the test
+bitcode:</p>
+<div class="highlight-bash"><div class="highlight"><pre>lli -load<span class="o">=</span>safe.so test.bc <span class="o">[</span>program options<span class="o">]</span>
+</pre></div>
+</div>
+</li>
+</ol>
+</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="SphinxQuickstartTemplate.html" title="Sphinx Quickstart Template"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="yaml2obj.html" title="yaml2obj"
+             >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-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/HowToUseAttributes.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/HowToUseAttributes.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/HowToUseAttributes.html (added)
+++ www-releases/trunk/3.9.1/docs/HowToUseAttributes.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,169 @@
+
+<!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 Use Attributes — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="User Guide for NVPTX Back-end" href="NVPTXUsage.html" />
+    <link rel="prev" title="Writing an LLVM Pass" href="WritingAnLLVMPass.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="NVPTXUsage.html" title="User Guide for NVPTX Back-end"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="WritingAnLLVMPass.html" title="Writing an LLVM Pass"
+             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-use-attributes">
+<h1>How To Use Attributes<a class="headerlink" href="#how-to-use-attributes" 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="#attribute" id="id2"><tt class="docutils literal"><span class="pre">Attribute</span></tt></a></li>
+<li><a class="reference internal" href="#attributeset" id="id3"><tt class="docutils literal"><span class="pre">AttributeSet</span></tt></a></li>
+<li><a class="reference internal" href="#attrbuilder" id="id4"><tt class="docutils literal"><span class="pre">AttrBuilder</span></tt></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>Attributes in LLVM have changed in some fundamental ways.  It was necessary to
+do this to support expanding the attributes to encompass more than a handful of
+attributes — e.g. command line options.  The old way of handling attributes
+consisted of representing them as a bit mask of values.  This bit mask was
+stored in a “list” structure that was reference counted.  The advantage of this
+was that attributes could be manipulated with ‘or’s and ‘and’s.  The
+disadvantage of this was that there was limited room for expansion, and
+virtually no support for attribute-value pairs other than alignment.</p>
+<p>In the new scheme, an <tt class="docutils literal"><span class="pre">Attribute</span></tt> object represents a single attribute that’s
+uniqued.  You use the <tt class="docutils literal"><span class="pre">Attribute::get</span></tt> methods to create a new <tt class="docutils literal"><span class="pre">Attribute</span></tt>
+object.  An attribute can be a single “enum” value (the enum being the
+<tt class="docutils literal"><span class="pre">Attribute::AttrKind</span></tt> enum), a string representing a target-dependent
+attribute, or an attribute-value pair.  Some examples:</p>
+<ul class="simple">
+<li>Target-independent: <tt class="docutils literal"><span class="pre">noinline</span></tt>, <tt class="docutils literal"><span class="pre">zext</span></tt></li>
+<li>Target-dependent: <tt class="docutils literal"><span class="pre">"no-sse"</span></tt>, <tt class="docutils literal"><span class="pre">"thumb2"</span></tt></li>
+<li>Attribute-value pair: <tt class="docutils literal"><span class="pre">"cpu"</span> <span class="pre">=</span> <span class="pre">"cortex-a8"</span></tt>, <tt class="docutils literal"><span class="pre">align</span> <span class="pre">=</span> <span class="pre">4</span></tt></li>
+</ul>
+<p>Note: for an attribute value pair, we expect a target-dependent attribute to
+have a string for the value.</p>
+</div>
+<div class="section" id="attribute">
+<h2><a class="toc-backref" href="#id2"><tt class="docutils literal"><span class="pre">Attribute</span></tt></a><a class="headerlink" href="#attribute" title="Permalink to this headline">¶</a></h2>
+<p>An <tt class="docutils literal"><span class="pre">Attribute</span></tt> object is designed to be passed around by value.</p>
+<p>Because attributes are no longer represented as a bit mask, you will need to
+convert any code which does treat them as a bit mask to use the new query
+methods on the Attribute class.</p>
+</div>
+<div class="section" id="attributeset">
+<h2><a class="toc-backref" href="#id3"><tt class="docutils literal"><span class="pre">AttributeSet</span></tt></a><a class="headerlink" href="#attributeset" title="Permalink to this headline">¶</a></h2>
+<p>The <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> class replaces the old <tt class="docutils literal"><span class="pre">AttributeList</span></tt> class.  The
+<tt class="docutils literal"><span class="pre">AttributeSet</span></tt> stores a collection of Attribute objects for each kind of
+object that may have an attribute associated with it: the function as a
+whole, the return type, or the function’s parameters.  A function’s attributes
+are at index <tt class="docutils literal"><span class="pre">AttributeSet::FunctionIndex</span></tt>; the return type’s attributes are
+at index <tt class="docutils literal"><span class="pre">AttributeSet::ReturnIndex</span></tt>; and the function’s parameters’
+attributes are at indices 1, ..., n (where ‘n’ is the number of parameters).
+Most methods on the <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> class take an index parameter.</p>
+<p>An <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> is also a uniqued and immutable object.  You create an
+<tt class="docutils literal"><span class="pre">AttributeSet</span></tt> through the <tt class="docutils literal"><span class="pre">AttributeSet::get</span></tt> methods.  You can add and
+remove attributes, which result in the creation of a new <tt class="docutils literal"><span class="pre">AttributeSet</span></tt>.</p>
+<p>An <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> object is designed to be passed around by value.</p>
+<p>Note: It is advised that you do <em>not</em> use the <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> “introspection”
+methods (e.g. <tt class="docutils literal"><span class="pre">Raw</span></tt>, <tt class="docutils literal"><span class="pre">getRawPointer</span></tt>, etc.).  These methods break
+encapsulation, and may be removed in a future release (i.e. LLVM 4.0).</p>
+</div>
+<div class="section" id="attrbuilder">
+<h2><a class="toc-backref" href="#id4"><tt class="docutils literal"><span class="pre">AttrBuilder</span></tt></a><a class="headerlink" href="#attrbuilder" title="Permalink to this headline">¶</a></h2>
+<p>Lastly, we have a “builder” class to help create the <tt class="docutils literal"><span class="pre">AttributeSet</span></tt> object
+without having to create several different intermediate uniqued
+<tt class="docutils literal"><span class="pre">AttributeSet</span></tt> objects.  The <tt class="docutils literal"><span class="pre">AttrBuilder</span></tt> class allows you to add and
+remove attributes at will.  The attributes won’t be uniqued until you call the
+appropriate <tt class="docutils literal"><span class="pre">AttributeSet::get</span></tt> method.</p>
+<p>An <tt class="docutils literal"><span class="pre">AttrBuilder</span></tt> object is <em>not</em> designed to be passed around by value.  It
+should be passed by reference.</p>
+<p>Note: It is advised that you do <em>not</em> use the <tt class="docutils literal"><span class="pre">AttrBuilder::addRawValue()</span></tt>
+method or the <tt class="docutils literal"><span class="pre">AttrBuilder(uint64_t</span> <span class="pre">Val)</span></tt> constructor.  These are for
+backwards compatibility and may be removed in a future release (i.e. LLVM 4.0).</p>
+<p>And that’s basically it! A lot of functionality is hidden behind these classes,
+but the interfaces are pretty straight forward.</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="NVPTXUsage.html" title="User Guide for NVPTX Back-end"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="WritingAnLLVMPass.html" title="Writing an LLVM Pass"
+             >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-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/HowToUseInstrMappings.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/HowToUseInstrMappings.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/HowToUseInstrMappings.html (added)
+++ www-releases/trunk/3.9.1/docs/HowToUseInstrMappings.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,269 @@
+
+<!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 Use Instruction Mappings — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="up" title="Writing an LLVM Backend" href="WritingAnLLVMBackend.html" />
+    <link rel="next" title="Garbage Collection with LLVM" href="GarbageCollection.html" />
+    <link rel="prev" title="Writing an LLVM Backend" href="WritingAnLLVMBackend.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="GarbageCollection.html" title="Garbage Collection with LLVM"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="WritingAnLLVMBackend.html" title="Writing an LLVM Backend"
+             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="WritingAnLLVMBackend.html" accesskey="U">Writing an LLVM Backend</a> »</li> 
+      </ul>
+    </div>
+
+
+    <div class="document">
+      <div class="documentwrapper">
+          <div class="body">
+            
+  <div class="section" id="how-to-use-instruction-mappings">
+<h1>How To Use Instruction Mappings<a class="headerlink" href="#how-to-use-instruction-mappings" 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="#instrmapping-class-overview" id="id2"><tt class="docutils literal"><span class="pre">InstrMapping</span></tt> Class Overview</a><ul>
+<li><a class="reference internal" href="#sample-example" id="id3">Sample Example</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document contains information about adding instruction mapping support
+for a target. The motivation behind this feature comes from the need to switch
+between different instruction formats during various optimizations. One approach
+could be to use switch cases which list all the instructions along with formats
+they can transition to. However, it has large maintenance overhead
+because of the hardcoded instruction names. Also, whenever a new instruction is
+added in the .td files, all the relevant switch cases should be modified
+accordingly. Instead, the same functionality could be achieved with TableGen and
+some support from the .td files for a fraction of maintenance cost.</p>
+</div>
+<div class="section" id="instrmapping-class-overview">
+<h2><a class="toc-backref" href="#id2"><tt class="docutils literal"><span class="pre">InstrMapping</span></tt> Class Overview</a><a class="headerlink" href="#instrmapping-class-overview" title="Permalink to this headline">¶</a></h2>
+<p>TableGen uses relationship models to map instructions with each other. These
+models are described using <tt class="docutils literal"><span class="pre">InstrMapping</span></tt> class as a base. Each model sets
+various fields of the <tt class="docutils literal"><span class="pre">InstrMapping</span></tt> class such that they can uniquely
+describe all the instructions using that model. TableGen parses all the relation
+models and uses the information to construct relation tables which relate
+instructions with each other. These tables are emitted in the
+<tt class="docutils literal"><span class="pre">XXXInstrInfo.inc</span></tt> file along with the functions to query them. Following
+is the definition of <tt class="docutils literal"><span class="pre">InstrMapping</span></tt> class definied in Target.td file:</p>
+<div class="highlight-text"><div class="highlight"><pre>class InstrMapping {
+  // Used to reduce search space only to the instructions using this
+  // relation model.
+  string FilterClass;
+
+  // List of fields/attributes that should be same for all the instructions in
+  // a row of the relation table. Think of this as a set of properties shared
+  // by all the instructions related by this relationship.
+  list<string> RowFields = [];
+
+  // List of fields/attributes that are same for all the instructions
+  // in a column of the relation table.
+  list<string> ColFields = [];
+
+  // Values for the fields/attributes listed in 'ColFields' corresponding to
+  // the key instruction. This is the instruction that will be transformed
+  // using this relation model.
+  list<string> KeyCol = [];
+
+  // List of values for the fields/attributes listed in 'ColFields', one for
+  // each column in the relation table. These are the instructions a key
+  // instruction will be transformed into.
+  list<list<string> > ValueCols = [];
+}
+</pre></div>
+</div>
+<div class="section" id="sample-example">
+<h3><a class="toc-backref" href="#id3">Sample Example</a><a class="headerlink" href="#sample-example" title="Permalink to this headline">¶</a></h3>
+<p>Let’s say that we want to have a function
+<tt class="docutils literal"><span class="pre">int</span> <span class="pre">getPredOpcode(uint16_t</span> <span class="pre">Opcode,</span> <span class="pre">enum</span> <span class="pre">PredSense</span> <span class="pre">inPredSense)</span></tt> which
+takes a non-predicated instruction and returns its predicated true or false form
+depending on some input flag, <tt class="docutils literal"><span class="pre">inPredSense</span></tt>. The first step in the process is
+to define a relationship model that relates predicated instructions to their
+non-predicated form by assigning appropriate values to the <tt class="docutils literal"><span class="pre">InstrMapping</span></tt>
+fields. For this relationship, non-predicated instructions are treated as key
+instruction since they are the one used to query the interface function.</p>
+<div class="highlight-text"><div class="highlight"><pre>def getPredOpcode : InstrMapping {
+  // Choose a FilterClass that is used as a base class for all the
+  // instructions modeling this relationship. This is done to reduce the
+  // search space only to these set of instructions.
+  let FilterClass = "PredRel";
+
+  // Instructions with same values for all the fields in RowFields form a
+  // row in the resulting relation table.
+  // For example, if we want to relate 'ADD' (non-predicated) with 'Add_pt'
+  // (predicated true) and 'Add_pf' (predicated false), then all 3
+  // instructions need to have same value for BaseOpcode field. It can be any
+  // unique value (Ex: XYZ) and should not be shared with any other
+  // instruction not related to 'add'.
+  let RowFields = ["BaseOpcode"];
+
+  // List of attributes that can be used to define key and column instructions
+  // for a relation. Key instruction is passed as an argument
+  // to the function used for querying relation tables. Column instructions
+  // are the instructions they (key) can transform into.
+  //
+  // Here, we choose 'PredSense' as ColFields since this is the unique
+  // attribute of the key (non-predicated) and column (true/false)
+  // instructions involved in this relationship model.
+  let ColFields = ["PredSense"];
+
+  // The key column contains non-predicated instructions.
+  let KeyCol = ["none"];
+
+  // Two value columns - first column contains instructions with
+  // PredSense=true while second column has instructions with PredSense=false.
+  let ValueCols = [["true"], ["false"]];
+}
+</pre></div>
+</div>
+<p>TableGen uses the above relationship model to emit relation table that maps
+non-predicated instructions with their predicated forms. It also outputs the
+interface function
+<tt class="docutils literal"><span class="pre">int</span> <span class="pre">getPredOpcode(uint16_t</span> <span class="pre">Opcode,</span> <span class="pre">enum</span> <span class="pre">PredSense</span> <span class="pre">inPredSense)</span></tt> to query
+the table. Here, Function <tt class="docutils literal"><span class="pre">getPredOpcode</span></tt> takes two arguments, opcode of the
+current instruction and PredSense of the desired instruction, and returns
+predicated form of the instruction, if found in the relation table.
+In order for an instruction to be added into the relation table, it needs
+to include relevant information in its definition. For example, consider
+following to be the current definitions of ADD, ADD_pt (true) and ADD_pf (false)
+instructions:</p>
+<div class="highlight-text"><div class="highlight"><pre>def ADD : ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
+            "$dst = add($a, $b)",
+            [(set (i32 IntRegs:$dst), (add (i32 IntRegs:$a),
+                                           (i32 IntRegs:$b)))]>;
+
+def ADD_Pt : ALU32_rr<(outs IntRegs:$dst),
+                       (ins PredRegs:$p, IntRegs:$a, IntRegs:$b),
+            "if ($p) $dst = add($a, $b)",
+            []>;
+
+def ADD_Pf : ALU32_rr<(outs IntRegs:$dst),
+                       (ins PredRegs:$p, IntRegs:$a, IntRegs:$b),
+            "if (!$p) $dst = add($a, $b)",
+            []>;
+</pre></div>
+</div>
+<p>In this step, we modify these instructions to include the information
+required by the relationship model, <tt>getPredOpcode</tt>, so that they can
+be related.</p>
+<div class="highlight-text"><div class="highlight"><pre>def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
+            "$dst = add($a, $b)",
+            [(set (i32 IntRegs:$dst), (add (i32 IntRegs:$a),
+                                           (i32 IntRegs:$b)))]> {
+  let BaseOpcode = "ADD";
+  let PredSense = "none";
+}
+
+def ADD_Pt : PredRel, ALU32_rr<(outs IntRegs:$dst),
+                       (ins PredRegs:$p, IntRegs:$a, IntRegs:$b),
+            "if ($p) $dst = add($a, $b)",
+            []> {
+  let BaseOpcode = "ADD";
+  let PredSense = "true";
+}
+
+def ADD_Pf : PredRel, ALU32_rr<(outs IntRegs:$dst),
+                       (ins PredRegs:$p, IntRegs:$a, IntRegs:$b),
+            "if (!$p) $dst = add($a, $b)",
+            []> {
+  let BaseOpcode = "ADD";
+  let PredSense = "false";
+}
+</pre></div>
+</div>
+<p>Please note that all the above instructions use <tt class="docutils literal"><span class="pre">PredRel</span></tt> as a base class.
+This is extremely important since TableGen uses it as a filter for selecting
+instructions for <tt class="docutils literal"><span class="pre">getPredOpcode</span></tt> model. Any instruction not derived from
+<tt class="docutils literal"><span class="pre">PredRel</span></tt> is excluded from the analysis. <tt class="docutils literal"><span class="pre">BaseOpcode</span></tt> is another important
+field. Since it’s selected as a <tt class="docutils literal"><span class="pre">RowFields</span></tt> of the model, it is required
+to have the same value for all 3 instructions in order to be related. Next,
+<tt class="docutils literal"><span class="pre">PredSense</span></tt> is used to determine their column positions by comparing its value
+with <tt class="docutils literal"><span class="pre">KeyCol</span></tt> and <tt class="docutils literal"><span class="pre">ValueCols</span></tt>. If an instruction sets its <tt class="docutils literal"><span class="pre">PredSense</span></tt>
+value to something not used in the relation model, it will not be assigned
+a column in the relation table.</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="GarbageCollection.html" title="Garbage Collection with LLVM"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="WritingAnLLVMBackend.html" title="Writing an LLVM Backend"
+             >previous</a> |</li>
+  <li><a href="http://llvm.org/">LLVM Home</a> | </li>
+  <li><a href="index.html">Documentation</a>»</li>
+
+          <li><a href="WritingAnLLVMBackend.html" >Writing an LLVM Backend</a> »</li> 
+      </ul>
+    </div>
+    <div class="footer">
+        © Copyright 2003-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/InAlloca.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/InAlloca.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/InAlloca.html (added)
+++ www-releases/trunk/3.9.1/docs/InAlloca.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,240 @@
+
+<!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>Design and Usage of the InAlloca Attribute — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="Using ARM NEON instructions in big endian mode" href="BigEndianNEON.html" />
+    <link rel="prev" title="Stack maps and patch points in LLVM" href="StackMaps.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="BigEndianNEON.html" title="Using ARM NEON instructions in big endian mode"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="StackMaps.html" title="Stack maps and patch points 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="design-and-usage-of-the-inalloca-attribute">
+<h1>Design and Usage of the InAlloca Attribute<a class="headerlink" href="#design-and-usage-of-the-inalloca-attribute" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction">
+<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>The <a class="reference internal" href="LangRef.html#attr-inalloca"><em>inalloca</em></a> attribute is designed to allow
+taking the address of an aggregate argument that is being passed by
+value through memory.  Primarily, this feature is required for
+compatibility with the Microsoft C++ ABI.  Under that ABI, class
+instances that are passed by value are constructed directly into
+argument stack memory.  Prior to the addition of inalloca, calls in LLVM
+were indivisible instructions.  There was no way to perform intermediate
+work, such as object construction, between the first stack adjustment
+and the final control transfer.  With inalloca, all arguments passed in
+memory are modelled as a single alloca, which can be stored to prior to
+the call.  Unfortunately, this complicated feature comes with a large
+set of restrictions designed to bound the lifetime of the argument
+memory around the call.</p>
+<p>For now, it is recommended that frontends and optimizers avoid producing
+this construct, primarily because it forces the use of a base pointer.
+This feature may grow in the future to allow general mid-level
+optimization, but for now, it should be regarded as less efficient than
+passing by value with a copy.</p>
+</div>
+<div class="section" id="intended-usage">
+<h2>Intended Usage<a class="headerlink" href="#intended-usage" title="Permalink to this headline">¶</a></h2>
+<p>The example below is the intended LLVM IR lowering for some C++ code
+that passes two default-constructed <tt class="docutils literal"><span class="pre">Foo</span></tt> objects to <tt class="docutils literal"><span class="pre">g</span></tt> in the
+32-bit Microsoft C++ ABI.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Foo is non-trivial.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">;</span> <span class="n">Foo</span><span class="p">();</span> <span class="o">~</span><span class="n">Foo</span><span class="p">();</span> <span class="n">Foo</span><span class="p">(</span><span class="k">const</span> <span class="n">Foo</span> <span class="o">&</span><span class="p">);</span> <span class="p">};</span>
+<span class="kt">void</span> <span class="nf">g</span><span class="p">(</span><span class="n">Foo</span> <span class="n">a</span><span class="p">,</span> <span class="n">Foo</span> <span class="n">b</span><span class="p">);</span>
+<span class="kt">void</span> <span class="nf">f</span><span class="p">()</span> <span class="p">{</span>
+  <span class="n">g</span><span class="p">(</span><span class="n">Foo</span><span class="p">(),</span> <span class="n">Foo</span><span class="p">());</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<div class="highlight-text"><div class="highlight"><pre>%struct.Foo = type { i32, i32 }
+declare void @Foo_ctor(%struct.Foo* %this)
+declare void @Foo_dtor(%struct.Foo* %this)
+declare void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
+
+define void @f() {
+entry:
+  %base = call i8* @llvm.stacksave()
+  %memargs = alloca <{ %struct.Foo, %struct.Foo }>
+  %b = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 1
+  call void @Foo_ctor(%struct.Foo* %b)
+
+  ; If a's ctor throws, we must destruct b.
+  %a = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 0
+  invoke void @Foo_ctor(%struct.Foo* %a)
+      to label %invoke.cont unwind %invoke.unwind
+
+invoke.cont:
+  call void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
+  call void @llvm.stackrestore(i8* %base)
+  ...
+
+invoke.unwind:
+  call void @Foo_dtor(%struct.Foo* %b)
+  call void @llvm.stackrestore(i8* %base)
+  ...
+}
+</pre></div>
+</div>
+<p>To avoid stack leaks, the frontend saves the current stack pointer with
+a call to <a class="reference internal" href="LangRef.html#int-stacksave"><em>llvm.stacksave</em></a>.  Then, it allocates the
+argument stack space with alloca and calls the default constructor.  The
+default constructor could throw an exception, so the frontend has to
+create a landing pad.  The frontend has to destroy the already
+constructed argument <tt class="docutils literal"><span class="pre">b</span></tt> before restoring the stack pointer.  If the
+constructor does not unwind, <tt class="docutils literal"><span class="pre">g</span></tt> is called.  In the Microsoft C++ ABI,
+<tt class="docutils literal"><span class="pre">g</span></tt> will destroy its arguments, and then the stack is restored in
+<tt class="docutils literal"><span class="pre">f</span></tt>.</p>
+</div>
+<div class="section" id="design-considerations">
+<h2>Design Considerations<a class="headerlink" href="#design-considerations" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="lifetime">
+<h3>Lifetime<a class="headerlink" href="#lifetime" title="Permalink to this headline">¶</a></h3>
+<p>The biggest design consideration for this feature is object lifetime.
+We cannot model the arguments as static allocas in the entry block,
+because all calls need to use the memory at the top of the stack to pass
+arguments.  We cannot vend pointers to that memory at function entry
+because after code generation they will alias.</p>
+<p>The rule against allocas between argument allocations and the call site
+avoids this problem, but it creates a cleanup problem.  Cleanup and
+lifetime is handled explicitly with stack save and restore calls.  In
+the future, we may want to introduce a new construct such as <tt class="docutils literal"><span class="pre">freea</span></tt>
+or <tt class="docutils literal"><span class="pre">afree</span></tt> to make it clear that this stack adjusting cleanup is less
+powerful than a full stack save and restore.</p>
+</div>
+<div class="section" id="nested-calls-and-copy-elision">
+<h3>Nested Calls and Copy Elision<a class="headerlink" href="#nested-calls-and-copy-elision" title="Permalink to this headline">¶</a></h3>
+<p>We also want to be able to support copy elision into these argument
+slots.  This means we have to support multiple live argument
+allocations.</p>
+<p>Consider the evaluation of:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span class="c1">// Foo is non-trivial.</span>
+<span class="k">struct</span> <span class="n">Foo</span> <span class="p">{</span> <span class="kt">int</span> <span class="n">a</span><span class="p">;</span> <span class="n">Foo</span><span class="p">();</span> <span class="n">Foo</span><span class="p">(</span><span class="k">const</span> <span class="o">&</span><span class="n">Foo</span><span class="p">);</span> <span class="o">~</span><span class="n">Foo</span><span class="p">();</span> <span class="p">};</span>
+<span class="n">Foo</span> <span class="nf">bar</span><span class="p">(</span><span class="n">Foo</span> <span class="n">b</span><span class="p">);</span>
+<span class="kt">int</span> <span class="nf">main</span><span class="p">()</span> <span class="p">{</span>
+  <span class="n">bar</span><span class="p">(</span><span class="n">bar</span><span class="p">(</span><span class="n">Foo</span><span class="p">()));</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>In this case, we want to be able to elide copies into <tt class="docutils literal"><span class="pre">bar</span></tt>‘s argument
+slots.  That means we need to have more than one set of argument frames
+active at the same time.  First, we need to allocate the frame for the
+outer call so we can pass it in as the hidden struct return pointer to
+the middle call.  Then we do the same for the middle call, allocating a
+frame and passing its address to <tt class="docutils literal"><span class="pre">Foo</span></tt>‘s default constructor.  By
+wrapping the evaluation of the inner <tt class="docutils literal"><span class="pre">bar</span></tt> with stack save and
+restore, we can have multiple overlapping active call frames.</p>
+</div>
+<div class="section" id="callee-cleanup-calling-conventions">
+<h3>Callee-cleanup Calling Conventions<a class="headerlink" href="#callee-cleanup-calling-conventions" title="Permalink to this headline">¶</a></h3>
+<p>Another wrinkle is the existence of callee-cleanup conventions.  On
+Windows, all methods and many other functions adjust the stack to clear
+the memory used to pass their arguments.  In some sense, this means that
+the allocas are automatically cleared by the call.  However, LLVM
+instead models this as a write of undef to all of the inalloca values
+passed to the call instead of a stack adjustment.  Frontends should
+still restore the stack pointer to avoid a stack leak.</p>
+</div>
+<div class="section" id="exceptions">
+<h3>Exceptions<a class="headerlink" href="#exceptions" title="Permalink to this headline">¶</a></h3>
+<p>There is also the possibility of an exception.  If argument evaluation
+or copy construction throws an exception, the landing pad must do
+cleanup, which includes adjusting the stack pointer to avoid a stack
+leak.  This means the cleanup of the stack memory cannot be tied to the
+call itself.  There needs to be a separate IR-level instruction that can
+perform independent cleanup of arguments.</p>
+</div>
+<div class="section" id="efficiency">
+<h3>Efficiency<a class="headerlink" href="#efficiency" title="Permalink to this headline">¶</a></h3>
+<p>Eventually, it should be possible to generate efficient code for this
+construct.  In particular, using inalloca should not require a base
+pointer.  If the backend can prove that all points in the CFG only have
+one possible stack level, then it can address the stack directly from
+the stack pointer.  While this is not yet implemented, the plan is that
+the inalloca attribute should not change much, but the frontend IR
+generation recommendations may change.</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="BigEndianNEON.html" title="Using ARM NEON instructions in big endian mode"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="StackMaps.html" title="Stack maps and patch points 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-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file

Added: www-releases/trunk/3.9.1/docs/LLVMBuild.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.9.1/docs/LLVMBuild.html?rev=290368&view=auto
==============================================================================
--- www-releases/trunk/3.9.1/docs/LLVMBuild.html (added)
+++ www-releases/trunk/3.9.1/docs/LLVMBuild.html Thu Dec 22 14:04:03 2016
@@ -0,0 +1,382 @@
+
+<!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>LLVMBuild Guide — LLVM 3.9 documentation</title>
+    
+    <link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
+    <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+    
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    './',
+        VERSION:     '3.9',
+        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 3.9 documentation" href="index.html" />
+    <link rel="next" title="How To Release LLVM To The Public" href="HowToReleaseLLVM.html" />
+    <link rel="prev" title="Creating an LLVM Project" href="Projects.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="HowToReleaseLLVM.html" title="How To Release LLVM To The Public"
+             accesskey="N">next</a> |</li>
+        <li class="right" >
+          <a href="Projects.html" title="Creating an LLVM Project"
+             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="llvmbuild-guide">
+<h1>LLVMBuild Guide<a class="headerlink" href="#llvmbuild-guide" 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="#project-organization" id="id2">Project Organization</a></li>
+<li><a class="reference internal" href="#build-integration" id="id3">Build Integration</a></li>
+<li><a class="reference internal" href="#component-overview" id="id4">Component Overview</a></li>
+<li><a class="reference internal" href="#llvmbuild-format-reference" id="id5">LLVMBuild Format Reference</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document describes the <tt class="docutils literal"><span class="pre">LLVMBuild</span></tt> organization and files which
+we use to describe parts of the LLVM ecosystem. For description of
+specific LLVMBuild related tools, please see the command guide.</p>
+<p>LLVM is designed to be a modular set of libraries which can be flexibly
+mixed together in order to build a variety of tools, like compilers,
+JITs, custom code generators, optimization passes, interpreters, and so
+on. Related projects in the LLVM system like Clang and LLDB also tend to
+follow this philosophy.</p>
+<p>In order to support this usage style, LLVM has a fairly strict structure
+as to how the source code and various components are organized. The
+<tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> files are the explicit specification of that
+structure, and are used by the build systems and other tools in order to
+develop the LLVM project.</p>
+</div>
+<div class="section" id="project-organization">
+<h2><a class="toc-backref" href="#id2">Project Organization</a><a class="headerlink" href="#project-organization" title="Permalink to this headline">¶</a></h2>
+<p>The source code for LLVM projects using the LLVMBuild system (LLVM,
+Clang, and LLDB) is organized into <em>components</em>, which define the
+separate pieces of functionality that make up the project. These
+projects may consist of many libraries, associated tools, build tools,
+or other utility tools (for example, testing tools).</p>
+<p>For the most part, the project contents are organized around defining
+one main component per each subdirectory. Each such directory contains
+an <tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> which contains the component definitions.</p>
+<p>The component descriptions for the project as a whole are automatically
+gathered by the LLVMBuild tools. The tools automatically traverse the
+source directory structure to find all of the component description
+files. NOTE: For performance/sanity reasons, we only traverse into
+subdirectories when the parent itself contains an <tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt>
+description file.</p>
+</div>
+<div class="section" id="build-integration">
+<h2><a class="toc-backref" href="#id3">Build Integration</a><a class="headerlink" href="#build-integration" title="Permalink to this headline">¶</a></h2>
+<p>The LLVMBuild files themselves are just a declarative way to describe
+the project structure. The actual building of the LLVM project is
+handled by another build system (See: <a class="reference internal" href="CMake.html"><em>CMake</em></a>).</p>
+<p>The build system implementation will load the relevant contents of the
+LLVMBuild files and use that to drive the actual project build.
+Typically, the build system will only need to load this information at
+“configure” time, and use it to generative native information. Build
+systems will also handle automatically reconfiguring their information
+when the contents of the <tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> files change.</p>
+<p>Developers generally are not expected to need to be aware of the details
+of how the LLVMBuild system is integrated into their build. Ideally,
+LLVM developers who are not working on the build system would only ever
+need to modify the contents of the <tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> description files
+(although we have not reached this goal yet).</p>
+<p>For more information on the utility tool we provide to help interfacing
+with the build system, please see the <a class="reference internal" href="CommandGuide/llvm-build.html"><em>llvm-build</em></a> documentation.</p>
+</div>
+<div class="section" id="component-overview">
+<h2><a class="toc-backref" href="#id4">Component Overview</a><a class="headerlink" href="#component-overview" title="Permalink to this headline">¶</a></h2>
+<p>As mentioned earlier, LLVM projects are organized into logical
+<em>components</em>. Every component is typically grouped into its own
+subdirectory. Generally, a component is organized around a coherent
+group of sources which have some kind of clear API separation from other
+parts of the code.</p>
+<p>LLVM primarily uses the following types of components:</p>
+<ul class="simple">
+<li><em>Libraries</em> - Library components define a distinct API which can be
+independently linked into LLVM client applications. Libraries typically
+have private and public header files, and may specify a link of required
+libraries that they build on top of.</li>
+<li><em>Build Tools</em> - Build tools are applications which are designed to be run
+as part of the build process (typically to generate other source files).
+Currently, LLVM uses one main build tool called <a class="reference internal" href="TableGen/index.html"><em>TableGen</em></a>
+to generate a variety of source files.</li>
+<li><em>Tools</em> - Command line applications which are built using the LLVM
+component libraries. Most LLVM tools are small and are primarily
+frontends to the library interfaces.</li>
+</ul>
+<p>Components are described using <tt class="docutils literal"><span class="pre">LLVMBuild.txt</span></tt> files in the directories
+that define the component. See the <a class="reference internal" href="#llvmbuild-format-reference">LLVMBuild Format Reference</a> section
+for information on the exact format of these files.</p>
+</div>
+<div class="section" id="llvmbuild-format-reference">
+<h2><a class="toc-backref" href="#id5">LLVMBuild Format Reference</a><a class="headerlink" href="#llvmbuild-format-reference" title="Permalink to this headline">¶</a></h2>
+<p>LLVMBuild files are written in a simple variant of the INI or configuration
+file format (<a class="reference external" href="http://en.wikipedia.org/wiki/INI_file">Wikipedia entry</a>). The format defines a list of sections
+each of which may contain some number of properties. A simple example of
+the file format is below:</p>
+<div class="highlight-ini"><div class="highlight"><pre><span class="c1">; Comments start with a semi-colon.</span>
+
+<span class="c1">; Sections are declared using square brackets.</span>
+<span class="k">[component_0]</span>
+
+<span class="c1">; Properties are declared using '=' and are contained in the previous section.</span>
+<span class="c1">;</span>
+<span class="c1">; We support simple string and boolean scalar values and list values, where</span>
+<span class="c1">; items are separated by spaces. There is no support for quoting, and so</span>
+<span class="c1">; property values may not contain spaces.</span>
+<span class="na">property_name</span> <span class="o">=</span> <span class="s">property_value</span>
+<span class="na">list_property_name</span> <span class="o">=</span> <span class="s">value_1 value_2 ... value_n</span>
+<span class="na">boolean_property_name</span> <span class="o">=</span> <span class="s">1 (or 0)</span>
+</pre></div>
+</div>
+<p>LLVMBuild files are expected to define a strict set of sections and
+properties. A typical component description file for a library
+component would look like the following example:</p>
+<div class="highlight-ini"><div class="highlight"><pre><span class="k">[component_0]</span>
+<span class="na">type</span> <span class="o">=</span> <span class="s">Library</span>
+<span class="na">name</span> <span class="o">=</span> <span class="s">Linker</span>
+<span class="na">parent</span> <span class="o">=</span> <span class="s">Libraries</span>
+<span class="na">required_libraries</span> <span class="o">=</span> <span class="s">Archive BitReader Core Support TransformUtils</span>
+</pre></div>
+</div>
+<p>A full description of the exact sections and properties which are
+allowed follows.</p>
+<p>Each file may define exactly one common component, named <tt class="docutils literal"><span class="pre">common</span></tt>. The
+common component may define the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">subdirectories</span></tt> <strong>[optional]</strong></p>
+<p>If given, a list of the names of the subdirectories from the current
+subpath to search for additional LLVMBuild files.</p>
+</li>
+</ul>
+<p>Each file may define multiple components. Each component is described by a
+section who name starts with <tt class="docutils literal"><span class="pre">component</span></tt>. The remainder of the section
+name is ignored, but each section name must be unique. Typically components
+are just number in order for files with multiple components
+(<tt class="docutils literal"><span class="pre">component_0</span></tt>, <tt class="docutils literal"><span class="pre">component_1</span></tt>, and so on).</p>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">Section names not matching this format (or the <tt class="docutils literal"><span class="pre">common</span></tt> section) are
+currently unused and are disallowed.</p>
+</div>
+<p>Every component is defined by the properties in the section. The exact
+list of properties that are allowed depends on the component type.
+Components <strong>may not</strong> define any properties other than those expected
+by the component type.</p>
+<p>Every component must define the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span></tt> <strong>[required]</strong></p>
+<p>The type of the component. Supported component types are detailed
+below. Most components will define additional properties which may be
+required or optional.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">name</span></tt> <strong>[required]</strong></p>
+<p>The name of the component. Names are required to be unique across the
+entire project.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">parent</span></tt> <strong>[required]</strong></p>
+<p>The name of the logical parent of the component. Components are
+organized into a logical tree to make it easier to navigate and
+organize groups of components. The parents have no semantics as far
+as the project build is concerned, however. Typically, the parent
+will be the main component of the parent directory.</p>
+<p>Components may reference the root pseudo component using <tt class="docutils literal"><span class="pre">$ROOT</span></tt> to
+indicate they should logically be grouped at the top-level.</p>
+</li>
+</ul>
+<p>Components may define the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">dependencies</span></tt> <strong>[optional]</strong></p>
+<p>If specified, a list of names of components which <em>must</em> be built
+prior to this one. This should only be exactly those components which
+produce some tool or source code required for building the component.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last"><tt class="docutils literal"><span class="pre">Group</span></tt> and <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt> components have no semantics for the
+actual build, and are not allowed to specify dependencies.</p>
+</div>
+</li>
+</ul>
+<p>The following section lists the available component types, as well as
+the properties which are associated with that component.</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">Group</span></tt></p>
+<p>Group components exist purely to allow additional arbitrary structuring
+of the logical components tree. For example, one might define a
+<tt class="docutils literal"><span class="pre">Libraries</span></tt> group to hold all of the root library components.</p>
+<p><tt class="docutils literal"><span class="pre">Group</span></tt> components have no additionally properties.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">Library</span></tt></p>
+<p>Library components define an individual library which should be built
+from the source code in the component directory.</p>
+<p>Components with this type use the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">library_name</span></tt> <strong>[optional]</strong></p>
+<p>If given, the name to use for the actual library file on disk. If
+not given, the name is derived from the component name itself.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">required_libraries</span></tt> <strong>[optional]</strong></p>
+<p>If given, a list of the names of <tt class="docutils literal"><span class="pre">Library</span></tt> or <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt>
+components which must also be linked in whenever this library is
+used. That is, the link time dependencies for this component. When
+tools are built, the build system will include the transitive closure
+of all <tt class="docutils literal"><span class="pre">required_libraries</span></tt> for the components the tool needs.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">add_to_library_groups</span></tt> <strong>[optional]</strong></p>
+<p>If given, a list of the names of <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt> components which
+this component is also part of. This allows nesting groups of
+components.  For example, the <tt class="docutils literal"><span class="pre">X86</span></tt> target might define a library
+group for all of the <tt class="docutils literal"><span class="pre">X86</span></tt> components. That library group might
+then be included in the <tt class="docutils literal"><span class="pre">all-targets</span></tt> library group.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">installed</span></tt> <strong>[optional]</strong> <strong>[boolean]</strong></p>
+<p>Whether this library is installed. Libraries that are not installed
+are only reported by <tt class="docutils literal"><span class="pre">llvm-config</span></tt> when it is run as part of a
+development directory.</p>
+</li>
+</ul>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">LibraryGroup</span></tt></p>
+<p><tt class="docutils literal"><span class="pre">LibraryGroup</span></tt> components are a mechanism to allow easy definition of
+useful sets of related components. In particular, we use them to easily
+specify things like “all targets”, or “all assembly printers”.</p>
+<p>Components with this type use the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">required_libraries</span></tt> <strong>[optional]</strong></p>
+<p>See the <tt class="docutils literal"><span class="pre">Library</span></tt> type for a description of this property.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">add_to_library_groups</span></tt> <strong>[optional]</strong></p>
+<p>See the <tt class="docutils literal"><span class="pre">Library</span></tt> type for a description of this property.</p>
+</li>
+</ul>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">TargetGroup</span></tt></p>
+<p><tt class="docutils literal"><span class="pre">TargetGroup</span></tt> components are an extension of <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt>s,
+specifically for defining LLVM targets (which are handled specially in a
+few places).</p>
+<p>The name of the component should always be the name of the target.</p>
+<p>Components with this type use the <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt> properties in
+addition to:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">has_asmparser</span></tt> <strong>[optional]</strong> <strong>[boolean]</strong></p>
+<p>Whether this target defines an assembly parser.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">has_asmprinter</span></tt> <strong>[optional]</strong> <strong>[boolean]</strong></p>
+<p>Whether this target defines an assembly printer.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">has_disassembler</span></tt> <strong>[optional]</strong> <strong>[boolean]</strong></p>
+<p>Whether this target defines a disassembler.</p>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">has_jit</span></tt> <strong>[optional]</strong> <strong>[boolean]</strong></p>
+<p>Whether this target supports JIT compilation.</p>
+</li>
+</ul>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">Tool</span></tt></p>
+<p><tt class="docutils literal"><span class="pre">Tool</span></tt> components define standalone command line tools which should be
+built from the source code in the component directory and linked.</p>
+<p>Components with this type use the following properties:</p>
+<ul>
+<li><p class="first"><tt class="docutils literal"><span class="pre">required_libraries</span></tt> <strong>[optional]</strong></p>
+<p>If given, a list of the names of <tt class="docutils literal"><span class="pre">Library</span></tt> or <tt class="docutils literal"><span class="pre">LibraryGroup</span></tt>
+components which this tool is required to be linked with.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">The values should be the component names, which may not always
+match up with the actual library names on disk.</p>
+</div>
+<p>Build systems are expected to properly include all of the libraries
+required by the linked components (i.e., the transitive closure of
+<tt class="docutils literal"><span class="pre">required_libraries</span></tt>).</p>
+<p>Build systems are also expected to understand that those library
+components must be built prior to linking – they do not also need
+to be listed under <tt class="docutils literal"><span class="pre">dependencies</span></tt>.</p>
+</li>
+</ul>
+</li>
+<li><p class="first"><tt class="docutils literal"><span class="pre">type</span> <span class="pre">=</span> <span class="pre">BuildTool</span></tt></p>
+<p><tt class="docutils literal"><span class="pre">BuildTool</span></tt> components are like <tt class="docutils literal"><span class="pre">Tool</span></tt> components, except that the
+tool is supposed to be built for the platform where the build is running
+(instead of that platform being targeted). Build systems are expected
+to handle the fact that required libraries may need to be built for
+multiple platforms in order to be able to link this tool.</p>
+<p><tt class="docutils literal"><span class="pre">BuildTool</span></tt> components currently use the exact same properties as
+<tt class="docutils literal"><span class="pre">Tool</span></tt> components, the type distinction is only used to differentiate
+what the tool is built for.</p>
+</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="HowToReleaseLLVM.html" title="How To Release LLVM To The Public"
+             >next</a> |</li>
+        <li class="right" >
+          <a href="Projects.html" title="Creating an LLVM Project"
+             >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-2016, LLVM Project.
+      Last updated on 2016-12-21.
+      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.2.
+    </div>
+  </body>
+</html>
\ No newline at end of file




More information about the llvm-commits mailing list