[PGO] make profile prefix even shorter and more readable

[oota-llvm.git] / docs / TableGen / index.rst

diff --git a/docs/TableGen/index.rst b/docs/TableGen/index.rst
index e5aeb386855af08376673d55118285b9cb4e6346..9526240d54f45b0d084b6655ab580c7aa72e742e 100644 (file)
--- a/docs/TableGen/index.rst
+++ b/docs/TableGen/index.rst
@@ -10,6 +10,7 @@ TableGen
 
    BackEnds
    LangRef
+   LangIntro
    Deficiencies
 
 Introduction
@@ -23,7 +24,7 @@ amount of duplication in the description, reduces the chance of error, and makes
 it easier to structure domain specific information.
 
 The core part of TableGen parses a file, instantiates the declarations, and
-hands the result off to a domain-specific `backends`_ for processing.
+hands the result off to a domain-specific `backend`_ for processing.
 
 The current major users of TableGen are :doc:`../CodeGenerator`
 and the
@@ -122,7 +123,6 @@ this (at the time of this writing):
     bit hasCtrlDep = 0;
     bit isNotDuplicable = 0;
     bit hasSideEffects = 0;
-    bit neverHasSideEffects = 0;
     InstrItinClass Itinerary = NoItinerary;
     string Constraints = "";
     string DisableEncoding = "";
@@ -145,11 +145,10 @@ of the x86 architecture.  ``def ADD32rr`` defines a record named
 ``ADD32rr``, and the comment at the end of the line indicates the superclasses
 of the definition.  The body of the record contains all of the data that
 TableGen assembled for the record, indicating that the instruction is part of
-the "X86" namespace, the pattern indicating how the instruction should be
-emitted into the assembly file, that it is a two-address instruction, has a
-particular encoding, etc.  The contents and semantics of the information in the
-record are specific to the needs of the X86 backend, and are only shown as an
-example.
+the "X86" namespace, the pattern indicating how the instruction is selected by
+the code generator, that it is a two-address instruction, has a particular
+encoding, etc.  The contents and semantics of the information in the record are
+specific to the needs of the X86 backend, and are only shown as an example.
 
 As you can see, a lot of information is needed for every instruction supported
 by the code generator, and specifying it all manually would be unmaintainable,
@@ -182,7 +181,7 @@ refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
 Syntax
 ======
 
-TableGen has a syntax that is losely based on C++ templates, with built-in
+TableGen has a syntax that is loosely based on C++ templates, with built-in
 types and specification. In addition, TableGen's syntax introduces some
 automation concepts like multiclass, foreach, let, etc.
 
@@ -195,7 +194,7 @@ which are considered 'records'.
 **TableGen records** have a unique name, a list of values, and a list of
 superclasses.  The list of values is the main data that TableGen builds for each
 record; it is this that holds the domain specific information for the
-application.  The interpretation of this data is left to a specific `backends`_,
+application.  The interpretation of this data is left to a specific `backend`_,
 but the structure and format rules are taken care of and are fixed by
 TableGen.
 
@@ -256,7 +255,10 @@ in the current multiclass.
 
 
 
-See the `TableGen Language Reference <LangRef.html>`_ for more information.
+See the :doc:`TableGen Language Introduction <LangIntro>` for more generic
+information on the usage of the language, and the
+:doc:`TableGen Language Reference <LangRef>` for more in-depth description
+of the formal language specification.
 
 .. _backend:
 .. _backends:
@@ -270,7 +272,7 @@ that's only useful for debugging of the TableGen files themselves. The power
 in TableGen is, however, to interpret the source files into an internal 
 representation that can be generated into anything you want.
 
-Current usage of TableGen is to create include huge files with tables that you
+Current usage of TableGen is to create huge include files with tables that you
 can either include directly (if the output is in the language you're coding),
 or be used in pre-processing via macros surrounding the include of the file.
 
@@ -289,18 +291,18 @@ Despite being very generic, TableGen has some deficiencies that have been
 pointed out numerous times. The common theme is that, while TableGen allows
 you to build Domain-Specific-Languages, the final languages that you create
 lack the power of other DSLs, which in turn increase considerably the size
-and complecity of TableGen files.
+and complexity of TableGen files.
 
 At the same time, TableGen allows you to create virtually any meaning of
 the basic concepts via custom-made back-ends, which can pervert the original
 design and make it very hard for newcomers to understand the evil TableGen
 file.
 
-There are some in favour of extending the semantics even more, but makeing sure
-back-ends adhere to strict rules. Others suggesting we should move to less,
+There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others are suggesting we should move to less,
 more powerful DSLs designed with specific purposes, or even re-using existing
 DSLs.
 
-Either way, this is a discussion that is likely spanning across several years,
+Either way, this is a discussion that will likely span across several years,
 if not decades. You can read more in the `TableGen Deficiencies <Deficiencies.html>`_
 document.