[docs] Fixing Sphinx warnings to unclog the buildbot

Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).

Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.

This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).

Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.

I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.

llvm-svn: 276109

2 files changed, 19 insertions, 19 deletions

diff --git a/llvm/docs/TableGen/LangIntro.rst b/llvm/docs/TableGen/LangIntro.rst
index a148634e3ed..c1391e73646 100644
--- a/llvm/docs/TableGen/LangIntro.rst
+++ b/llvm/docs/TableGen/LangIntro.rst
@@ -232,7 +232,7 @@ the record ends with a semicolon.
 
 Here is a simple TableGen file:
 
-.. code-block:: llvm
+.. code-block:: text
 
   class C { bit V = 1; }
   def X : C;
@@ -276,7 +276,7 @@ derived class or definition wants to override.  Let expressions consist of the
 value.  For example, a new class could be added to the example above, redefining
 the ``V`` field for all of its subclasses:
 
-.. code-block:: llvm
+.. code-block:: text
 
   class D : C { let V = 0; }
   def Z : D;
@@ -295,7 +295,7 @@ concrete classes.  Parameterized TableGen classes specify a list of variable
 bindings (which may optionally have defaults) that are bound when used.  Here is
 a simple example:
 
-.. code-block:: llvm
+.. code-block:: text
 
   class FPFormat<bits<3> val> {
     bits<3> Value = val;
@@ -316,7 +316,7 @@ integer.
 The more esoteric forms of `TableGen expressions`_ are useful in conjunction
 with template arguments.  As an example:
 
-.. code-block:: llvm
+.. code-block:: text
 
   class ModRefVal<bits<2> val> {
     bits<2> Value = val;
@@ -346,7 +346,7 @@ be used to decouple the interface provided to the user of the class from the
 actual internal data representation expected by the class.  In this case,
 running ``llvm-tblgen`` on the example prints the following definitions:
 
-.. code-block:: llvm
+.. code-block:: text
 
   def bork {      // Value
     bit isMod = 1;
@@ -379,7 +379,7 @@ commonality exists, then in a separate place indicate what all the ops are.
 
 Here is an example TableGen fragment that shows this idea:
 
-.. code-block:: llvm
+.. code-block:: text
 
   def ops;
   def GPR;
@@ -405,7 +405,7 @@ inherit from multiple multiclasses, instantiating definitions from each
 multiclass.  Using a multiclass this way is exactly equivalent to instantiating
 the classes multiple times yourself, e.g. by writing:
 
-.. code-block:: llvm
+.. code-block:: text
 
   def ops;
   def GPR;
@@ -432,7 +432,7 @@ the classes multiple times yourself, e.g. by writing:
 A ``defm`` can also be used inside a multiclass providing several levels of
 multiclass instantiations.
 
-.. code-block:: llvm
+.. code-block:: text
 
   class Instruction<bits<4> opc, string Name> {
     bits<4> opcode = opc;
@@ -473,7 +473,7 @@ multiclass instantiations.
 the class list must start after the last multiclass, and there must be at least
 one multiclass before them.
 
-.. code-block:: llvm
+.. code-block:: text
 
   class XD { bits<4> Prefix = 11; }
   class XS { bits<4> Prefix = 12; }
@@ -516,7 +516,7 @@ specified file in place of the include directive.  The filename should be
 specified as a double quoted string immediately after the '``include``' keyword.
 Example:
 
-.. code-block:: llvm
+.. code-block:: text
 
   include "foo.td"
 
@@ -532,7 +532,7 @@ commonality from the records.
 File-scope "let" expressions take a comma-separated list of bindings to apply,
 and one or more records to bind the values in.  Here are some examples:
 
-.. code-block:: llvm
+.. code-block:: text
 
   let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
     def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
@@ -559,7 +559,7 @@ ways to factor out commonality from the records, specially if using several
 levels of multiclass instantiations. This also avoids the need of using "let"
 expressions within subsequent records inside a multiclass.
 
-.. code-block:: llvm
+.. code-block:: text
 
   multiclass basic_r<bits<4> opc> {
     let Predicates = [HasSSE2] in {
@@ -587,7 +587,7 @@ TableGen supports the '``foreach``' block, which textually replicates the loop
 body, substituting iterator values for iterator references in the body.
 Example:
 
-.. code-block:: llvm
+.. code-block:: text
 
   foreach i = [0, 1, 2, 3] in {
     def R#i : Register<...>;
@@ -598,7 +598,7 @@ This will create objects ``R0``, ``R1``, ``R2`` and ``R3``.  ``foreach`` blocks
 may be nested. If there is only one item in the body the braces may be
 elided:
 
-.. code-block:: llvm
+.. code-block:: text
 
   foreach i = [0, 1, 2, 3] in
     def R#i : Register<...>;
diff --git a/llvm/docs/TableGen/index.rst b/llvm/docs/TableGen/index.rst
index 9526240d54f..5ba555ac2d2 100644
--- a/llvm/docs/TableGen/index.rst
+++ b/llvm/docs/TableGen/index.rst
@@ -90,7 +90,7 @@ of the classes, then all of the definitions.  This is a good way to see what the
 various definitions expand to fully.  Running this on the ``X86.td`` file prints
 this (at the time of this writing):
 
-.. code-block:: llvm
+.. code-block:: text
 
   ...
   def ADD32rr {   // Instruction X86Inst I
@@ -155,7 +155,7 @@ by the code generator, and specifying it all manually would be unmaintainable,
 prone to bugs, and tiring to do in the first place.  Because we are using
 TableGen, all of the information was derived from the following definition:
 
-.. code-block:: llvm
+.. code-block:: text
 
   let Defs = [EFLAGS],
       isCommutable = 1,                  // X = ADD Y,Z --> X = ADD Z,Y
@@ -201,7 +201,7 @@ TableGen.
 **TableGen definitions** are the concrete form of 'records'.  These generally do
 not have any undefined values, and are marked with the '``def``' keyword.
 
-.. code-block:: llvm
+.. code-block:: text
 
   def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
                                         "Enable ARMv8 FP">;
@@ -220,7 +220,7 @@ floating point instructions in the X86 backend).  TableGen keeps track of all of
 the classes that are used to build up a definition, so the backend can find all
 definitions of a particular class, such as "Instruction".
 
-.. code-block:: llvm
+.. code-block:: text
 
  class ProcNoItin<string Name, list<SubtargetFeature> Features>
        : Processor<Name, NoItineraries, Features>;
@@ -235,7 +235,7 @@ If a multiclass inherits from another multiclass, the definitions in the
 sub-multiclass become part of the current multiclass, as if they were declared
 in the current multiclass.
 
-.. code-block:: llvm
+.. code-block:: text
 
   multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
                           dag address, ValueType sty> {