[docs] Fix sphinx doc generation errors

[rupprecht]

Summary

Errors fixed:

• GettingStarted: Duplicate explicit target name: "cmake"
• GlobalISel: Unexpected indentation
• LoopTerminology: Explicit markup ends without a blank line; unexpected unindent
• ORCv2: Definition list ends without a blank line; unexpected unindent
• Misc: document isn't included in any toctree

Verified that a clean docs build (rm -rf docs/ && ninja docs-llvm-html) passes with no errors. Spot checked the individual pages to make sure they look OK.

[dsanders]

LGTM

llvm/trunk/docs/GettingStarted.rst

* Run your build tool of choice!
      * CMake will generate build targets for each tool and library, and most
        LLVM sub-projects generate their own ``check-<project>`` target.
 
      * Running a serial build will be *slow*.  Make sure you run a parallel
        build. That's already done by default in Ninja; for ``make``, use
        ``make -j NNN`` (with an appropriate value of NNN, e.g. number of CPUs
        you have.)
 
-   * For more information see `CMake <CMake.html>`_
+   * For more information see `CMake <CMake.html>`__
 
    * If you get an "internal compiler error (ICE)" or test failures, see
      `below`_.
 
 Consult the `Getting Started with LLVM`_ section for detailed information on
 configuring and compiling LLVM.  Go to `Directory Layout`_ to learn about the
 layout of the source code tree.
 

 table below lists those required packages. The Package column is the usual name
 for the software package that LLVM depends on. The Version column provides
 "known to work" versions of the package. The Notes column describes how LLVM
 uses the package and provides other details.
 
 =========================================================== ============ ==========================================
 Package                                                     Version      Notes
 =========================================================== ============ ==========================================
-`CMake <http://cmake.org/>`_                                >=3.4.3      Makefile/workspace generator
+`CMake <http://cmake.org/>`__                               >=3.4.3      Makefile/workspace generator
 `GCC <http://gcc.gnu.org/>`_                                >=5.1.0      C/C++ compiler\ :sup:`1`
 `python <http://www.python.org/>`_                          >=2.7        Automated test suite\ :sup:`2`
 `zlib <http://zlib.net>`_                                   >=1.2.3.4    Compression library\ :sup:`3`
 `GNU Make <http://savannah.gnu.org/projects/make>`_         3.79, 3.79.1 Makefile/build processor\ :sup:`4`
 =========================================================== ============ ==========================================
 
 .. note::
 

llvm/trunk/docs/GlobalISel.rst

 * G_TRUNC must be legal for all inputs from the producer type set and all
   smaller outputs from the consumer type set.
 
 G_ANYEXT, and G_TRUNC have mandatory legality since the GMIR requires a means to
 connect operations with different type sizes. They are usually trivial to support
 since G_ANYEXT doesn't define the value of the additional bits and G_TRUNC is
 discarding bits. The other conversions can be lowered into G_ANYEXT/G_TRUNC
 with some additional operations that are subject to further legalization. For
-example, G_SEXT can lower to:
+example, G_SEXT can lower to::
+
   %1 = G_ANYEXT %0
   %2 = G_CONSTANT ...
   %3 = G_SHL %1, %2
   %4 = G_ASHR %3, %2
+
 and the G_CONSTANT/G_SHL/G_ASHR can further lower to other operations or target
 instructions. Similarly, G_FPEXT has no legality requirement since it can lower
 to a G_ANYEXT followed by a target instruction.
 
 G_MERGE_VALUES and G_UNMERGE_VALUES do not have legality requirements since the
 former can lower to G_ANYEXT and some other legalizable instructions, while the
 latter can lower to some legalizable instructions followed by G_TRUNC.
 

 
 Minimum Legality For Operations
 """""""""""""""""""""""""""""""
 
 The rules for G_ANYEXT, G_MERGE_VALUES, G_BITCAST, G_BUILD_VECTOR,
 G_BUILD_VECTOR_TRUNC, G_CONCAT_VECTORS, G_UNMERGE_VALUES, G_PTRTOINT, and
 G_INTTOPTR have already been noted above. In addition to those, the following
 operations have requirements:
+
 * At least one G_IMPLICIT_DEF must be legal. This is usually trivial as it
   requires no code to be selected.
 * G_PHI must be legal for all types in the producer and consumer typesets. This
   is usually trivial as it requires no code to be selected.
 * At least one G_FRAME_INDEX must be legal
 * At least one G_BLOCK_ADDR must be legal
 
 There are many other operations you'd expect to have legality requirements but

llvm/trunk/docs/LoopTerminology.rst

 .. _loop-terminology:
+
 ===========================================
 LLVM Loop Terminology (and Canonical Forms)
 ===========================================
 
 .. contents::
    :local:
 
 Introduction

llvm/trunk/docs/ORCv2.rst

 is only accessible on the current thread, or that the context is locked. In the
 example above (where the context is never locked) we rely on the fact that both
 ``TSM1`` and ``TSM2``, and TSCtx are all created on one thread. If a context is
 going to be shared between threads then it must be locked before any accessing
 or creating any Modules attached to it. E.g.
 
   .. code-block:: c++
 
-
     ThreadSafeContext TSCtx(llvm::make_unique<LLVMContext>());
 
     ThreadPool TP(NumThreads);
     JITStack J;
 
     for (auto &ModulePath : ModulePaths) {
       TP.async(
         [&]() {
           auto Lock = TSCtx.getLock();
-
           auto M = loadModuleOnContext(ModulePath, TSCtx.getContext());
-
           J.addModule(ThreadSafeModule(std::move(M), TSCtx));
         });
     }
 
     TP.wait();
 
 To make exclusive access to Modules easier to manage the ThreadSafeModule class
 provides a convenince function, ``withModuleDo``, that implicitly (1) locks the
 associated context, (2) runs a given function object, (3) unlocks the context,
 and (3) returns the result generated by the function object. E.g.
 
   .. code-block:: c++
 

llvm/trunk/docs/index.rst

.. toctree::
    :hidden:
 
    AliasAnalysis
    MemorySSA
    BitCodeFormat
    BlockFrequencyTerminology
    BranchWeightMetadata
    Bugpoint
+   BugpointRedesign
    CodeGenerator
    ExceptionHandling
    AddingConstrainedIntrinsics
    LinkTimeOptimization
    SegmentedStacks
    TableGenFundamentals
    TableGen/index
    DebuggingJITedCode
.. toctree::
    GlobalISel
    XRay
    XRayExample
    XRayFDRFormat
    PDB/index
    CFIVerify
    SpeculativeLoadHardening
    StackSafetyAnalysis
+   LoopTerminology
 
 :doc:`WritingAnLLVMPass`
    Information on how to write LLVM transformations and analyses.
 
 :doc:`WritingAnLLVMBackend`
    Information on how to write LLVM backends for machine targets.
 
 :doc:`CodeGenerator`

 :doc:`AddingConstrainedIntrinsics`
    Gives the steps necessary when adding a new constrained math intrinsic
    to LLVM.
 
 :doc:`Bugpoint`
    Automatic bug finder and test-case reducer description and usage
    information.
 
+:doc:`BugpointRedesign`
+   Design doc for a redesign of the Bugpoint tool.
+
 :doc:`BitCodeFormat`
    This describes the file format and encoding used for LLVM "bc" files.
 
 :doc:`Support Library <SupportLibrary>`
    This document describes the LLVM Support Library (``lib/Support``) and
    how to keep LLVM source code portable
 
 :doc:`LinkTimeOptimization`

 
 :doc:`SpeculativeLoadHardening`
   A description of the Speculative Load Hardening mitigation for Spectre v1.
 
 :doc:`StackSafetyAnalysis`
   This document describes the design of the stack safety analysis of local
   variables.
 
+:doc:`LoopTerminology`
+  A document describing Loops and associated terms as used in LLVM.
+
 Development Process Documentation
 =================================
 
 Information about LLVM's development process.
 
 .. toctree::
    :hidden:
 

llvm/trunk/docs/tutorial/index.rst

 ================================
 LLVM Tutorial: Table of Contents
 ================================
 
 Kaleidoscope: Implementing a Language with LLVM
 ===============================================
 
 .. toctree::
    :titlesonly:
    :glob:
    :numbered:
 
-#. `My First Language Frontend with LLVM Tutorial <MyFirstLanguageFrontend/index.html>`_
-   This is the "Kaleidoscope" Language tutorial, showing how to implement 
-   a simple language using LLVM components in C++.
+   MyFirstLanguageFrontend/index
+
+This is the "Kaleidoscope" Language tutorial, showing how to implement a simple
+language using LLVM components in C++.
 
 Kaleidoscope: Implementing a Language with LLVM in Objective Caml
 =================================================================
 
 .. toctree::
    :titlesonly:
    :glob:
    :numbered: