[llvm] r276109 - [docs] Fixing Sphinx warnings to unclog the buildbot
Hahnfeld, Jonas via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 20 05:50:18 PDT 2016
Hi,
Thanks for fixing these, I also hit them recently.
Should this be merged for 3.9 to allow the docs being built with sphinx 1.4
which I think they currently do not?
Thanks,
Jonas
> -----Original Message-----
> From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf
> Of Renato Golin via llvm-commits
> Sent: Wednesday, July 20, 2016 2:17 PM
> To: llvm-commits at lists.llvm.org
> Subject: [llvm] r276109 - [docs] Fixing Sphinx warnings to unclog the
> buildbot
>
> Author: rengolin
> Date: Wed Jul 20 07:16:38 2016
> New Revision: 276109
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276109&view=rev
> Log:
> [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.
>
> Modified:
> llvm/trunk/docs/CodeGenerator.rst
> llvm/trunk/docs/CommandGuide/FileCheck.rst
> llvm/trunk/docs/CommandGuide/llvm-nm.rst
> llvm/trunk/docs/CommandGuide/opt.rst
> llvm/trunk/docs/ExceptionHandling.rst
> llvm/trunk/docs/Extensions.rst
> llvm/trunk/docs/GarbageCollection.rst
> llvm/trunk/docs/GetElementPtr.rst
> llvm/trunk/docs/HowToUseInstrMappings.rst
> llvm/trunk/docs/InAlloca.rst
> llvm/trunk/docs/LangRef.rst
> llvm/trunk/docs/MIRLangRef.rst
> llvm/trunk/docs/MarkedUpDisassembly.rst
> llvm/trunk/docs/MergeFunctions.rst
> llvm/trunk/docs/NVPTXUsage.rst
> llvm/trunk/docs/SegmentedStacks.rst
> llvm/trunk/docs/SourceLevelDebugging.rst
> llvm/trunk/docs/Statepoints.rst
> llvm/trunk/docs/TableGen/LangIntro.rst
> llvm/trunk/docs/TableGen/index.rst
> llvm/trunk/docs/WritingAnLLVMBackend.rst
> llvm/trunk/docs/WritingAnLLVMPass.rst
>
> Modified: llvm/trunk/docs/CodeGenerator.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/CodeGenerator.rst?rev=276109&r1=276108&r2=276
> 109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/CodeGenerator.rst (original)
> +++ llvm/trunk/docs/CodeGenerator.rst Wed Jul 20 07:16:38 2016
> @@ -436,7 +436,7 @@ For example, consider this simple LLVM e
> The X86 instruction selector might produce this machine code for the
> ``div``
> and
> ``ret``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ;; Start of div
> %EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
> @@ -453,7 +453,7 @@ By the end of code generation, the regis
> registers and delete the resultant identity moves producing the following
> code:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ;; X is in EAX, Y is in ECX
> mov %EAX, %EDX
> @@ -965,7 +965,7 @@ target code. For example, consider the
>
> This LLVM code corresponds to a SelectionDAG that looks basically like
> this:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
>
>
> Modified: llvm/trunk/docs/CommandGuide/FileCheck.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/CommandGuide/FileCheck.rst?rev=276109&r1=276
> 108&r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/CommandGuide/FileCheck.rst (original)
> +++ llvm/trunk/docs/CommandGuide/FileCheck.rst Wed Jul 20 07:16:38 2016
> @@ -144,7 +144,7 @@ exists anywhere in the file.
> The FileCheck -check-prefix option
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -The FileCheck :option:`-check-prefix` option allows multiple test
> +The FileCheck `-check-prefix` option allows multiple test
> configurations to be driven from one `.ll` file. This is useful in many
> circumstances, for example, testing different architectural variants with
> :program:`llc`. Here's a simple example:
> @@ -303,7 +303,7 @@ be aware that the definition rule can ma
>
> So, for instance, the code below will pass:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
> ; CHECK-DAG: vmov.32 [[REG2]][1]
> @@ -312,7 +312,7 @@ So, for instance, the code below will pa
>
> While this other code, will not:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
> ; CHECK-DAG: vmov.32 [[REG2]][1]
> @@ -473,7 +473,7 @@ To match newline characters in regular e
>
> matches output of the form (from llvm-dwarfdump):
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> DW_AT_location [DW_FORM_sec_offset] (0x00000233)
> DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd")
>
> Modified: llvm/trunk/docs/CommandGuide/llvm-nm.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/CommandGuide/llvm-
> nm.rst?rev=276109&r1=276108&r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/CommandGuide/llvm-nm.rst (original)
> +++ llvm/trunk/docs/CommandGuide/llvm-nm.rst Wed Jul 20 07:16:38 2016
> @@ -68,11 +68,11 @@ OPTIONS
>
> .. option:: -B (default)
>
> - Use BSD output format. Alias for :option:`--format=bsd`.
> + Use BSD output format. Alias for `--format=bsd`.
>
> .. option:: -P
>
> - Use POSIX.2 output format. Alias for :option:`--format=posix`.
> + Use POSIX.2 output format. Alias for `--format=posix`.
>
> .. option:: --debug-syms, -a
>
>
> Modified: llvm/trunk/docs/CommandGuide/opt.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/CommandGuide/opt.rst?rev=276109&r1=276108&r
> 2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/CommandGuide/opt.rst (original)
> +++ llvm/trunk/docs/CommandGuide/opt.rst Wed Jul 20 07:16:38 2016
> @@ -12,16 +12,16 @@ DESCRIPTION
> The :program:`opt` command is the modular LLVM optimizer and analyzer. It
> takes LLVM source files as input, runs the specified optimizations or
> analyses
> on it, and then outputs the optimized file or the analysis results. The
> -function of :program:`opt` depends on whether the :option:`-analyze`
> option is
> +function of :program:`opt` depends on whether the `-analyze` option is
> given.
>
> -When :option:`-analyze` is specified, :program:`opt` performs various
> analyses
> +When `-analyze` is specified, :program:`opt` performs various analyses
> of the input source. It will usually print the results on standard output,
> but
> in a few cases, it will print output to standard error or generate a file
> with
> the analysis output, which is usually done when the output is meant for
> another
> program.
>
> -While :option:`-analyze` is *not* given, :program:`opt` attempts to produce
> an
> +While `-analyze` is *not* given, :program:`opt` attempts to produce an
> optimized output file. The optimizations available via :program:`opt`
> depend
> upon what libraries were linked into it as well as any additional libraries
> that have been loaded with the :option:`-load` option. Use the :option:`-
> help`
> @@ -68,19 +68,19 @@ OPTIONS
>
> .. option:: -disable-opt
>
> - This option is only meaningful when :option:`-std-link-opts` is given. It
> + This option is only meaningful when `-std-link-opts` is given. It
> disables most passes.
>
> .. option:: -strip-debug
>
> This option causes opt to strip debug information from the module before
> - applying other optimizations. It is essentially the same as
> :option:`-strip`
> + applying other optimizations. It is essentially the same as `-strip`
> but it ensures that stripping of debug information is done first.
>
> .. option:: -verify-each
>
> This option causes opt to add a verify pass after every pass otherwise
> - specified on the command line (including :option:`-verify`). This is
> useful
> + specified on the command line (including `-verify`). This is useful
> for cases where it is suspected that a pass is creating an invalid module
> but
> it is not clear which pass is doing it.
>
>
> Modified: llvm/trunk/docs/ExceptionHandling.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/ExceptionHandling.rst?rev=276109&r1=276108&r2=
> 276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/ExceptionHandling.rst (original)
> +++ llvm/trunk/docs/ExceptionHandling.rst Wed Jul 20 07:16:38 2016
> @@ -406,7 +406,7 @@ outlined. After the handler is outlined
> ``llvm.eh.exceptionpointer``
> ----------------------------
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> i8 addrspace(N)* @llvm.eh.padparam.pNi8(token %catchpad)
>
> @@ -427,7 +427,7 @@ backend. Uses of them are generated by
> ``llvm.eh.sjlj.setjmp``
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
>
> @@ -664,7 +664,7 @@ all of the new IR instructions:
> return 0;
> }
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 {
> entry:
> @@ -741,7 +741,7 @@ C++ code:
> }
> }
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void @f() #0 personality i8* bitcast (i32 (...)*
> @__CxxFrameHandler3
> to i8*) {
> entry:
>
> Modified: llvm/trunk/docs/Extensions.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/Extensions.rst?rev=276109&r1=276108&r2=276109
> &view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/Extensions.rst (original)
> +++ llvm/trunk/docs/Extensions.rst Wed Jul 20 07:16:38 2016
> @@ -43,7 +43,7 @@ The following additional relocation type
> corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-
> bit) or
> ``IMAGE_REL_AMD64_ADDR32NB`` (64-bit).
>
> -.. code-block:: gas
> +.. code-block:: text
>
> .text
> fun:
>
> Modified: llvm/trunk/docs/GarbageCollection.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/GarbageCollection.rst?rev=276109&r1=276108&r2=
> 276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/GarbageCollection.rst (original)
> +++ llvm/trunk/docs/GarbageCollection.rst Wed Jul 20 07:16:38 2016
> @@ -204,7 +204,7 @@ IR features is specified by the selected
> Specifying GC code generation: ``gc "..."``
> -------------------------------------------
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define <returntype> @name(...) gc "name" { ... }
>
>
> Modified: llvm/trunk/docs/GetElementPtr.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/GetElementPtr.rst?rev=276109&r1=276108&r2=276
> 109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/GetElementPtr.rst (original)
> +++ llvm/trunk/docs/GetElementPtr.rst Wed Jul 20 07:16:38 2016
> @@ -105,7 +105,7 @@ memory, or a global variable.
>
> To make this clear, let's consider a more obtuse example:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %MyVar = uninitialized global i32
> ...
> @@ -142,7 +142,7 @@ Quick answer: there are no superfluous i
> This question arises most often when the GEP instruction is applied to a
> global
> variable which is always a pointer type. For example, consider this:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %MyStruct = uninitialized global { float*, i32 }
> ...
> @@ -178,7 +178,7 @@ The GetElementPtr instruction dereferenc
> memory in any way. That's what the Load and Store instructions are for.
> GEP
> is
> only involved in the computation of addresses. For example, consider this:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %MyVar = uninitialized global { [40 x i32 ]* }
> ...
> @@ -195,7 +195,7 @@ illegal.
> In order to access the 18th integer in the array, you would need to do the
> following:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0
> %arr = load [40 x i32]** %idx
> @@ -204,7 +204,7 @@ following:
> In this case, we have to load the pointer in the structure with a load
> instruction before we can index into the array. If the example was changed
> to:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %MyVar = uninitialized global { [40 x i32 ] }
> ...
>
> Modified: llvm/trunk/docs/HowToUseInstrMappings.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/HowToUseInstrMappings.rst?rev=276109&r1=2761
> 08&r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/HowToUseInstrMappings.rst (original)
> +++ llvm/trunk/docs/HowToUseInstrMappings.rst Wed Jul 20 07:16:38 2016
> @@ -30,7 +30,7 @@ instructions with each other. These tabl
> ``XXXInstrInfo.inc`` file along with the functions to query them. Following
> is the definition of ``InstrMapping`` class definied in Target.td file:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class InstrMapping {
> // Used to reduce search space only to the instructions using this
> @@ -69,7 +69,7 @@ non-predicated form by assigning appropr
> fields. For this relationship, non-predicated instructions are treated as
> key
> instruction since they are the one used to query the interface function.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def getPredOpcode : InstrMapping {
> // Choose a FilterClass that is used as a base class for all the
> @@ -116,7 +116,7 @@ to include relevant information in its d
> following to be the current definitions of ADD, ADD_pt (true) and ADD_pf
> (false)
> instructions:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def ADD : ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
> "$dst = add($a, $b)",
> @@ -137,7 +137,7 @@ In this step, we modify these instructio
> required by the relationship model, <tt>getPredOpcode</tt>, so that they
> can
> be related.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a,
> IntRegs:$b),
> "$dst = add($a, $b)",
>
> Modified: llvm/trunk/docs/InAlloca.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/InAlloca.rst?rev=276109&r1=276108&r2=276109&vi
> ew=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/InAlloca.rst (original)
> +++ llvm/trunk/docs/InAlloca.rst Wed Jul 20 07:16:38 2016
> @@ -41,7 +41,7 @@ that passes two default-constructed ``Fo
> g(Foo(), Foo());
> }
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %struct.Foo = type { i32, i32 }
> declare void @Foo_ctor(%struct.Foo* %this)
>
> Modified: llvm/trunk/docs/LangRef.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/LangRef.rst?rev=276109&r1=276108&r2=276109&vi
> ew=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/LangRef.rst (original)
> +++ llvm/trunk/docs/LangRef.rst Wed Jul 20 07:16:38 2016
> @@ -839,7 +839,7 @@ Note that the Mach-O platform doesn't su
> Here is an example of a COMDAT group where a function will only be
> selected if
> the COMDAT key's section is the largest:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> $foo = comdat largest
> @foo = global i32 2, comdat($foo)
> @@ -851,7 +851,7 @@ the COMDAT key's section is the largest:
> As a syntactic sugar the ``$name`` can be omitted if the name is the same
> as
> the global name:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> $foo = comdat any
> @foo = global i32 2, comdat
> @@ -875,7 +875,7 @@ if a collision occurs in the symbol tabl
> The combined use of COMDATS and section attributes may yield surprising
> results.
> For example:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> $foo = comdat any
> $bar = comdat any
> @@ -1205,7 +1205,7 @@ makes the format of the prologue data hi
> A trivial example of valid prologue data for the x86 architecture is ``i8
> 144``,
> which encodes the ``nop`` instruction:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void @f() prologue i8 144 { ... }
>
> @@ -1213,7 +1213,7 @@ Generally prologue data can be formed by
> which skips the metadata, as in this example of valid prologue data for the
> x86_64 architecture, where the first two bytes encode ``jmp .+10``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %0 = type <{ i8, i8, i8* }>
>
> @@ -2237,7 +2237,7 @@ source file name to the local function n
>
> The syntax for the source file name is simply:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> source_filename = "/path/to/source.c"
>
> @@ -2847,7 +2847,7 @@ cleared low bit. However, in the ``%C``
> allowed to assume that the '``undef``' operand could be the same as
> ``%Y``, allowing the whole '``select``' to be eliminated.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %A = xor undef, undef
>
> @@ -2899,7 +2899,7 @@ does not execute at all. This allows us
> code after it. Because the undefined operation "can't happen", the
> optimizer can assume that it occurs in dead code.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> a: store undef -> %X
> b: store %X -> undef
> @@ -3884,7 +3884,7 @@ their operand. For example:
>
> Metadata nodes that aren't uniqued use the ``distinct`` keyword. For
> example:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = distinct !{!"test\00", i32 10}
>
> @@ -3949,7 +3949,7 @@ fields are tuples containing the debug i
> unit, regardless of code optimizations (some nodes are only emitted if
> there
> are
> references to them from instructions).
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang",
> isOptimized: true, flags: "-O2", runtimeVersion: 2,
> @@ -3985,7 +3985,7 @@ DIBasicType
> ``DIBasicType`` nodes represent primitive types, such as ``int``, ``bool``
> and
> ``float``. ``tag:`` defaults to ``DW_TAG_base_type``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
> encoding: DW_ATE_unsigned_char)
> @@ -3994,7 +3994,7 @@ DIBasicType
> The ``encoding:`` describes the details of the type. Usually it's one of
> the
> following:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> DW_ATE_address = 1
> DW_ATE_boolean = 2
> @@ -4014,7 +4014,7 @@ refers to a tuple; the first operand is
> types of the formal arguments in order. If the first operand is ``null``,
> that
> represents a function with no return value (such as ``void foo() {}`` in
> C++).
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !BasicType(name: "int", size: 32, align: 32, DW_ATE_signed)
> !1 = !BasicType(name: "char", size: 8, align: 8, DW_ATE_signed_char)
> @@ -4028,7 +4028,7 @@ DIDerivedType
> ``DIDerivedType`` nodes represent types derived from other types, such as
> qualified types.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
> encoding: DW_ATE_unsigned_char)
> @@ -4037,7 +4037,7 @@ qualified types.
>
> The following ``tag:`` values are valid:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> DW_TAG_member = 13
> DW_TAG_pointer_type = 15
> @@ -4089,7 +4089,7 @@ does not have ``flags: DIFlagFwdDecl``
> together will unique such definitions at parse time via the ``identifier:``
> field, even if the nodes are ``distinct``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DIEnumerator(name: "SixKind", value: 7)
> !1 = !DIEnumerator(name: "SevenKind", value: 7)
> @@ -4100,7 +4100,7 @@ field, even if the nodes are ``distinct`
>
> The following ``tag:`` values are valid:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> DW_TAG_array_type = 1
> DW_TAG_class_type = 2
> @@ -4219,7 +4219,7 @@ type with an ODR ``identifier:`` and tha
> then the subprogram declaration is uniqued based only on its
> ``linkageName:``
> and ``scope:``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void @_Z3foov() !dbg !0 {
> ...
> @@ -4244,7 +4244,7 @@ DILexicalBlock
> two lexical blocks at same depth. They are valid targets for ``scope:``
> fields.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = distinct !DILexicalBlock(scope: !1, file: !2, line: 7, column: 35)
>
> @@ -4290,7 +4290,7 @@ the ``arg:`` field is set to non-zero, t
> parameter, and it will be included in the ``variables:`` field of its
> :ref:`DISubprogram`.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DILocalVariable(name: "this", arg: 1, scope: !3, file: !2, line:
> 7,
> type: !3, flags: DIFlagArtificial)
> @@ -4313,7 +4313,7 @@ The current supported vocabulary is limi
> - ``DW_OP_bit_piece, 16, 8`` specifies the offset and size (``16`` and
> ``8``
> here, respectively) of the variable piece from the working expression.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !DIExpression(DW_OP_deref)
> !1 = !DIExpression(DW_OP_plus, 3)
> @@ -4336,7 +4336,7 @@ DIImportedEntity
> ``DIImportedEntity`` nodes represent entities (such as modules) imported
> into a
> compile unit.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo",
> scope: !0,
> entity: !1, line: 7)
> @@ -4349,7 +4349,7 @@ The ``name:`` field is the macro identif
> defining a function-like macro, and the ``value`` field is the token-string
> used to expand the macro identifier.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !2 = !DIMacro(macinfo: DW_MACINFO_define, line: 7, name: "foo(x)",
> value: "((x) + 1)")
> @@ -4362,7 +4362,7 @@ DIMacroFile
> The ``nodes:`` field is a list of ``DIMacro`` and ``DIMacroFile`` nodes
> that
> appear in the included source file.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !2 = !DIMacroFile(macinfo: DW_MACINFO_start_file, line: 7, file: !2,
> nodes: !3)
> @@ -5660,7 +5660,7 @@ block. Therefore, it must be the only no
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> dispatch1:
> %cs1 = catchswitch within none [label %handler0, label %handler1]
> unwind to caller
> @@ -5711,7 +5711,7 @@ the ``catchret``'s behavior is undefined
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> catchret from %catch label %continue
>
> @@ -5761,7 +5761,7 @@ It transfers control to ``continue`` or
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> cleanupret from %cleanup unwind to caller
> cleanupret from %cleanup unwind label %continue
> @@ -5851,7 +5851,7 @@ unsigned and/or signed overflow, respect
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = add i32 4, %var ; yields i32:result = 4 + %var
>
> @@ -5890,7 +5890,7 @@ optimizations:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = fadd float 4.0, %var ; yields float:result = 4.0
> + %var
>
> @@ -5942,7 +5942,7 @@ unsigned and/or signed overflow, respect
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = sub i32 4, %var ; yields i32:result = 4 - %var
> <result> = sub i32 0, %val ; yields i32:result = -%var
> @@ -5985,7 +5985,7 @@ unsafe floating point optimizations:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = fsub float 4.0, %var ; yields float:result =
> 4.0 - %var
> <result> = fsub float -0.0, %val ; yields float:result
> = -%var
> @@ -6039,7 +6039,7 @@ unsigned and/or signed overflow, respect
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = mul i32 4, %var ; yields i32:result = 4 * %var
>
> @@ -6078,7 +6078,7 @@ unsafe floating point optimizations:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = fmul float 4.0, %var ; yields float:result = 4.0
> * %var
>
> @@ -6122,7 +6122,7 @@ such, "((a udiv exact b) mul b) == a").
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = udiv i32 4, %var ; yields i32:result = 4 / %var
>
> @@ -6168,7 +6168,7 @@ a :ref:`poison value <poisonvalues>` if
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = sdiv i32 4, %var ; yields i32:result = 4 / %var
>
> @@ -6207,7 +6207,7 @@ unsafe floating point optimizations:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = fdiv float 4.0, %var ; yields float:result = 4.0
> / %var
>
> @@ -6249,7 +6249,7 @@ Taking the remainder of a division by ze
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = urem i32 4, %var ; yields i32:result = 4 % %var
>
> @@ -6304,7 +6304,7 @@ result of the division and the remainder
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = srem i32 4, %var ; yields i32:result = 4 % %var
>
> @@ -6344,7 +6344,7 @@ to enable otherwise unsafe floating poin
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = frem float 4.0, %var ; yields float:result = 4.0
> % %var
>
> @@ -6406,7 +6406,7 @@ nsw/nuw bits in (mul %op1, (shl 1, %op2)
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = shl i32 4, %var ; yields i32: 4 << %var
> <result> = shl i32 4, 2 ; yields i32: 16
> @@ -6455,7 +6455,7 @@ non-zero.
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = lshr i32 4, 1 ; yields i32:result = 2
> <result> = lshr i32 4, 2 ; yields i32:result = 1
> @@ -6506,7 +6506,7 @@ non-zero.
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = ashr i32 4, 1 ; yields i32:result = 2
> <result> = ashr i32 4, 2 ; yields i32:result = 1
> @@ -6558,7 +6558,7 @@ The truth table used for the '``and``' i
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = and i32 4, %var ; yields i32:result = 4 & %var
> <result> = and i32 15, 40 ; yields i32:result = 8
> @@ -6657,7 +6657,7 @@ The truth table used for the '``xor``' i
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = xor i32 4, %var ; yields i32:result = 4 ^ %var
> <result> = xor i32 15, 40 ; yields i32:result = 39
> @@ -6710,7 +6710,7 @@ exceeds the length of ``val``, the resul
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = extractelement <4 x i32> %vec, i32 0 ; yields i32
>
> @@ -6752,7 +6752,7 @@ undefined.
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4
> x i32>
>
> @@ -6800,7 +6800,7 @@ only one vector.
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
> <4 x i32> <i32 0, i32 4, i32 1, i32 5> ;
> yields <4 x i32>
> @@ -6859,7 +6859,7 @@ the index operands.
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = extractvalue {i32, float} %agg, 0 ; yields i32
>
> @@ -8126,7 +8126,7 @@ or :ref:`ptrtoint <i_ptrtoint>` instruct
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %X = bitcast i8 255 to i8 ; yields i8 :-1
> %Y = bitcast i32* %x to sint* ; yields sint*:%x
> @@ -8265,7 +8265,7 @@ as the values being compared. Otherwise,
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = icmp eq i32 4, 5 ; yields: result=false
> <result> = icmp ne float* %X, %X ; yields: result=false
> @@ -8379,7 +8379,7 @@ assumptions to be made about the values
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> <result> = fcmp oeq float 4.0, 5.0 ; yields: result=false
> <result> = fcmp one float 4.0, 5.0 ; yields: result=true
> @@ -8815,7 +8815,7 @@ that does not carry an appropriate :ref:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> dispatch:
> %cs = catchswitch within none [label %handler0] unwind to caller
> @@ -8885,7 +8885,7 @@ that does not carry an appropriate :ref:
> Example:
> """"""""
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %tok = cleanuppad within %cs []
>
> @@ -12481,19 +12481,19 @@ optimistic assumptions made during compi
> ``@llvm.experimental.deoptimize`` -- its body is defined to be
> equivalent to:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> - define void @llvm.experimental.guard(i1 %pred, <args...>) {
> - %realPred = and i1 %pred, undef
> - br i1 %realPred, label %continue, label %leave [, !make.implicit !{}]
> -
> - leave:
> - call void @llvm.experimental.deoptimize(<args...>) [ "deopt"() ]
> - ret void
> -
> - continue:
> - ret void
> - }
> + define void @llvm.experimental.guard(i1 %pred, <args...>) {
> + %realPred = and i1 %pred, undef
> + br i1 %realPred, label %continue, label %leave [, !make.implicit !{}]
> +
> + leave:
> + call void @llvm.experimental.deoptimize(<args...>) [ "deopt"() ]
> + ret void
> +
> + continue:
> + ret void
> + }
>
>
> with the optional ``[, !make.implicit !{}]`` present if and only if it
>
> Modified: llvm/trunk/docs/MIRLangRef.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/MIRLangRef.rst?rev=276109&r1=276108&r2=276109
> &view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/MIRLangRef.rst (original)
> +++ llvm/trunk/docs/MIRLangRef.rst Wed Jul 20 07:16:38 2016
> @@ -111,7 +111,6 @@ Here is an example of a YAML document th
>
> .. code-block:: llvm
>
> - --- |
> define i32 @inc(i32* %x) {
> entry:
> %0 = load i32, i32* %x
> @@ -119,7 +118,6 @@ Here is an example of a YAML document th
> store i32 %1, i32* %x
> ret i32 %1
> }
> - ...
>
> .. _YAML block literal string:
> http://www.yaml.org/spec/1.2/spec.html#id2795688
>
> @@ -129,7 +127,7 @@ Machine Functions
> The remaining YAML documents contain the machine functions. This is an
> example
> of such YAML document:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ---
> name: inc
> @@ -172,7 +170,7 @@ A machine basic block is defined in a si
> that contains the block's ID.
> The example below defines two blocks that have an ID of zero and one:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0:
> <instructions>
> @@ -182,7 +180,7 @@ The example below defines two blocks tha
> A machine basic block can also have a name. It should be specified after
> the
> ID
> in the block's definition:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0.entry: ; This block's name is "entry"
> <instructions>
> @@ -196,7 +194,7 @@ Block References
> The machine basic blocks are identified by their ID numbers. Individual
> blocks are referenced using the following syntax:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %bb.<id>[.<name>]
>
> @@ -213,7 +211,7 @@ Successors
> The machine basic block's successors have to be specified before any of the
> instructions:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0.entry:
> successors: %bb.1.then, %bb.2.else
> @@ -227,7 +225,7 @@ The branch weights can be specified in b
> The example below defines a block that has two successors with branch
> weights
> of 32 and 16:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0.entry:
> successors: %bb.1.then(32), %bb.2.else(16)
> @@ -240,7 +238,7 @@ Live In Registers
> The machine basic block's live in registers have to be specified before any
> of
> the instructions:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0.entry:
> liveins: %edi, %esi
> @@ -255,7 +253,7 @@ Miscellaneous Attributes
> The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can
> be
> specified in brackets after the block's definition:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> bb.0.entry (address-taken):
> <instructions>
> @@ -278,7 +276,7 @@ The instruction's name is usually specif
> below shows an instance of the X86 ``RETQ`` instruction with a single
> machine
> operand:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> RETQ %eax
>
> @@ -287,7 +285,7 @@ operands, the instruction's name has to
> below shows an instance of the AArch64 ``LDPXpost`` instruction with three
> defined register operands:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %sp, %fp, %lr = LDPXpost %sp, 2
>
> @@ -303,7 +301,7 @@ Instruction Flags
>
> The flag ``frame-setup`` can be specified before the instruction's name:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %fp = frame-setup ADDXri %sp, 0, 0
>
> @@ -321,13 +319,13 @@ but they can also be used in a number of
> The physical registers are identified by their name. They use the following
> syntax:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %<name>
>
> The example below shows three X86 physical registers:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %eax
> %r15
> @@ -336,13 +334,13 @@ The example below shows three X86 physic
> The virtual registers are identified by their ID number. They use the
> following
> syntax:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %<id>
>
> Example:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %0
>
> @@ -366,7 +364,7 @@ The immediate machine operands are untyp
> example below shows an instance of the X86 ``MOV32ri`` instruction that has
> an
> immediate machine operand ``-42``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %eax = MOV32ri -42
>
> @@ -384,14 +382,14 @@ machine operands. The register operands
> and a reference to the tied register operand.
> The full syntax of a register operand is shown below:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def
> <tied-op>) ]
>
> This example shows an instance of the X86 ``XOR32rr`` instruction that has
> 5 register operands with different register flags:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags,
> implicit-def %al
>
> @@ -446,7 +444,7 @@ the subregister indices. The example bel
> pseudo instruction that uses the X86 ``sub_8bit`` subregister index to copy
> 8
> lower bits from the 32-bit virtual register 0 to the 8-bit virtual register
> 1:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %1 = COPY %0:sub_8bit
>
> @@ -461,7 +459,7 @@ The global value machine operands refere
> The example below shows an instance of the X86 ``MOV64rm`` instruction
> that has
> a global value operand named ``G``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> %rax = MOV64rm %rip, 1, _, @G, _
>
>
> Modified: llvm/trunk/docs/MarkedUpDisassembly.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/MarkedUpDisassembly.rst?rev=276109&r1=276108
> &r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/MarkedUpDisassembly.rst (original)
> +++ llvm/trunk/docs/MarkedUpDisassembly.rst Wed Jul 20 07:16:38 2016
> @@ -70,7 +70,7 @@ clients.
> For example, a possible annotation of an ARM load of a stack-relative
> location
> might be annotated as:
>
> -.. code-block:: nasm
> +.. code-block:: text
>
> ldr <reg gpr:r0>, <mem regoffset:[<reg gpr:sp>, <imm:#4>]>
>
>
> Modified: llvm/trunk/docs/MergeFunctions.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/MergeFunctions.rst?rev=276109&r1=276108&r2=27
> 6109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/MergeFunctions.rst (original)
> +++ llvm/trunk/docs/MergeFunctions.rst Wed Jul 20 07:16:38 2016
> @@ -394,7 +394,7 @@ and in right function "*FR*". And every
> corresponding part of *right* place, and (!) both parts use *Value*
> instances,
> for example:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> instr0 i32 %LV ; left side, function FL
> instr0 i32 %RV ; right side, function FR
> @@ -409,13 +409,13 @@ in "*FL*" and "*FR*".
>
> Consider small example here:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void %f(i32 %pf0, i32 %pf1) {
> instr0 i32 %pf0 instr1 i32 %pf1 instr2 i32 123
> }
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void %g(i32 %pg0, i32 %pg1) {
> instr0 i32 %pg0 instr1 i32 %pg0 instr2 i32 123
>
> Modified: llvm/trunk/docs/NVPTXUsage.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/NVPTXUsage.rst?rev=276109&r1=276108&r2=27610
> 9&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/NVPTXUsage.rst (original)
> +++ llvm/trunk/docs/NVPTXUsage.rst Wed Jul 20 07:16:38 2016
> @@ -37,7 +37,7 @@ code. By default, the back-end will emit
> declare a function as a kernel function. This metadata is attached to the
> ``nvvm.annotations`` named metadata object, and has the following format:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !0 = !{<function-ref>, metadata !"kernel", i32 1}
>
>
> Modified: llvm/trunk/docs/SegmentedStacks.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/SegmentedStacks.rst?rev=276109&r1=276108&r2=2
> 76109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/SegmentedStacks.rst (original)
> +++ llvm/trunk/docs/SegmentedStacks.rst Wed Jul 20 07:16:38 2016
> @@ -33,7 +33,7 @@ current stack limit (minus the amount of
> this slot's offset is again dictated by ``libgcc``. The generated
> assembly looks like this on x86-64:
>
> -.. code-block:: nasm
> +.. code-block:: text
>
> leaq -8(%rsp), %r10
> cmpq %fs:112, %r10
>
> Modified: llvm/trunk/docs/SourceLevelDebugging.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/SourceLevelDebugging.rst?rev=276109&r1=276108
> &r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/SourceLevelDebugging.rst (original)
> +++ llvm/trunk/docs/SourceLevelDebugging.rst Wed Jul 20 07:16:38 2016
> @@ -230,7 +230,7 @@ following C fragment, for example:
>
> Compiled to LLVM, this function would be represented like this:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ; Function Attrs: nounwind ssp uwtable
> define void @foo() #0 !dbg !4 {
> @@ -303,7 +303,7 @@ The first intrinsic ``%llvm.dbg.declare`
> variable ``X``. The metadata ``!dbg !14`` attached to the intrinsic
> provides
> scope information for the variable ``X``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !14 = !DILocation(line: 2, column: 9, scope: !4)
> !4 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 1,
> type: !5,
> @@ -327,7 +327,7 @@ The third intrinsic ``%llvm.dbg.declare`
> variable ``Z``. The metadata ``!dbg !19`` attached to the intrinsic
> provides
> scope information for the variable ``Z``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> !18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 4, column: 5)
> !19 = !DILocation(line: 5, column: 11, scope: !18)
> @@ -390,7 +390,7 @@ Given an integer global variable declare
>
> a C/C++ front-end would generate the following descriptors:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ;;
> ;; Define the global itself.
> @@ -456,7 +456,7 @@ Given a function declared as follows:
>
> a C/C++ front-end would generate the following descriptors:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> ;;
> ;; Define the anchor for subprograms.
>
> Modified: llvm/trunk/docs/Statepoints.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/Statepoints.rst?rev=276109&r1=276108&r2=276109
> &view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/Statepoints.rst (original)
> +++ llvm/trunk/docs/Statepoints.rst Wed Jul 20 07:16:38 2016
> @@ -138,7 +138,7 @@ SSA value ``%obj.relocated`` which repre
> ``%obj`` after the safepoint and update any following uses appropriately.
> The
> resulting relocation sequence is:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
> gc "statepoint-example" {
> @@ -237,7 +237,7 @@ afterwards.
> If we extend our previous example to include a pointless derived pointer,
> we get:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
> gc "statepoint-example" {
> @@ -283,7 +283,7 @@ Let's assume a hypothetical GC--somewhat
> --that requires that a TLS variable must be written to before and after a
> call
> to unmanaged code. The resulting relocation sequence is:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> @flag = thread_local global i32 0, align 4
>
> @@ -662,7 +662,7 @@ distinguish between GC references and no
>
> As an example, given this code:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
> gc "statepoint-example" {
> @@ -672,7 +672,7 @@ As an example, given this code:
>
> The pass would produce this IR:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
> gc "statepoint-example" {
> @@ -737,7 +737,7 @@ As an example, given input IR of the fol
>
> This pass would produce the following IR:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> define void @test() gc "statepoint-example" {
> %safepoint_token = call token (i64, i32, void ()*, i32, i32, ...)*
> @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 2882400000, i32 0, void ()*
> @do_safepoint, i32 0, i32 0, i32 0, i32 0)
>
> Modified: llvm/trunk/docs/TableGen/LangIntro.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/TableGen/LangIntro.rst?rev=276109&r1=276108&r2
> =276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/TableGen/LangIntro.rst (original)
> +++ llvm/trunk/docs/TableGen/LangIntro.rst Wed Jul 20 07:16:38 2016
> @@ -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 ove
> 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 TableGe
> 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 provid
> 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 p
>
> 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, inst
> 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
> 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 d
> 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
> 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``' bloc
> 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``,
> 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<...>;
>
> Modified: llvm/trunk/docs/TableGen/index.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/TableGen/index.rst?rev=276109&r1=276108&r2=27
> 6109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/TableGen/index.rst (original)
> +++ llvm/trunk/docs/TableGen/index.rst Wed Jul 20 07:16:38 2016
> @@ -90,7 +90,7 @@ of the classes, then all of the definiti
> 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
> 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 b
> 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 mu
> 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> {
>
> Modified: llvm/trunk/docs/WritingAnLLVMBackend.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/WritingAnLLVMBackend.rst?rev=276109&r1=276108
> &r2=276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/WritingAnLLVMBackend.rst (original)
> +++ llvm/trunk/docs/WritingAnLLVMBackend.rst Wed Jul 20 07:16:38 2016
> @@ -345,7 +345,7 @@ to define an object for each register.
> ``Name`` of the register. The basic ``Register`` object does not have any
> subregisters and does not specify any aliases.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class Register<string n> {
> string Namespace = "";
> @@ -361,7 +361,7 @@ subregisters and does not specify any al
> For example, in the ``X86RegisterInfo.td`` file, there are register
> definitions
> that utilize the ``Register`` class, such as:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
>
> @@ -414,7 +414,7 @@ classes. In ``Target.td``, the ``Regist
> ``RegisterWithSubRegs`` class that is used to define registers that need to
> specify subregisters in the ``SubRegs`` list, as shown here:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n>
> {
> let SubRegs = subregs;
> @@ -427,7 +427,7 @@ feature common to these subclasses. Not
> override values that are initially defined in a superclass (such as
> ``SubRegs``
> field in the ``Rd`` class).
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class SparcReg<string n> : Register<n> {
> field bits<5> Num;
> @@ -452,7 +452,7 @@ field in the ``Rd`` class).
> In the ``SparcRegisterInfo.td`` file, there are register definitions that
> utilize these subclasses of ``Register``, such as:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>;
> def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
> @@ -478,7 +478,7 @@ default allocation order of the register
> ``XXXRegisterInfo.td`` that uses ``Target.td`` can construct register
> classes
> using the following class:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class RegisterClass<string namespace,
> list<ValueType> regTypes, int alignment, dag regList> {
> @@ -532,7 +532,7 @@ defines a group of 32 single-precision f
> ``F31``); ``DFPRegs`` defines a group of 16 double-precision registers
> (``D0-D15``).
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> // F0, F1, F2, ..., F31
> def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>;
> @@ -703,7 +703,7 @@ which describes one instruction. An ins
> The Instruction class (defined in ``Target.td``) is mostly used as a base
> for
> more complex instruction classes.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class Instruction {
> string Namespace = "";
> @@ -760,7 +760,7 @@ specific operation value for ``LD``/Load
> output destination, which is a register operand and defined in the
> ``Register``
> target description file (``IntRegs``).
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
> "ld [$addr], $dst",
> @@ -769,7 +769,7 @@ target description file (``IntRegs``).
> The fourth parameter is the input source, which uses the address operand
> ``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def MEMrr : Operand<i32> {
> let PrintMethod = "printMemOperand";
> @@ -788,7 +788,7 @@ immediate value operands. For example,
> for a Word from an immediate operand to a register, the following
> instruction
> class is defined:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
> "ld [$addr], $dst",
> @@ -801,7 +801,7 @@ creation of templates to define several
> pattern ``F3_12`` is defined to create 2 instruction classes each time
> ``F3_12`` is invoked:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
> def rr : F3_1 <2, Op3Val,
> @@ -818,7 +818,7 @@ So when the ``defm`` directive is used f
> instructions, as seen below, it creates four instruction objects:
> ``XORrr``,
> ``XORri``, ``ADDrr``, and ``ADDri``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> defm XOR : F3_12<"xor", 0b000011, xor>;
> defm ADD : F3_12<"add", 0b000000, add>;
> @@ -830,7 +830,7 @@ For example, the 10\ :sup:`th` bit repre
> integers, and the 22\ :sup:`nd` bit represents the "greater than" condition
> for
> floats.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def ICC_NE : ICC_VAL< 9>; // Not Equal
> def ICC_E : ICC_VAL< 1>; // Equal
> @@ -855,7 +855,7 @@ order they are defined. Fields are boun
> example, the Sparc target defines the ``XNORrr`` instruction as a ``F3_1``
> format instruction having three operands.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def XNORrr : F3_1<2, 0b000111,
> (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
> @@ -865,7 +865,7 @@ format instruction having three operands
> The instruction templates in ``SparcInstrFormats.td`` show the base class
> for
> ``F3_1`` is ``InstSP``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> :
> Instruction
> {
> field bits<32> Inst;
> @@ -880,7 +880,7 @@ The instruction templates in ``SparcInst
>
> ``InstSP`` leaves the ``op`` field unbound.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
> : InstSP<outs, ins, asmstr, pattern> {
> @@ -897,7 +897,7 @@ The instruction templates in ``SparcInst
> fields. ``F3`` format instructions will bind the operands ``rd``, ``op3``,
> and
> ``rs1`` fields.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
> string asmstr, list<dag> pattern> : F3<outs, ins, asmstr,
> pattern> {
> @@ -925,7 +925,7 @@ TableGen definition will add all of its
> llvm::XXX:OpName namespace and also add an entry for it into the
> OperandMap
> table, which can be queried using getNamedOperandIdx()
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); //
> => 0
> int BIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::b); //
> => 1
> @@ -972,7 +972,7 @@ For example, the X86 backend defines ``b
> instances of the TableGen ``Operand`` class, which represent branch target
> operands:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def brtarget : Operand<OtherVT>;
> def brtarget8 : Operand<OtherVT>;
> @@ -1222,14 +1222,14 @@ definitions in ``XXXInstrInfo.td``. For
> this entry defines a register store operation, and the last parameter
> describes
> a pattern with the store DAG operator.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
> "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>;
>
> ``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
>
> @@ -1240,7 +1240,7 @@ defined in an implementation of the Inst
> In ``lib/Target/TargetSelectionDAG.td``, the DAG operator for store is
> defined
> below:
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def store : PatFrag<(ops node:$val, node:$ptr),
> (st node:$val, node:$ptr), [{
> @@ -1458,7 +1458,7 @@ if the current argument is of type ``f32
> performed. In this case, the ``CCAssignToReg`` action assigns the argument
> value to the first available register: either ``R0`` or ``R1``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
>
> @@ -1469,7 +1469,7 @@ which registers are used for specified s
> float is returned to register ``F0``, and a double-precision float goes to
> register ``D0``. A 32-bit integer is returned in register ``I0`` or
> ``I1``.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def RetCC_Sparc32 : CallingConv<[
> CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
> @@ -1484,7 +1484,7 @@ the size of the slot, and the second par
> alignment along 4-byte units. (Special cases: if size is zero, then the
> ABI
> size is used; if alignment is zero, then the ABI alignment is used.)
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def CC_Sparc32 : CallingConv<[
> // All arguments get passed in integer registers if there is space.
> @@ -1499,7 +1499,7 @@ the following example (in ``X86CallingCo
> assigned to the register ``ST0`` or ``ST1``, the ``RetCC_X86Common`` is
> invoked.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def RetCC_X86_32_C : CallingConv<[
> CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
> @@ -1514,7 +1514,7 @@ then a specified action is invoked. In
> ``RetCC_X86_32_Fast`` is invoked. If the ``SSECall`` calling convention is
> in
> use, then ``RetCC_X86_32_SSE`` is invoked.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def RetCC_X86_32 : CallingConv<[
> CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
> @@ -1682,7 +1682,7 @@ feature, the value of the attribute, and
> fifth parameter is a list of features whose presence is implied, and its
> default value is an empty array.)
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class SubtargetFeature<string n, string a, string v, string d,
> list<SubtargetFeature> i = []> {
> @@ -1696,7 +1696,7 @@ default value is an empty array.)
> In the ``Sparc.td`` file, the ``SubtargetFeature`` is used to define the
> following features.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
> "Enable SPARC-V9 instructions">;
> @@ -1710,7 +1710,7 @@ Elsewhere in ``Sparc.td``, the ``Proc``
> define particular SPARC processor subtypes that may have the previously
> described features.
>
> -.. code-block:: llvm
> +.. code-block:: text
>
> class Proc<string Name, list<SubtargetFeature> Features>
> : Processor<Name, NoItineraries, Features>;
>
> Modified: llvm/trunk/docs/WritingAnLLVMPass.rst
> URL: http://llvm.org/viewvc/llvm-
> project/llvm/trunk/docs/WritingAnLLVMPass.rst?rev=276109&r1=276108&r2
> =276109&view=diff
> ==========================================================
> ====================
> --- llvm/trunk/docs/WritingAnLLVMPass.rst (original)
> +++ llvm/trunk/docs/WritingAnLLVMPass.rst Wed Jul 20 07:16:38 2016
> @@ -747,7 +747,7 @@ template parameter is the name of the pa
> line to specify that the pass should be added to a program (for example,
> with
> :program:`opt` or :program:`bugpoint`). The first argument is the name of
> the
> pass, which is to be used for the :option:`-help` output of programs, as
> well
> -as for debug output generated by the :option:`--debug-pass` option.
> +as for debug output generated by the `--debug-pass` option.
>
> If you want your pass to be easily dumpable, you should implement the
> virtual
> print method:
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5868 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160720/15df9197/attachment.bin>
More information about the llvm-commits
mailing list