From dfb328c43734dd3e1a10c4dc7db2fb2d9e232068 Mon Sep 17 00:00:00 2001 From: Renato Golin Date: Wed, 20 Jul 2016 12:16:38 +0000 Subject: [PATCH] [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 --- docs/CodeGenerator.rst | 6 +- docs/CommandGuide/FileCheck.rst | 8 +- docs/CommandGuide/llvm-nm.rst | 4 +- docs/CommandGuide/opt.rst | 12 +-- docs/ExceptionHandling.rst | 8 +- docs/Extensions.rst | 2 +- docs/GarbageCollection.rst | 2 +- docs/GetElementPtr.rst | 10 +-- docs/HowToUseInstrMappings.rst | 8 +- docs/InAlloca.rst | 2 +- docs/LangRef.rst | 126 ++++++++++++++++---------------- docs/MIRLangRef.rst | 42 +++++------ docs/MarkedUpDisassembly.rst | 2 +- docs/MergeFunctions.rst | 6 +- docs/NVPTXUsage.rst | 2 +- docs/SegmentedStacks.rst | 2 +- docs/SourceLevelDebugging.rst | 10 +-- docs/Statepoints.rst | 12 +-- docs/TableGen/LangIntro.rst | 28 +++---- docs/TableGen/index.rst | 10 +-- docs/WritingAnLLVMBackend.rst | 62 ++++++++-------- docs/WritingAnLLVMPass.rst | 2 +- 22 files changed, 182 insertions(+), 184 deletions(-) diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst index 6a54343dfba..2f5a27c00af 100644 --- a/docs/CodeGenerator.rst +++ b/docs/CodeGenerator.rst @@ -436,7 +436,7 @@ For example, consider this simple LLVM example: 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 register allocator would coalesce the 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 following LLVM fragment: 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) diff --git a/docs/CommandGuide/FileCheck.rst b/docs/CommandGuide/FileCheck.rst index a0ca1bfe52f..413b6f41b0c 100644 --- a/docs/CommandGuide/FileCheck.rst +++ b/docs/CommandGuide/FileCheck.rst @@ -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 match `after` its use. 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 pass: 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 expressions the character class 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") diff --git a/docs/CommandGuide/llvm-nm.rst b/docs/CommandGuide/llvm-nm.rst index f666e1c35e3..319e6e6aecf 100644 --- a/docs/CommandGuide/llvm-nm.rst +++ b/docs/CommandGuide/llvm-nm.rst @@ -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 diff --git a/docs/CommandGuide/opt.rst b/docs/CommandGuide/opt.rst index 3a050f7d815..7b9255d2642 100644 --- a/docs/CommandGuide/opt.rst +++ b/docs/CommandGuide/opt.rst @@ -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. diff --git a/docs/ExceptionHandling.rst b/docs/ExceptionHandling.rst index 41dd4b606b1..a44fb92794c 100644 --- a/docs/ExceptionHandling.rst +++ b/docs/ExceptionHandling.rst @@ -406,7 +406,7 @@ outlined. After the handler is outlined, this intrinsic is simply removed. ``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 the backend's ``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: diff --git a/docs/Extensions.rst b/docs/Extensions.rst index c8ff07c2b0c..f7029215c19 100644 --- a/docs/Extensions.rst +++ b/docs/Extensions.rst @@ -43,7 +43,7 @@ The following additional relocation types are supported: 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: diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst index 56b4b9f8f95..81605bc2095 100644 --- a/docs/GarbageCollection.rst +++ b/docs/GarbageCollection.rst @@ -204,7 +204,7 @@ IR features is specified by the selected :ref:`GC strategy description Specifying GC code generation: ``gc "..."`` ------------------------------------------- -.. code-block:: llvm +.. code-block:: text define @name(...) gc "name" { ... } diff --git a/docs/GetElementPtr.rst b/docs/GetElementPtr.rst index c9cfae64ace..f39f1d9207a 100644 --- a/docs/GetElementPtr.rst +++ b/docs/GetElementPtr.rst @@ -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 indices. 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 dereferences nothing. That is, it doesn't access 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 ] } ... diff --git a/docs/HowToUseInstrMappings.rst b/docs/HowToUseInstrMappings.rst index 8a3e7c8d726..1c586b4bada 100644 --- a/docs/HowToUseInstrMappings.rst +++ b/docs/HowToUseInstrMappings.rst @@ -30,7 +30,7 @@ instructions with each other. These tables are emitted in the ``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 appropriate values to the ``InstrMapping`` 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 definition. For example, consider 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 instructions to include the information required by the relationship model, getPredOpcode, 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)", diff --git a/docs/InAlloca.rst b/docs/InAlloca.rst index c7609cddb4f..a75f22da796 100644 --- a/docs/InAlloca.rst +++ b/docs/InAlloca.rst @@ -41,7 +41,7 @@ that passes two default-constructed ``Foo`` objects to ``g`` in the g(Foo(), Foo()); } -.. code-block:: llvm +.. code-block:: text %struct.Foo = type { i32, i32 } declare void @Foo_ctor(%struct.Foo* %this) diff --git a/docs/LangRef.rst b/docs/LangRef.rst index f6dda59fda2..ce15c47111c 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -839,7 +839,7 @@ Note that the Mach-O platform doesn't support COMDATs and ELF only supports 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 table. 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 highly target dependent. 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 encoding a relative branch instruction 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 name. 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`` example, the optimizer is 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 to delete the divide and all 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 info to be emitted along with the compile 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 the return type, while the rest are the 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`` set. LLVM tools that link modules 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 that does not set ``flags: DIFwdDecl``, 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, then this variable is a subprogram 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 limited: - ``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 identifier, followed by macro parameters when 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 non-phi instruction in the block. 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 unwinds out of the function. 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, respectively, occurs. Example: """""""" -.. code-block:: llvm +.. code-block:: text = add i32 4, %var ; yields i32:result = 4 + %var @@ -5890,7 +5890,7 @@ optimizations: Example: """""""" -.. code-block:: llvm +.. code-block:: text = fadd float 4.0, %var ; yields float:result = 4.0 + %var @@ -5942,7 +5942,7 @@ unsigned and/or signed overflow, respectively, occurs. Example: """""""" -.. code-block:: llvm +.. code-block:: text = sub i32 4, %var ; yields i32:result = 4 - %var = sub i32 0, %val ; yields i32:result = -%var @@ -5985,7 +5985,7 @@ unsafe floating point optimizations: Example: """""""" -.. code-block:: llvm +.. code-block:: text = fsub float 4.0, %var ; yields float:result = 4.0 - %var = fsub float -0.0, %val ; yields float:result = -%var @@ -6039,7 +6039,7 @@ unsigned and/or signed overflow, respectively, occurs. Example: """""""" -.. code-block:: llvm +.. code-block:: text = mul i32 4, %var ; yields i32:result = 4 * %var @@ -6078,7 +6078,7 @@ unsafe floating point optimizations: Example: """""""" -.. code-block:: llvm +.. code-block:: text = 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 = udiv i32 4, %var ; yields i32:result = 4 / %var @@ -6168,7 +6168,7 @@ a :ref:`poison value ` if the result would be rounded. Example: """""""" -.. code-block:: llvm +.. code-block:: text = sdiv i32 4, %var ; yields i32:result = 4 / %var @@ -6207,7 +6207,7 @@ unsafe floating point optimizations: Example: """""""" -.. code-block:: llvm +.. code-block:: text = fdiv float 4.0, %var ; yields float:result = 4.0 / %var @@ -6249,7 +6249,7 @@ Taking the remainder of a division by zero leads to undefined behavior. Example: """""""" -.. code-block:: llvm +.. code-block:: text = 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 = srem i32 4, %var ; yields i32:result = 4 % %var @@ -6344,7 +6344,7 @@ to enable otherwise unsafe floating point optimizations: Example: """""""" -.. code-block:: llvm +.. code-block:: text = 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 = shl i32 4, %var ; yields i32: 4 << %var = shl i32 4, 2 ; yields i32: 16 @@ -6455,7 +6455,7 @@ non-zero. Example: """""""" -.. code-block:: llvm +.. code-block:: text = lshr i32 4, 1 ; yields i32:result = 2 = lshr i32 4, 2 ; yields i32:result = 1 @@ -6506,7 +6506,7 @@ non-zero. Example: """""""" -.. code-block:: llvm +.. code-block:: text = ashr i32 4, 1 ; yields i32:result = 2 = ashr i32 4, 2 ; yields i32:result = 1 @@ -6558,7 +6558,7 @@ The truth table used for the '``and``' instruction is: Example: """""""" -.. code-block:: llvm +.. code-block:: text = and i32 4, %var ; yields i32:result = 4 & %var = and i32 15, 40 ; yields i32:result = 8 @@ -6657,7 +6657,7 @@ The truth table used for the '``xor``' instruction is: Example: """""""" -.. code-block:: llvm +.. code-block:: text = xor i32 4, %var ; yields i32:result = 4 ^ %var = xor i32 15, 40 ; yields i32:result = 39 @@ -6710,7 +6710,7 @@ exceeds the length of ``val``, the results are undefined. Example: """""""" -.. code-block:: llvm +.. code-block:: text = extractelement <4 x i32> %vec, i32 0 ; yields i32 @@ -6752,7 +6752,7 @@ undefined. Example: """""""" -.. code-block:: llvm +.. code-block:: text = 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 = shufflevector <4 x i32> %v1, <4 x i32> %v2, <4 x i32> ; yields <4 x i32> @@ -6859,7 +6859,7 @@ the index operands. Example: """""""" -.. code-block:: llvm +.. code-block:: text = extractvalue {i32, float} %agg, 0 ; yields i32 @@ -8126,7 +8126,7 @@ or :ref:`ptrtoint ` instructions first. 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, the result is an ``i1``. Example: """""""" -.. code-block:: llvm +.. code-block:: text = icmp eq i32 4, 5 ; yields: result=false = icmp ne float* %X, %X ; yields: result=false @@ -8379,7 +8379,7 @@ assumptions to be made about the values of input arguments; namely Example: """""""" -.. code-block:: llvm +.. code-block:: text = fcmp oeq float 4.0, 5.0 ; yields: result=false = fcmp one float 4.0, 5.0 ; yields: result=true @@ -8815,7 +8815,7 @@ that does not carry an appropriate :ref:`"funclet" bundle `. 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:`"funclet" bundle `. Example: """""""" -.. code-block:: llvm +.. code-block:: text %tok = cleanuppad within %cs [] @@ -12481,19 +12481,19 @@ optimistic assumptions made during compilation. The semantics of ``@llvm.experimental.deoptimize`` -- its body is defined to be equivalent to: -.. code-block:: llvm +.. code-block:: text - define void @llvm.experimental.guard(i1 %pred, ) { - %realPred = and i1 %pred, undef - br i1 %realPred, label %continue, label %leave [, !make.implicit !{}] + define void @llvm.experimental.guard(i1 %pred, ) { + %realPred = and i1 %pred, undef + br i1 %realPred, label %continue, label %leave [, !make.implicit !{}] - leave: - call void @llvm.experimental.deoptimize() [ "deopt"() ] - ret void + leave: + call void @llvm.experimental.deoptimize() [ "deopt"() ] + ret void - continue: - ret void - } + continue: + ret void + } with the optional ``[, !make.implicit !{}]`` present if and only if it diff --git a/docs/MIRLangRef.rst b/docs/MIRLangRef.rst index a5f8c8c743a..f6ee6ccd050 100644 --- a/docs/MIRLangRef.rst +++ b/docs/MIRLangRef.rst @@ -111,7 +111,6 @@ Here is an example of a YAML document that contains an LLVM module: .. 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 that contains an LLVM module: 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 single block definition source construct 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: @@ -182,7 +180,7 @@ The example below defines two blocks that have an ID of zero and one: 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" @@ -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.[.] @@ -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 brackets after the successor blocks. 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): @@ -278,7 +276,7 @@ The instruction's name is usually specified before the operands. The example 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 be specified after them. The example 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 other places, like the The physical registers are identified by their name. They use the following syntax: -.. code-block:: llvm +.. code-block:: text % 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 physical registers: The virtual registers are identified by their ID number. They use the following syntax: -.. code-block:: llvm +.. code-block:: text % Example: -.. code-block:: llvm +.. code-block:: text %0 @@ -366,7 +364,7 @@ The immediate machine operands are untyped, 64-bit signed integers. The 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 can also have optional and a reference to the tied register operand. The full syntax of a register operand is shown below: -.. code-block:: llvm +.. code-block:: text [] [ : ] [ (tied-def ) ] 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 below shows an instance of the ``COPY`` 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 reference the global values from the 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, _ diff --git a/docs/MarkedUpDisassembly.rst b/docs/MarkedUpDisassembly.rst index cc4dbc817e0..df8befe45cd 100644 --- a/docs/MarkedUpDisassembly.rst +++ b/docs/MarkedUpDisassembly.rst @@ -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 , , ]> diff --git a/docs/MergeFunctions.rst b/docs/MergeFunctions.rst index f808010f3ac..b87cea68ba5 100644 --- a/docs/MergeFunctions.rst +++ b/docs/MergeFunctions.rst @@ -394,7 +394,7 @@ and in right function "*FR*". And every part of *left* place is equal to the 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 diff --git a/docs/NVPTXUsage.rst b/docs/NVPTXUsage.rst index 8b8c40f1fd7..fdfc8e41dc3 100644 --- a/docs/NVPTXUsage.rst +++ b/docs/NVPTXUsage.rst @@ -37,7 +37,7 @@ code. By default, the back-end will emit device functions. Metadata is used to 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 = !{, metadata !"kernel", i32 1} diff --git a/docs/SegmentedStacks.rst b/docs/SegmentedStacks.rst index c0bf32b3f92..b1c588cb163 100644 --- a/docs/SegmentedStacks.rst +++ b/docs/SegmentedStacks.rst @@ -33,7 +33,7 @@ current stack limit (minus the amount of space needed to allocate a new block) - 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 diff --git a/docs/SourceLevelDebugging.rst b/docs/SourceLevelDebugging.rst index 1815ee398e0..8c3142ed219 100644 --- a/docs/SourceLevelDebugging.rst +++ b/docs/SourceLevelDebugging.rst @@ -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`` encodes debugging information for the 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`` encodes debugging information for 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 declared as follows: 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. diff --git a/docs/Statepoints.rst b/docs/Statepoints.rst index a78ab3c2170..29b1be37a89 100644 --- a/docs/Statepoints.rst +++ b/docs/Statepoints.rst @@ -138,7 +138,7 @@ SSA value ``%obj.relocated`` which represents the potentially changed value of ``%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 unimaginatively named "hypothetical-gc" --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 non-GC references in IR it is given. 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 following: 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) diff --git a/docs/TableGen/LangIntro.rst b/docs/TableGen/LangIntro.rst index a148634e3ed..c1391e73646 100644 --- a/docs/TableGen/LangIntro.rst +++ b/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 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 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 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 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/docs/TableGen/index.rst b/docs/TableGen/index.rst index 9526240d54f..5ba555ac2d2 100644 --- a/docs/TableGen/index.rst +++ b/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 Features> : Processor; @@ -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 { diff --git a/docs/WritingAnLLVMBackend.rst b/docs/WritingAnLLVMBackend.rst index 023f6ffc460..f0f3ab5504d 100644 --- a/docs/WritingAnLLVMBackend.rst +++ b/docs/WritingAnLLVMBackend.rst @@ -345,7 +345,7 @@ to define an object for each register. The specified string ``n`` becomes the ``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 Namespace = ""; @@ -361,7 +361,7 @@ subregisters and does not specify any aliases. 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 ``Register`` class is the base for the ``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 subregs> : Register { let SubRegs = subregs; @@ -427,7 +427,7 @@ feature common to these subclasses. Note the use of "``let``" expressions to 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 : Register { 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 registers. A target description file ``XXXRegisterInfo.td`` that uses ``Target.td`` can construct register classes using the following class: -.. code-block:: llvm +.. code-block:: text class RegisterClass regTypes, int alignment, dag regList> { @@ -532,7 +532,7 @@ defines a group of 32 single-precision floating-point registers (``F0`` to ``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 instruction descriptor defines: 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 Word. The third parameter is the 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 { let PrintMethod = "printMemOperand"; @@ -788,7 +788,7 @@ immediate value operands. For example, to perform a Load Integer instruction 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 instruction classes at once (using the 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 Op3Val, SDNode OpNode> { def rr : F3_1 <2, Op3Val, @@ -818,7 +818,7 @@ So when the ``defm`` directive is used for the ``XOR`` and ``ADD`` 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 represents the "greater than" condition for 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 bound when they are assigned a value. For 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 pattern> : Instruction { field bits<32> Inst; @@ -880,7 +880,7 @@ The instruction templates in ``SparcInstrFormats.td`` show the base class for ``InstSP`` leaves the ``op`` field unbound. -.. code-block:: llvm +.. code-block:: text class F3 pattern> : InstSP { @@ -897,7 +897,7 @@ The instruction templates in ``SparcInstrFormats.td`` show the base class for fields. ``F3`` format instructions will bind the operands ``rd``, ``op3``, and ``rs1`` fields. -.. code-block:: llvm +.. code-block:: text class F3_1 opVal, bits<6> op3val, dag outs, dag ins, string asmstr, list pattern> : F3 { @@ -925,7 +925,7 @@ TableGen definition will add all of its operands to an enumeration in the 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 ``brtarget`` and ``brtarget8``, both instances of the TableGen ``Operand`` class, which represent branch target operands: -.. code-block:: llvm +.. code-block:: text def brtarget : Operand; def brtarget8 : Operand; @@ -1222,14 +1222,14 @@ definitions in ``XXXInstrInfo.td``. For example, in ``SparcInstrInfo.td``, 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; @@ -1240,7 +1240,7 @@ defined in an implementation of the Instructor Selector (such as 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`` or ``f64``), then the action is 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 scalar return types. A single-precision 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 parameter, also 4, indicates the stack 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 ``X86CallingConv.td``), the definition of 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 the following example (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>, @@ -1682,7 +1682,7 @@ feature, the value of the attribute, and a description of the feature. (The 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 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`` class is defined and then is used to define particular SPARC processor subtypes that may have the previously described features. -.. code-block:: llvm +.. code-block:: text class Proc Features> : Processor; diff --git a/docs/WritingAnLLVMPass.rst b/docs/WritingAnLLVMPass.rst index 9e9d9f1703a..537bbbc19d2 100644 --- a/docs/WritingAnLLVMPass.rst +++ b/docs/WritingAnLLVMPass.rst @@ -747,7 +747,7 @@ template parameter is the name of the pass that is to be used on the command 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: