CbC/CbC_llvm: docs/MIRLangRef.rst comparison

comparison docs/MIRLangRef.rst @ 147:c2174574ed3a

LLVM 10

author	Shinji KONO <kono@ie.u-ryukyu.ac.jp>
date	Wed, 14 Aug 2019 16:55:33 +0900
parents	3a76565eade5
children

comparison

equal deleted inserted replaced

-:3a76565eade5
+:c2174574ed3a
 for the post register allocation pseudo instruction expansion pass, you can
 specify the machine copy propagation pass in the ``-stop-after`` option, as it
 runs just before the pass that we are trying to test:
 ``llc -stop-after=machine-cp bug-trigger.ll > test.mir``
+If the same pass is run multiple times, a run index can be included
+after the name with a comma.
+``llc -stop-after=dead-mi-elimination,1 bug-trigger.ll > test.mir``
 After generating the input MIR file, you'll have to add a run line that uses
 the ``-run-pass`` option to it. In order to test the post register allocation
 pseudo instruction expansion pass on X86-64, a run line like the one shown
 below can be used:
 subclasses isn't serialized at the moment.
 - The target-specific ``MachineConstantPoolValue`` subclasses (in the ARM and
 SystemZ backends) aren't serialized at the moment.
-- The ``MCSymbol`` machine operands are only printed, they can't be parsed.
+- The ``MCSymbol`` machine operands don't support temporary or local symbols.
 - A lot of the state in ``MachineModuleInfo`` isn't serialized - only the CFI
 instructions and the variable debug information from MMI is serialized right
 now.
 These limitations impose restrictions on what you can test with the MIR format.
 For now, tests that would like to test some behaviour that depends on the state
-of certain ``MCSymbol``  operands or the exception handling state in MMI, can't
+of temporary or local ``MCSymbol``  operands or the exception handling state in
-use the MIR format. As well as that, tests that test some behaviour that
+MMI, can't use the MIR format. As well as that, tests that test some behaviour
-depends on the state of the target specific ``MachineFunctionInfo`` or
+that depends on the state of the target specific ``MachineFunctionInfo`` or
 ``MachineConstantPoolValue`` subclasses can't use the MIR format at the moment.
 High Level Structure
 ====================
 ---
 name:            inc
 tracksRegLiveness: true
 liveins:
-- { reg: '%rdi' }
+- { reg: '$rdi' }
+callSites:
+- { bb: 0, offset: 3, fwdArgRegs:
+- { arg: 0, reg: '$edi' } }
 body: |
 bb.0.entry:
-liveins: %rdi
+liveins: $rdi
-%eax = MOV32rm %rdi, 1, _, 0, _
+$eax = MOV32rm $rdi, 1, _, 0, _
-%eax = INC32r killed %eax, implicit-def dead %eflags
+$eax = INC32r killed $eax, implicit-def dead $eflags
-MOV32mr killed %rdi, 1, _, 0, _, %eax
+MOV32mr killed $rdi, 1, _, 0, _, $eax
-RETQ %eax
+CALL64pcrel32 @foo <regmask...>
+RETQ $eax
 ...
 The document above consists of attributes that represent the various
 properties and data structures in a machine function.
 The attribute ``name`` is required, and its value should be identical to the
 name of a function that this machine function is based on.
 The attribute ``body`` is a `YAML block literal string`_. Its value represents
 the function's machine basic blocks and their machine instructions.
+The attribute ``callSites`` is a representation of call site information which
+keeps track of call instructions and registers used to transfer call arguments.
 Machine Instructions Format Reference
 =====================================
 The machine basic blocks and their instructions are represented using a custom,
 the instructions:
 .. code-block:: text
 bb.0.entry:
-liveins: %edi, %esi
+liveins: $edi, $esi
 The list of live in registers and successors can be empty. The language also
 allows multiple live in register and successor lists - they are combined into
 one list by the parser.
 below shows an instance of the X86 ``RETQ`` instruction with a single machine
 operand:
 .. code-block:: text
-RETQ %eax
+RETQ $eax
 However, if the machine instruction has one or more explicitly defined register
 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:: text
-%sp, %fp, %lr = LDPXpost %sp, 2
+$sp, $fp, $lr = LDPXpost $sp, 2
 The instruction names are serialized using the exact definitions from the
 target's ``*InstrInfo.td`` files, and they are case sensitive. This means that
 similar instruction names like ``TSTri`` and ``tSTRi`` represent different
 machine instructions.
 The flag ``frame-setup`` or ``frame-destroy`` can be specified before the
 instruction's name:
 .. code-block:: text
-%fp = frame-setup ADDXri %sp, 0, 0
+$fp = frame-setup ADDXri $sp, 0, 0
 .. code-block:: text
-%x21, %x20 = frame-destroy LDPXi %sp
+$x21, $x20 = frame-destroy LDPXi $sp
 .. _registers:
 Bundled Instructions
 ^^^^^^^^^^^^^^^^^^^^
 The syntax for bundled instructions is the following:
 .. code-block:: text
-BUNDLE implicit-def %r0, implicit-def %r1, implicit %r2 {
+BUNDLE implicit-def $r0, implicit-def $r1, implicit $r2 {
-%r0 = SOME_OP %r2
+$r0 = SOME_OP $r2
-%r1 = ANOTHER_OP internal %r0
+$r1 = ANOTHER_OP internal $r0
 }
 The first instruction is often a bundle header. The instructions between ``{``
 and ``}`` are bundled with the first instruction.
 Registers
 ---------
 Registers are one of the key primitives in the machine instructions
-serialization language. They are primarly used in the
+serialization language. They are primarily used in the
 :ref:`register machine operands <register-operands>`,
 but they can also be used in a number of other places, like the
 :ref:`basic block's live in list <bb-liveins>`.
-The physical registers are identified by their name. They use the following
+The physical registers are identified by their name and by the '$' prefix sigil.
-syntax:
+They use the following syntax:
 .. code-block:: text
-%<name>
+$<name>
 The example below shows three X86 physical registers:
 .. code-block:: text
-%eax
+$eax
-%r15
+$r15
-%eflags
+$eflags
-The virtual registers are identified by their ID number. They use the following
+The virtual registers are identified by their ID number and by the '%' sigil.
-syntax:
+They use the following syntax:
 .. code-block:: text
 %<id>
 .. code-block:: text
 %0
 The null registers are represented using an underscore ('``_``'). They can also be
-represented using a '``%noreg``' named register, although the former syntax
+represented using a '``$noreg``' named register, although the former syntax
 is preferred.
 .. _machine-operands:
 Machine Operands
 ----------------
-There are seventeen different kinds of machine operands, and all of them, except
+There are seventeen different kinds of machine operands, and all of them can be
-the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are
+serialized.
-just printed out - they can't be parsed back yet.
 Immediate Operands
 ^^^^^^^^^^^^^^^^^^
 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:: text
-%eax = MOV32ri -42
+$eax = MOV32ri -42
 An immediate operand is also used to represent a subregister index when the
 machine instruction has one of the following opcodes:
 - ``EXTRACT_SUBREG``
 This example shows an instance of the X86 ``XOR32rr`` instruction that has
 5 register operands with different register flags:
 .. 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
 .. _register-flags:
 Register Flags
 ~~~~~~~~~~~~~~
 The example below shows an instance of the X86 ``MOV64rm`` instruction that has
 a global value operand named ``G``:
 .. code-block:: text
-%rax = MOV64rm %rip, 1, _, @G, _
+$rax = MOV64rm $rip, 1, _, @G, _
 The named global values are represented using an identifier with the '@' prefix.
 If the identifier doesn't match the regular expression
 `[-a-zA-Z$._][-a-zA-Z$._0-9]*`, then this identifier must be quoted.
 in the AMDGPU backend. So if we have a target index operand with the index 0
 and the offset 8:
 .. code-block:: text
-%sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _
+$sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _
 Jump-table Index Operands
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 A jump-table index operand with the index 0 is printed as following:
 .. code-block:: text
-tBR_JTr killed %r0, %jump-table.0
+tBR_JTr killed $r0, %jump-table.0
 A machine jump-table entry contains a list of ``MachineBasicBlocks``. When serializing all the function's jump-table entries, the following format is used:
 .. code-block:: text
 blocks:         [ '%bb.7', '%bb.7', '%bb.4.d3', '%bb.5' ]
 External Symbol Operands
 ^^^^^^^^^^^^^^^^^^^^^^^^^
-An external symbol operand is represented using an identifier with the ``$``
+An external symbol operand is represented using an identifier with the ``&``
 prefix. The identifier is surrounded with ""'s and escaped if it has any
 special non-printable characters in it.
 Example:
 .. code-block:: text
-CALL64pcrel32 $__stack_chk_fail, csr_64, implicit %rsp, implicit-def %rsp
+CALL64pcrel32 &__stack_chk_fail, csr_64, implicit $rsp, implicit-def $rsp
 MCSymbol Operands
 ^^^^^^^^^^^^^^^^^
 A MCSymbol operand is holding a pointer to a ``MCSymbol``. For the limitations
 The syntax is:
 .. code-block:: text
-CFI_INSTRUCTION offset %w30, -16
+CFI_INSTRUCTION offset $w30, -16
 which may be emitted later in the MC layer as:
 .. code-block:: text
 The syntax for the ``returnaddress`` intrinsic is:
 .. code-block:: text
-%x0 = COPY intrinsic(@llvm.returnaddress)
+$x0 = COPY intrinsic(@llvm.returnaddress)
 Predicate Operands
 ^^^^^^^^^^^^^^^^^^
 A Predicate operand contains an IR predicate from ``CmpInst::Predicate``, like

Mercurial > hg > CbC > CbC_llvm

comparison docs/MIRLangRef.rst @ 147:c2174574ed3a