RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 12:12:47 +01:00
Code Issues Projects Releases Wiki Activity

[docs] Fixing Sphinx warnings to unclog the buildbot

Browse Source 
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
This commit is contained in:
Renato Golin 2016-07-20 12:16:38 +00:00
parent 1dc4aabfd0
commit dfb328c437
22 changed files with 182 additions and 184 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/CodeGenerator.rst
View File

@ -436,7 +436,7 @@ For example, consider this simple LLVM example:
The X86 instruction selector might produce this machine code for the ``div`` and The X86 instruction selector might produce this machine code for the ``div`` and
``ret``: ``ret``:
.. code-block:: llvm .. code-block:: text
;; Start of div ;; Start of div
%EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX %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 registers and delete the resultant identity moves producing the following
code: code:
.. code-block:: llvm .. code-block:: text
;; X is in EAX, Y is in ECX ;; X is in EAX, Y is in ECX
mov %EAX, %EDX 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: 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) (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)

8
docs/CommandGuide/FileCheck.rst
View File

@ -144,7 +144,7 @@ exists anywhere in the file.
The FileCheck -check-prefix option 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 configurations to be driven from one `.ll` file. This is useful in many
circumstances, for example, testing different architectural variants with circumstances, for example, testing different architectural variants with
:program:`llc`. Here's a simple example: :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: 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:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1] ; CHECK-DAG: vmov.32 [[REG2]][1]
@ -312,7 +312,7 @@ So, for instance, the code below will pass:
While this other code, will not: 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:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1] ; 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): matches output of the form (from llvm-dwarfdump):
.. code-block:: llvm .. code-block:: text
DW_AT_location [DW_FORM_sec_offset] (0x00000233) DW_AT_location [DW_FORM_sec_offset] (0x00000233)
DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd") DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd")

4
docs/CommandGuide/llvm-nm.rst
View File

@ -68,11 +68,11 @@ OPTIONS
.. option:: -B (default) .. option:: -B (default)
Use BSD output format. Alias for :option:`--format=bsd`. Use BSD output format. Alias for `--format=bsd`.
.. option:: -P .. 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 .. option:: --debug-syms, -a

12
docs/CommandGuide/opt.rst
View File

@ -12,16 +12,16 @@ DESCRIPTION
The :program:`opt` command is the modular LLVM optimizer and analyzer. It The :program:`opt` command is the modular LLVM optimizer and analyzer. It
takes LLVM source files as input, runs the specified optimizations or analyses 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 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. 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 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 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 the analysis output, which is usually done when the output is meant for another
program. 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 optimized output file. The optimizations available via :program:`opt` depend
upon what libraries were linked into it as well as any additional libraries 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` that have been loaded with the :option:`-load` option. Use the :option:`-help`
@ -68,19 +68,19 @@ OPTIONS
.. option:: -disable-opt .. 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. disables most passes.
.. option:: -strip-debug .. option:: -strip-debug
This option causes opt to strip debug information from the module before 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. but it ensures that stripping of debug information is done first.
.. option:: -verify-each .. option:: -verify-each
This option causes opt to add a verify pass after every pass otherwise 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 for cases where it is suspected that a pass is creating an invalid module but
it is not clear which pass is doing it. it is not clear which pass is doing it.

8
docs/ExceptionHandling.rst
View File

@ -406,7 +406,7 @@ outlined. After the handler is outlined, this intrinsic is simply removed.
``llvm.eh.exceptionpointer`` ``llvm.eh.exceptionpointer``
---------------------------- ----------------------------
.. code-block:: llvm .. code-block:: text
i8 addrspace(N)* @llvm.eh.padparam.pNi8(token %catchpad) 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`` ``llvm.eh.sjlj.setjmp``
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
.. code-block:: llvm .. code-block:: text
i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf) i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
@ -664,7 +664,7 @@ all of the new IR instructions:
return 0; return 0;
} }
.. code-block:: llvm .. code-block:: text
define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 { define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 {
entry: entry:
@ -741,7 +741,7 @@ C++ code:
} }
} }
.. code-block:: llvm .. code-block:: text
define void @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) { define void @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) {
entry: entry:

2
docs/Extensions.rst
View File

@ -43,7 +43,7 @@ The following additional relocation types are supported:
corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or
``IMAGE_REL_AMD64_ADDR32NB`` (64-bit). ``IMAGE_REL_AMD64_ADDR32NB`` (64-bit).
.. code-block:: gas .. code-block:: text
.text .text
fun: fun:

2
docs/GarbageCollection.rst
View File

@ -204,7 +204,7 @@ IR features is specified by the selected :ref:`GC strategy description
Specifying GC code generation: ``gc "..."`` Specifying GC code generation: ``gc "..."``
------------------------------------------- -------------------------------------------
.. code-block:: llvm .. code-block:: text
define <returntype> @name(...) gc "name" { ... } define <returntype> @name(...) gc "name" { ... }

10
docs/GetElementPtr.rst
View File

@ -105,7 +105,7 @@ memory, or a global variable.
To make this clear, let's consider a more obtuse example: To make this clear, let's consider a more obtuse example:
.. code-block:: llvm .. code-block:: text
%MyVar = uninitialized global i32 %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 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: variable which is always a pointer type. For example, consider this:
.. code-block:: llvm .. code-block:: text
%MyStruct = uninitialized global { float*, i32 } %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 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: only involved in the computation of addresses. For example, consider this:
.. code-block:: llvm .. code-block:: text
%MyVar = uninitialized global { [40 x i32 ]* } %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 In order to access the 18th integer in the array, you would need to do the
following: following:
.. code-block:: llvm .. code-block:: text
%idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0 %idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0
%arr = load [40 x i32]** %idx %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 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: 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 ] } %MyVar = uninitialized global { [40 x i32 ] }
... ...

8
docs/HowToUseInstrMappings.rst
View File

@ -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 ``XXXInstrInfo.inc`` file along with the functions to query them. Following
is the definition of ``InstrMapping`` class definied in Target.td file: is the definition of ``InstrMapping`` class definied in Target.td file:
.. code-block:: llvm .. code-block:: text
class InstrMapping { class InstrMapping {
// Used to reduce search space only to the instructions using this // 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 fields. For this relationship, non-predicated instructions are treated as key
instruction since they are the one used to query the interface function. instruction since they are the one used to query the interface function.
.. code-block:: llvm .. code-block:: text
def getPredOpcode : InstrMapping { def getPredOpcode : InstrMapping {
// Choose a FilterClass that is used as a base class for all the // 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) following to be the current definitions of ADD, ADD_pt (true) and ADD_pf (false)
instructions: instructions:
.. code-block:: llvm .. code-block:: text
def ADD : ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b), def ADD : ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
"$dst = add($a, $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, <tt>getPredOpcode</tt>, so that they can required by the relationship model, <tt>getPredOpcode</tt>, so that they can
be related. be related.
.. code-block:: llvm .. code-block:: text
def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b), def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
"$dst = add($a, $b)", "$dst = add($a, $b)",

2
docs/InAlloca.rst
View File

@ -41,7 +41,7 @@ that passes two default-constructed ``Foo`` objects to ``g`` in the
g(Foo(), Foo()); g(Foo(), Foo());
} }
.. code-block:: llvm .. code-block:: text
%struct.Foo = type { i32, i32 } %struct.Foo = type { i32, i32 }
declare void @Foo_ctor(%struct.Foo* %this) declare void @Foo_ctor(%struct.Foo* %this)

108
docs/LangRef.rst
View File

@ -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 Here is an example of a COMDAT group where a function will only be selected if
the COMDAT key's section is the largest: the COMDAT key's section is the largest:
.. code-block:: llvm .. code-block:: text
$foo = comdat largest $foo = comdat largest
@foo = global i32 2, comdat($foo) @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 As a syntactic sugar the ``$name`` can be omitted if the name is the same as
the global name: the global name:
.. code-block:: llvm .. code-block:: text
$foo = comdat any $foo = comdat any
@foo = global i32 2, comdat @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. The combined use of COMDATS and section attributes may yield surprising results.
For example: For example:
.. code-block:: llvm .. code-block:: text
$foo = comdat any $foo = comdat any
$bar = 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``, A trivial example of valid prologue data for the x86 architecture is ``i8 144``,
which encodes the ``nop`` instruction: which encodes the ``nop`` instruction:
.. code-block:: llvm .. code-block:: text
define void @f() prologue i8 144 { ... } 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 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``: x86_64 architecture, where the first two bytes encode ``jmp .+10``:
.. code-block:: llvm .. code-block:: text
%0 = type <{ i8, i8, i8* }> %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: The syntax for the source file name is simply:
.. code-block:: llvm .. code-block:: text
source_filename = "/path/to/source.c" 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 allowed to assume that the '``undef``' operand could be the same as
``%Y``, allowing the whole '``select``' to be eliminated. ``%Y``, allowing the whole '``select``' to be eliminated.
.. code-block:: llvm .. code-block:: text
%A = xor undef, undef %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 code after it. Because the undefined operation "can't happen", the
optimizer can assume that it occurs in dead code. optimizer can assume that it occurs in dead code.
.. code-block:: llvm .. code-block:: text
a: store undef -> %X a: store undef -> %X
b: store %X -> undef b: store %X -> undef
@ -3884,7 +3884,7 @@ their operand. For example:
Metadata nodes that aren't uniqued use the ``distinct`` keyword. 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} !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 unit, regardless of code optimizations (some nodes are only emitted if there are
references to them from instructions). references to them from instructions).
.. code-block:: llvm .. code-block:: text
!0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang", !0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang",
isOptimized: true, flags: "-O2", runtimeVersion: 2, isOptimized: true, flags: "-O2", runtimeVersion: 2,
@ -3985,7 +3985,7 @@ DIBasicType
``DIBasicType`` nodes represent primitive types, such as ``int``, ``bool`` and ``DIBasicType`` nodes represent primitive types, such as ``int``, ``bool`` and
``float``. ``tag:`` defaults to ``DW_TAG_base_type``. ``float``. ``tag:`` defaults to ``DW_TAG_base_type``.
.. code-block:: llvm .. code-block:: text
!0 = !DIBasicType(name: "unsigned char", size: 8, align: 8, !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
encoding: DW_ATE_unsigned_char) encoding: DW_ATE_unsigned_char)
@ -3994,7 +3994,7 @@ DIBasicType
The ``encoding:`` describes the details of the type. Usually it's one of the The ``encoding:`` describes the details of the type. Usually it's one of the
following: following:
.. code-block:: llvm .. code-block:: text
DW_ATE_address = 1 DW_ATE_address = 1
DW_ATE_boolean = 2 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 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++). 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) !0 = !BasicType(name: "int", size: 32, align: 32, DW_ATE_signed)
!1 = !BasicType(name: "char", size: 8, align: 8, DW_ATE_signed_char) !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 ``DIDerivedType`` nodes represent types derived from other types, such as
qualified types. qualified types.
.. code-block:: llvm .. code-block:: text
!0 = !DIBasicType(name: "unsigned char", size: 8, align: 8, !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
encoding: DW_ATE_unsigned_char) encoding: DW_ATE_unsigned_char)
@ -4037,7 +4037,7 @@ qualified types.
The following ``tag:`` values are valid: The following ``tag:`` values are valid:
.. code-block:: llvm .. code-block:: text
DW_TAG_member = 13 DW_TAG_member = 13
DW_TAG_pointer_type = 15 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:`` together will unique such definitions at parse time via the ``identifier:``
field, even if the nodes are ``distinct``. field, even if the nodes are ``distinct``.
.. code-block:: llvm .. code-block:: text
!0 = !DIEnumerator(name: "SixKind", value: 7) !0 = !DIEnumerator(name: "SixKind", value: 7)
!1 = !DIEnumerator(name: "SevenKind", 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: The following ``tag:`` values are valid:
.. code-block:: llvm .. code-block:: text
DW_TAG_array_type = 1 DW_TAG_array_type = 1
DW_TAG_class_type = 2 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:`` then the subprogram declaration is uniqued based only on its ``linkageName:``
and ``scope:``. and ``scope:``.
.. code-block:: llvm .. code-block:: text
define void @_Z3foov() !dbg !0 { define void @_Z3foov() !dbg !0 {
... ...
@ -4244,7 +4244,7 @@ DILexicalBlock
two lexical blocks at same depth. They are valid targets for ``scope:`` two lexical blocks at same depth. They are valid targets for ``scope:``
fields. fields.
.. code-block:: llvm .. code-block:: text
!0 = distinct !DILexicalBlock(scope: !1, file: !2, line: 7, column: 35) !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 parameter, and it will be included in the ``variables:`` field of its
:ref:`DISubprogram`. :ref:`DISubprogram`.
.. code-block:: llvm .. code-block:: text
!0 = !DILocalVariable(name: "this", arg: 1, scope: !3, file: !2, line: 7, !0 = !DILocalVariable(name: "this", arg: 1, scope: !3, file: !2, line: 7,
type: !3, flags: DIFlagArtificial) 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`` - ``DW_OP_bit_piece, 16, 8`` specifies the offset and size (``16`` and ``8``
here, respectively) of the variable piece from the working expression. here, respectively) of the variable piece from the working expression.
.. code-block:: llvm .. code-block:: text
!0 = !DIExpression(DW_OP_deref) !0 = !DIExpression(DW_OP_deref)
!1 = !DIExpression(DW_OP_plus, 3) !1 = !DIExpression(DW_OP_plus, 3)
@ -4336,7 +4336,7 @@ DIImportedEntity
``DIImportedEntity`` nodes represent entities (such as modules) imported into a ``DIImportedEntity`` nodes represent entities (such as modules) imported into a
compile unit. compile unit.
.. code-block:: llvm .. code-block:: text
!2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0, !2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0,
entity: !1, line: 7) 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 defining a function-like macro, and the ``value`` field is the token-string
used to expand the macro identifier. used to expand the macro identifier.
.. code-block:: llvm .. code-block:: text
!2 = !DIMacro(macinfo: DW_MACINFO_define, line: 7, name: "foo(x)", !2 = !DIMacro(macinfo: DW_MACINFO_define, line: 7, name: "foo(x)",
value: "((x) + 1)") value: "((x) + 1)")
@ -4362,7 +4362,7 @@ DIMacroFile
The ``nodes:`` field is a list of ``DIMacro`` and ``DIMacroFile`` nodes that The ``nodes:`` field is a list of ``DIMacro`` and ``DIMacroFile`` nodes that
appear in the included source file. appear in the included source file.
.. code-block:: llvm .. code-block:: text
!2 = !DIMacroFile(macinfo: DW_MACINFO_start_file, line: 7, file: !2, !2 = !DIMacroFile(macinfo: DW_MACINFO_start_file, line: 7, file: !2,
nodes: !3) nodes: !3)
@ -5660,7 +5660,7 @@ block. Therefore, it must be the only non-phi instruction in the block.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
dispatch1: dispatch1:
%cs1 = catchswitch within none [label %handler0, label %handler1] unwind to caller %cs1 = catchswitch within none [label %handler0, label %handler1] unwind to caller
@ -5711,7 +5711,7 @@ the ``catchret``'s behavior is undefined.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
catchret from %catch label %continue catchret from %catch label %continue
@ -5761,7 +5761,7 @@ It transfers control to ``continue`` or unwinds out of the function.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
cleanupret from %cleanup unwind to caller cleanupret from %cleanup unwind to caller
cleanupret from %cleanup unwind label %continue cleanupret from %cleanup unwind label %continue
@ -5851,7 +5851,7 @@ unsigned and/or signed overflow, respectively, occurs.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = add i32 4, %var ; yields i32:result = 4 + %var <result> = add i32 4, %var ; yields i32:result = 4 + %var
@ -5890,7 +5890,7 @@ optimizations:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = fadd float 4.0, %var ; yields float:result = 4.0 + %var <result> = fadd float 4.0, %var ; yields float:result = 4.0 + %var
@ -5942,7 +5942,7 @@ unsigned and/or signed overflow, respectively, occurs.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = sub i32 4, %var ; yields i32:result = 4 - %var <result> = sub i32 4, %var ; yields i32:result = 4 - %var
<result> = sub i32 0, %val ; yields i32:result = -%var <result> = sub i32 0, %val ; yields i32:result = -%var
@ -5985,7 +5985,7 @@ unsafe floating point optimizations:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = fsub float 4.0, %var ; yields float:result = 4.0 - %var <result> = fsub float 4.0, %var ; yields float:result = 4.0 - %var
<result> = fsub float -0.0, %val ; yields float:result = -%var <result> = fsub float -0.0, %val ; yields float:result = -%var
@ -6039,7 +6039,7 @@ unsigned and/or signed overflow, respectively, occurs.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = mul i32 4, %var ; yields i32:result = 4 * %var <result> = mul i32 4, %var ; yields i32:result = 4 * %var
@ -6078,7 +6078,7 @@ unsafe floating point optimizations:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = fmul float 4.0, %var ; yields float:result = 4.0 * %var <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: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = udiv i32 4, %var ; yields i32:result = 4 / %var <result> = udiv i32 4, %var ; yields i32:result = 4 / %var
@ -6168,7 +6168,7 @@ a :ref:`poison value <poisonvalues>` if the result would be rounded.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = sdiv i32 4, %var ; yields i32:result = 4 / %var <result> = sdiv i32 4, %var ; yields i32:result = 4 / %var
@ -6207,7 +6207,7 @@ unsafe floating point optimizations:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = fdiv float 4.0, %var ; yields float:result = 4.0 / %var <result> = 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: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = urem i32 4, %var ; yields i32:result = 4 % %var <result> = urem i32 4, %var ; yields i32:result = 4 % %var
@ -6304,7 +6304,7 @@ result of the division and the remainder.)
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = srem i32 4, %var ; yields i32:result = 4 % %var <result> = srem i32 4, %var ; yields i32:result = 4 % %var
@ -6344,7 +6344,7 @@ to enable otherwise unsafe floating point optimizations:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = frem float 4.0, %var ; yields float:result = 4.0 % %var <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: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = shl i32 4, %var ; yields i32: 4 << %var <result> = shl i32 4, %var ; yields i32: 4 << %var
<result> = shl i32 4, 2 ; yields i32: 16 <result> = shl i32 4, 2 ; yields i32: 16
@ -6455,7 +6455,7 @@ non-zero.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = lshr i32 4, 1 ; yields i32:result = 2 <result> = lshr i32 4, 1 ; yields i32:result = 2
<result> = lshr i32 4, 2 ; yields i32:result = 1 <result> = lshr i32 4, 2 ; yields i32:result = 1
@ -6506,7 +6506,7 @@ non-zero.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = ashr i32 4, 1 ; yields i32:result = 2 <result> = ashr i32 4, 1 ; yields i32:result = 2
<result> = ashr i32 4, 2 ; yields i32:result = 1 <result> = ashr i32 4, 2 ; yields i32:result = 1
@ -6558,7 +6558,7 @@ The truth table used for the '``and``' instruction is:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = and i32 4, %var ; yields i32:result = 4 & %var <result> = and i32 4, %var ; yields i32:result = 4 & %var
<result> = and i32 15, 40 ; yields i32:result = 8 <result> = and i32 15, 40 ; yields i32:result = 8
@ -6657,7 +6657,7 @@ The truth table used for the '``xor``' instruction is:
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = xor i32 4, %var ; yields i32:result = 4 ^ %var <result> = xor i32 4, %var ; yields i32:result = 4 ^ %var
<result> = xor i32 15, 40 ; yields i32:result = 39 <result> = xor i32 15, 40 ; yields i32:result = 39
@ -6710,7 +6710,7 @@ exceeds the length of ``val``, the results are undefined.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = extractelement <4 x i32> %vec, i32 0 ; yields i32 <result> = extractelement <4 x i32> %vec, i32 0 ; yields i32
@ -6752,7 +6752,7 @@ undefined.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32> <result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32>
@ -6800,7 +6800,7 @@ only one vector.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <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> <4 x i32> <i32 0, i32 4, i32 1, i32 5> ; yields <4 x i32>
@ -6859,7 +6859,7 @@ the index operands.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = extractvalue {i32, float} %agg, 0 ; yields i32 <result> = extractvalue {i32, float} %agg, 0 ; yields i32
@ -8126,7 +8126,7 @@ or :ref:`ptrtoint <i_ptrtoint>` instructions first.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
%X = bitcast i8 255 to i8 ; yields i8 :-1 %X = bitcast i8 255 to i8 ; yields i8 :-1
%Y = bitcast i32* %x to sint* ; yields sint*:%x %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: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = icmp eq i32 4, 5 ; yields: result=false <result> = icmp eq i32 4, 5 ; yields: result=false
<result> = icmp ne float* %X, %X ; yields: result=false <result> = icmp ne float* %X, %X ; yields: result=false
@ -8379,7 +8379,7 @@ assumptions to be made about the values of input arguments; namely
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
<result> = fcmp oeq float 4.0, 5.0 ; yields: result=false <result> = fcmp oeq float 4.0, 5.0 ; yields: result=false
<result> = fcmp one float 4.0, 5.0 ; yields: result=true <result> = fcmp one float 4.0, 5.0 ; yields: result=true
@ -8815,7 +8815,7 @@ that does not carry an appropriate :ref:`"funclet" bundle <ob_funclet>`.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
dispatch: dispatch:
%cs = catchswitch within none [label %handler0] unwind to caller %cs = catchswitch within none [label %handler0] unwind to caller
@ -8885,7 +8885,7 @@ that does not carry an appropriate :ref:`"funclet" bundle <ob_funclet>`.
Example: Example:
"""""""" """"""""
.. code-block:: llvm .. code-block:: text
%tok = cleanuppad within %cs [] %tok = cleanuppad within %cs []
@ -12481,7 +12481,7 @@ optimistic assumptions made during compilation. The semantics of
``@llvm.experimental.deoptimize`` -- its body is defined to be ``@llvm.experimental.deoptimize`` -- its body is defined to be
equivalent to: equivalent to:
.. code-block:: llvm .. code-block:: text
define void @llvm.experimental.guard(i1 %pred, <args...>) { define void @llvm.experimental.guard(i1 %pred, <args...>) {
%realPred = and i1 %pred, undef %realPred = and i1 %pred, undef

42
docs/MIRLangRef.rst
View File

@ -111,7 +111,6 @@ Here is an example of a YAML document that contains an LLVM module:
.. code-block:: llvm .. code-block:: llvm
--- |
define i32 @inc(i32* %x) { define i32 @inc(i32* %x) {
entry: entry:
%0 = load i32, i32* %x %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 store i32 %1, i32* %x
ret i32 %1 ret i32 %1
} }
...
.. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688 .. _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 The remaining YAML documents contain the machine functions. This is an example
of such YAML document: of such YAML document:
.. code-block:: llvm .. code-block:: text
--- ---
name: inc 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. that contains the block's ID.
The example below defines two blocks that have an ID of zero and one: The example below defines two blocks that have an ID of zero and one:
.. code-block:: llvm .. code-block:: text
bb.0: bb.0:
<instructions> <instructions>
@ -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 A machine basic block can also have a name. It should be specified after the ID
in the block's definition: in the block's definition:
.. code-block:: llvm .. code-block:: text
bb.0.entry: ; This block's name is "entry" bb.0.entry: ; This block's name is "entry"
<instructions> <instructions>
@ -196,7 +194,7 @@ Block References
The machine basic blocks are identified by their ID numbers. Individual The machine basic blocks are identified by their ID numbers. Individual
blocks are referenced using the following syntax: blocks are referenced using the following syntax:
.. code-block:: llvm .. code-block:: text
%bb.<id>[.<name>] %bb.<id>[.<name>]
@ -213,7 +211,7 @@ Successors
The machine basic block's successors have to be specified before any of the The machine basic block's successors have to be specified before any of the
instructions: instructions:
.. code-block:: llvm .. code-block:: text
bb.0.entry: bb.0.entry:
successors: %bb.1.then, %bb.2.else 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 The example below defines a block that has two successors with branch weights
of 32 and 16: of 32 and 16:
.. code-block:: llvm .. code-block:: text
bb.0.entry: bb.0.entry:
successors: %bb.1.then(32), %bb.2.else(16) 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 machine basic block's live in registers have to be specified before any of
the instructions: the instructions:
.. code-block:: llvm .. code-block:: text
bb.0.entry: bb.0.entry:
liveins: %edi, %esi liveins: %edi, %esi
@ -255,7 +253,7 @@ Miscellaneous Attributes
The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be
specified in brackets after the block's definition: specified in brackets after the block's definition:
.. code-block:: llvm .. code-block:: text
bb.0.entry (address-taken): bb.0.entry (address-taken):
<instructions> <instructions>
@ -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 below shows an instance of the X86 ``RETQ`` instruction with a single machine
operand: operand:
.. code-block:: llvm .. code-block:: text
RETQ %eax 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 below shows an instance of the AArch64 ``LDPXpost`` instruction with three
defined register operands: defined register operands:
.. code-block:: llvm .. code-block:: text
%sp, %fp, %lr = LDPXpost %sp, 2 %sp, %fp, %lr = LDPXpost %sp, 2
@ -303,7 +301,7 @@ Instruction Flags
The flag ``frame-setup`` can be specified before the instruction's name: 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 %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 The physical registers are identified by their name. They use the following
syntax: syntax:
.. code-block:: llvm .. code-block:: text
%<name> %<name>
The example below shows three X86 physical registers: The example below shows three X86 physical registers:
.. code-block:: llvm .. code-block:: text
%eax %eax
%r15 %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 The virtual registers are identified by their ID number. They use the following
syntax: syntax:
.. code-block:: llvm .. code-block:: text
%<id> %<id>
Example: Example:
.. code-block:: llvm .. code-block:: text
%0 %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 example below shows an instance of the X86 ``MOV32ri`` instruction that has an
immediate machine operand ``-42``: immediate machine operand ``-42``:
.. code-block:: llvm .. code-block:: text
%eax = MOV32ri -42 %eax = MOV32ri -42
@ -384,14 +382,14 @@ machine operands. The register operands can also have optional
and a reference to the tied register operand. and a reference to the tied register operand.
The full syntax of a register operand is shown below: 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>) ] [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]
This example shows an instance of the X86 ``XOR32rr`` instruction that has This example shows an instance of the X86 ``XOR32rr`` instruction that has
5 register operands with different register flags: 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 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 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: 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 %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 The example below shows an instance of the X86 ``MOV64rm`` instruction that has
a global value operand named ``G``: a global value operand named ``G``:
.. code-block:: llvm .. code-block:: text
%rax = MOV64rm %rip, 1, _, @G, _ %rax = MOV64rm %rip, 1, _, @G, _

2
docs/MarkedUpDisassembly.rst
View File

@ -70,7 +70,7 @@ clients.
For example, a possible annotation of an ARM load of a stack-relative location For example, a possible annotation of an ARM load of a stack-relative location
might be annotated as: might be annotated as:
.. code-block:: nasm .. code-block:: text
ldr <reg gpr:r0>, <mem regoffset:[<reg gpr:sp>, <imm:#4>]> ldr <reg gpr:r0>, <mem regoffset:[<reg gpr:sp>, <imm:#4>]>

6
docs/MergeFunctions.rst
View File

@ -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, corresponding part of *right* place, and (!) both parts use *Value* instances,
for example: for example:
.. code-block:: llvm .. code-block:: text
instr0 i32 %LV ; left side, function FL instr0 i32 %LV ; left side, function FL
instr0 i32 %RV ; right side, function FR instr0 i32 %RV ; right side, function FR
@ -409,13 +409,13 @@ in "*FL*" and "*FR*".
Consider small example here: Consider small example here:
.. code-block:: llvm .. code-block:: text
define void %f(i32 %pf0, i32 %pf1) { define void %f(i32 %pf0, i32 %pf1) {
instr0 i32 %pf0 instr1 i32 %pf1 instr2 i32 123 instr0 i32 %pf0 instr1 i32 %pf1 instr2 i32 123
} }
.. code-block:: llvm .. code-block:: text
define void %g(i32 %pg0, i32 %pg1) { define void %g(i32 %pg0, i32 %pg1) {
instr0 i32 %pg0 instr1 i32 %pg0 instr2 i32 123 instr0 i32 %pg0 instr1 i32 %pg0 instr2 i32 123

2
docs/NVPTXUsage.rst
View File

@ -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 declare a function as a kernel function. This metadata is attached to the
``nvvm.annotations`` named metadata object, and has the following format: ``nvvm.annotations`` named metadata object, and has the following format:
.. code-block:: llvm .. code-block:: text
!0 = !{<function-ref>, metadata !"kernel", i32 1} !0 = !{<function-ref>, metadata !"kernel", i32 1}

2
docs/SegmentedStacks.rst
View File

@ -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 this slot's offset is again dictated by ``libgcc``. The generated
assembly looks like this on x86-64: assembly looks like this on x86-64:
.. code-block:: nasm .. code-block:: text
leaq -8(%rsp), %r10 leaq -8(%rsp), %r10
cmpq %fs:112, %r10 cmpq %fs:112, %r10

10
docs/SourceLevelDebugging.rst
View File

@ -230,7 +230,7 @@ following C fragment, for example:
Compiled to LLVM, this function would be represented like this: Compiled to LLVM, this function would be represented like this:
.. code-block:: llvm .. code-block:: text
; Function Attrs: nounwind ssp uwtable ; Function Attrs: nounwind ssp uwtable
define void @foo() #0 !dbg !4 { 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 variable ``X``. The metadata ``!dbg !14`` attached to the intrinsic provides
scope information for the variable ``X``. scope information for the variable ``X``.
.. code-block:: llvm .. code-block:: text
!14 = !DILocation(line: 2, column: 9, scope: !4) !14 = !DILocation(line: 2, column: 9, scope: !4)
!4 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 1, type: !5, !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 variable ``Z``. The metadata ``!dbg !19`` attached to the intrinsic provides
scope information for the variable ``Z``. scope information for the variable ``Z``.
.. code-block:: llvm .. code-block:: text
!18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 4, column: 5) !18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 4, column: 5)
!19 = !DILocation(line: 5, column: 11, scope: !18) !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: a C/C++ front-end would generate the following descriptors:
.. code-block:: llvm .. code-block:: text
;; ;;
;; Define the global itself. ;; Define the global itself.
@ -456,7 +456,7 @@ Given a function declared as follows:
a C/C++ front-end would generate the following descriptors: a C/C++ front-end would generate the following descriptors:
.. code-block:: llvm .. code-block:: text
;; ;;
;; Define the anchor for subprograms. ;; Define the anchor for subprograms.

12
docs/Statepoints.rst
View File

@ -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 ``%obj`` after the safepoint and update any following uses appropriately. The
resulting relocation sequence is: resulting relocation sequence is:
.. code-block:: llvm .. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" { gc "statepoint-example" {
@ -237,7 +237,7 @@ afterwards.
If we extend our previous example to include a pointless derived pointer, If we extend our previous example to include a pointless derived pointer,
we get: we get:
.. code-block:: llvm .. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" { 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 --that requires that a TLS variable must be written to before and after a call
to unmanaged code. The resulting relocation sequence is: to unmanaged code. The resulting relocation sequence is:
.. code-block:: llvm .. code-block:: text
@flag = thread_local global i32 0, align 4 @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: As an example, given this code:
.. code-block:: llvm .. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" { gc "statepoint-example" {
@ -672,7 +672,7 @@ As an example, given this code:
The pass would produce this IR: The pass would produce this IR:
.. code-block:: llvm .. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" { gc "statepoint-example" {
@ -737,7 +737,7 @@ As an example, given input IR of the following:
This pass would produce the following IR: This pass would produce the following IR:
.. code-block:: llvm .. code-block:: text
define void @test() gc "statepoint-example" { 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) %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)

28
docs/TableGen/LangIntro.rst
View File

@ -232,7 +232,7 @@ the record ends with a semicolon.
Here is a simple TableGen file: Here is a simple TableGen file:
.. code-block:: llvm .. code-block:: text
class C { bit V = 1; } class C { bit V = 1; }
def X : C; 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 value. For example, a new class could be added to the example above, redefining
the ``V`` field for all of its subclasses: the ``V`` field for all of its subclasses:
.. code-block:: llvm .. code-block:: text
class D : C { let V = 0; } class D : C { let V = 0; }
def Z : D; 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 bindings (which may optionally have defaults) that are bound when used. Here is
a simple example: a simple example:
.. code-block:: llvm .. code-block:: text
class FPFormat<bits<3> val> { class FPFormat<bits<3> val> {
bits<3> Value = val; bits<3> Value = val;
@ -316,7 +316,7 @@ integer.
The more esoteric forms of `TableGen expressions`_ are useful in conjunction The more esoteric forms of `TableGen expressions`_ are useful in conjunction
with template arguments. As an example: with template arguments. As an example:
.. code-block:: llvm .. code-block:: text
class ModRefVal<bits<2> val> { class ModRefVal<bits<2> val> {
bits<2> Value = 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, actual internal data representation expected by the class. In this case,
running ``llvm-tblgen`` on the example prints the following definitions: running ``llvm-tblgen`` on the example prints the following definitions:
.. code-block:: llvm .. code-block:: text
def bork { // Value def bork { // Value
bit isMod = 1; 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: Here is an example TableGen fragment that shows this idea:
.. code-block:: llvm .. code-block:: text
def ops; def ops;
def GPR; 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 multiclass. Using a multiclass this way is exactly equivalent to instantiating
the classes multiple times yourself, e.g. by writing: the classes multiple times yourself, e.g. by writing:
.. code-block:: llvm .. code-block:: text
def ops; def ops;
def GPR; 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 A ``defm`` can also be used inside a multiclass providing several levels of
multiclass instantiations. multiclass instantiations.
.. code-block:: llvm .. code-block:: text
class Instruction<bits<4> opc, string Name> { class Instruction<bits<4> opc, string Name> {
bits<4> opcode = opc; 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 the class list must start after the last multiclass, and there must be at least
one multiclass before them. one multiclass before them.
.. code-block:: llvm .. code-block:: text
class XD { bits<4> Prefix = 11; } class XD { bits<4> Prefix = 11; }
class XS { bits<4> Prefix = 12; } 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. specified as a double quoted string immediately after the '``include``' keyword.
Example: Example:
.. code-block:: llvm .. code-block:: text
include "foo.td" include "foo.td"
@ -532,7 +532,7 @@ commonality from the records.
File-scope "let" expressions take a comma-separated list of bindings to apply, 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: 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 let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>; 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" levels of multiclass instantiations. This also avoids the need of using "let"
expressions within subsequent records inside a multiclass. expressions within subsequent records inside a multiclass.
.. code-block:: llvm .. code-block:: text
multiclass basic_r<bits<4> opc> { multiclass basic_r<bits<4> opc> {
let Predicates = [HasSSE2] in { 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. body, substituting iterator values for iterator references in the body.
Example: Example:
.. code-block:: llvm .. code-block:: text
foreach i = [0, 1, 2, 3] in { foreach i = [0, 1, 2, 3] in {
def R#i : Register<...>; 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 may be nested. If there is only one item in the body the braces may be
elided: elided:
.. code-block:: llvm .. code-block:: text
foreach i = [0, 1, 2, 3] in foreach i = [0, 1, 2, 3] in
def R#i : Register<...>; def R#i : Register<...>;

10
docs/TableGen/index.rst
View File

@ -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 various definitions expand to fully. Running this on the ``X86.td`` file prints
this (at the time of this writing): this (at the time of this writing):
.. code-block:: llvm .. code-block:: text
... ...
def ADD32rr { // Instruction X86Inst I 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 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: TableGen, all of the information was derived from the following definition:
.. code-block:: llvm .. code-block:: text
let Defs = [EFLAGS], let Defs = [EFLAGS],
isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y 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 **TableGen definitions** are the concrete form of 'records'. These generally do
not have any undefined values, and are marked with the '``def``' keyword. 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", def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
"Enable ARMv8 FP">; "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 the classes that are used to build up a definition, so the backend can find all
definitions of a particular class, such as "Instruction". definitions of a particular class, such as "Instruction".
.. code-block:: llvm .. code-block:: text
class ProcNoItin<string Name, list<SubtargetFeature> Features> class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>; : Processor<Name, NoItineraries, Features>;
@ -235,7 +235,7 @@ If a multiclass inherits from another multiclass, the definitions in the
sub-multiclass become part of the current multiclass, as if they were declared sub-multiclass become part of the current multiclass, as if they were declared
in the current multiclass. in the current multiclass.
.. code-block:: llvm .. code-block:: text
multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend, multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
dag address, ValueType sty> { dag address, ValueType sty> {

62
docs/WritingAnLLVMBackend.rst
View File

@ -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 ``Name`` of the register. The basic ``Register`` object does not have any
subregisters and does not specify any aliases. subregisters and does not specify any aliases.
.. code-block:: llvm .. code-block:: text
class Register<string n> { class Register<string n> {
string Namespace = ""; string Namespace = "";
@ -361,7 +361,7 @@ subregisters and does not specify any aliases.
For example, in the ``X86RegisterInfo.td`` file, there are register definitions For example, in the ``X86RegisterInfo.td`` file, there are register definitions
that utilize the ``Register`` class, such as: that utilize the ``Register`` class, such as:
.. code-block:: llvm .. code-block:: text
def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>; 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 ``RegisterWithSubRegs`` class that is used to define registers that need to
specify subregisters in the ``SubRegs`` list, as shown here: specify subregisters in the ``SubRegs`` list, as shown here:
.. code-block:: llvm .. code-block:: text
class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> { class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> {
let SubRegs = subregs; 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`` override values that are initially defined in a superclass (such as ``SubRegs``
field in the ``Rd`` class). field in the ``Rd`` class).
.. code-block:: llvm .. code-block:: text
class SparcReg<string n> : Register<n> { class SparcReg<string n> : Register<n> {
field bits<5> Num; field bits<5> Num;
@ -452,7 +452,7 @@ field in the ``Rd`` class).
In the ``SparcRegisterInfo.td`` file, there are register definitions that In the ``SparcRegisterInfo.td`` file, there are register definitions that
utilize these subclasses of ``Register``, such as: utilize these subclasses of ``Register``, such as:
.. code-block:: llvm .. code-block:: text
def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>; def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>;
def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>; 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 ``XXXRegisterInfo.td`` that uses ``Target.td`` can construct register classes
using the following class: using the following class:
.. code-block:: llvm .. code-block:: text
class RegisterClass<string namespace, class RegisterClass<string namespace,
list<ValueType> regTypes, int alignment, dag regList> { list<ValueType> 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 ``F31``); ``DFPRegs`` defines a group of 16 double-precision registers
(``D0-D15``). (``D0-D15``).
.. code-block:: llvm .. code-block:: text
// F0, F1, F2, ..., F31 // F0, F1, F2, ..., F31
def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>; 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 The Instruction class (defined in ``Target.td``) is mostly used as a base for
more complex instruction classes. more complex instruction classes.
.. code-block:: llvm .. code-block:: text
class Instruction { class Instruction {
string Namespace = ""; 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`` output destination, which is a register operand and defined in the ``Register``
target description file (``IntRegs``). target description file (``IntRegs``).
.. code-block:: llvm .. code-block:: text
def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr), def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
"ld [$addr], $dst", "ld [$addr], $dst",
@ -769,7 +769,7 @@ target description file (``IntRegs``).
The fourth parameter is the input source, which uses the address operand The fourth parameter is the input source, which uses the address operand
``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``: ``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``:
.. code-block:: llvm .. code-block:: text
def MEMrr : Operand<i32> { def MEMrr : Operand<i32> {
let PrintMethod = "printMemOperand"; 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 for a Word from an immediate operand to a register, the following instruction
class is defined: class is defined:
.. code-block:: llvm .. code-block:: text
def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
"ld [$addr], $dst", "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 pattern ``F3_12`` is defined to create 2 instruction classes each time
``F3_12`` is invoked: ``F3_12`` is invoked:
.. code-block:: llvm .. code-block:: text
multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> { multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
def rr : F3_1 <2, Op3Val, 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``, instructions, as seen below, it creates four instruction objects: ``XORrr``,
``XORri``, ``ADDrr``, and ``ADDri``. ``XORri``, ``ADDrr``, and ``ADDri``.
.. code-block:: llvm .. code-block:: text
defm XOR : F3_12<"xor", 0b000011, xor>; defm XOR : F3_12<"xor", 0b000011, xor>;
defm ADD : F3_12<"add", 0b000000, add>; 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 integers, and the 22\ :sup:`nd` bit represents the "greater than" condition for
floats. floats.
.. code-block:: llvm .. code-block:: text
def ICC_NE : ICC_VAL< 9>; // Not Equal def ICC_NE : ICC_VAL< 9>; // Not Equal
def ICC_E : ICC_VAL< 1>; // 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`` example, the Sparc target defines the ``XNORrr`` instruction as a ``F3_1``
format instruction having three operands. format instruction having three operands.
.. code-block:: llvm .. code-block:: text
def XNORrr : F3_1<2, 0b000111, def XNORrr : F3_1<2, 0b000111,
(outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), (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 The instruction templates in ``SparcInstrFormats.td`` show the base class for
``F3_1`` is ``InstSP``. ``F3_1`` is ``InstSP``.
.. code-block:: llvm .. code-block:: text
class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
field bits<32> Inst; 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. ``InstSP`` leaves the ``op`` field unbound.
.. code-block:: llvm .. code-block:: text
class F3<dag outs, dag ins, string asmstr, list<dag> pattern> class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSP<outs, ins, asmstr, pattern> { : InstSP<outs, ins, asmstr, pattern> {
@ -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 fields. ``F3`` format instructions will bind the operands ``rd``, ``op3``, and
``rs1`` fields. ``rs1`` fields.
.. code-block:: llvm .. code-block:: text
class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins, class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> { string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
@ -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 llvm::XXX:OpName namespace and also add an entry for it into the OperandMap
table, which can be queried using getNamedOperandIdx() table, which can be queried using getNamedOperandIdx()
.. code-block:: llvm .. code-block:: text
int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); // => 0 int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); // => 0
int BIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::b); // => 1 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 instances of the TableGen ``Operand`` class, which represent branch target
operands: operands:
.. code-block:: llvm .. code-block:: text
def brtarget : Operand<OtherVT>; def brtarget : Operand<OtherVT>;
def brtarget8 : Operand<OtherVT>; def brtarget8 : Operand<OtherVT>;
@ -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 this entry defines a register store operation, and the last parameter describes
a pattern with the store DAG operator. 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), def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
"st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>; "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>;
``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``: ``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``:
.. code-block:: llvm .. code-block:: text
def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>; def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
@ -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 In ``lib/Target/TargetSelectionDAG.td``, the DAG operator for store is defined
below: below:
.. code-block:: llvm .. code-block:: text
def store : PatFrag<(ops node:$val, node:$ptr), def store : PatFrag<(ops node:$val, node:$ptr),
(st 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 performed. In this case, the ``CCAssignToReg`` action assigns the argument
value to the first available register: either ``R0`` or ``R1``. value to the first available register: either ``R0`` or ``R1``.
.. code-block:: llvm .. code-block:: text
CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>> 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 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``. register ``D0``. A 32-bit integer is returned in register ``I0`` or ``I1``.
.. code-block:: llvm .. code-block:: text
def RetCC_Sparc32 : CallingConv<[ def RetCC_Sparc32 : CallingConv<[
CCIfType<[i32], CCAssignToReg<[I0, I1]>>, 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 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.) size is used; if alignment is zero, then the ABI alignment is used.)
.. code-block:: llvm .. code-block:: text
def CC_Sparc32 : CallingConv<[ def CC_Sparc32 : CallingConv<[
// All arguments get passed in integer registers if there is space. // 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 assigned to the register ``ST0`` or ``ST1``, the ``RetCC_X86Common`` is
invoked. invoked.
.. code-block:: llvm .. code-block:: text
def RetCC_X86_32_C : CallingConv<[ def RetCC_X86_32_C : CallingConv<[
CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>, 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 ``RetCC_X86_32_Fast`` is invoked. If the ``SSECall`` calling convention is in
use, then ``RetCC_X86_32_SSE`` is invoked. use, then ``RetCC_X86_32_SSE`` is invoked.
.. code-block:: llvm .. code-block:: text
def RetCC_X86_32 : CallingConv<[ def RetCC_X86_32 : CallingConv<[
CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>, CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
@ -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 fifth parameter is a list of features whose presence is implied, and its
default value is an empty array.) default value is an empty array.)
.. code-block:: llvm .. code-block:: text
class SubtargetFeature<string n, string a, string v, string d, class SubtargetFeature<string n, string a, string v, string d,
list<SubtargetFeature> i = []> { 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 In the ``Sparc.td`` file, the ``SubtargetFeature`` is used to define the
following features. following features.
.. code-block:: llvm .. code-block:: text
def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true", def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
"Enable SPARC-V9 instructions">; "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 define particular SPARC processor subtypes that may have the previously
described features. described features.
.. code-block:: llvm .. code-block:: text
class Proc<string Name, list<SubtargetFeature> Features> class Proc<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>; : Processor<Name, NoItineraries, Features>;

2
docs/WritingAnLLVMPass.rst
View File

@ -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 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 :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 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 If you want your pass to be easily dumpable, you should implement the virtual
print method: print method: