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
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
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)
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:
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]
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]
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")
.. 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
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`
.. 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.
``llvm.eh.exceptionpointer``
----------------------------
-.. code-block:: llvm
+.. code-block:: text
i8 addrspace(N)* @llvm.eh.padparam.pNi8(token %catchpad)
``llvm.eh.sjlj.setjmp``
~~~~~~~~~~~~~~~~~~~~~~~
-.. code-block:: llvm
+.. code-block:: text
i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
return 0;
}
-.. code-block:: llvm
+.. code-block:: text
define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 {
entry:
}
}
-.. code-block:: llvm
+.. code-block:: text
define void @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) {
entry:
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:
Specifying GC code generation: ``gc "..."``
-------------------------------------------
-.. code-block:: llvm
+.. code-block:: text
define <returntype> @name(...) gc "name" { ... }
To make this clear, let's consider a more obtuse example:
-.. code-block:: llvm
+.. code-block:: text
%MyVar = uninitialized global i32
...
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 }
...
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 ]* }
...
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
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 ] }
...
``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
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
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)",
required by the relationship model, <tt>getPredOpcode</tt>, so that they can
be related.
-.. code-block:: llvm
+.. code-block:: text
def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
"$dst = add($a, $b)",
g(Foo(), Foo());
}
-.. code-block:: llvm
+.. code-block:: text
%struct.Foo = type { i32, i32 }
declare void @Foo_ctor(%struct.Foo* %this)
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)
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
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
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 { ... }
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* }>
The syntax for the source file name is simply:
-.. code-block:: llvm
+.. code-block:: text
source_filename = "/path/to/source.c"
allowed to assume that the '``undef``' operand could be the same as
``%Y``, allowing the whole '``select``' to be eliminated.
-.. code-block:: llvm
+.. code-block:: text
%A = xor undef, undef
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
Metadata nodes that aren't uniqued use the ``distinct`` keyword. For example:
-.. code-block:: llvm
+.. code-block:: text
!0 = distinct !{!"test\00", i32 10}
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,
``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)
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
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)
``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)
The following ``tag:`` values are valid:
-.. code-block:: llvm
+.. code-block:: text
DW_TAG_member = 13
DW_TAG_pointer_type = 15
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)
The following ``tag:`` values are valid:
-.. code-block:: llvm
+.. code-block:: text
DW_TAG_array_type = 1
DW_TAG_class_type = 2
then the subprogram declaration is uniqued based only on its ``linkageName:``
and ``scope:``.
-.. code-block:: llvm
+.. code-block:: text
define void @_Z3foov() !dbg !0 {
...
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)
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)
- ``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)
``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)
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)")
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)
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
dispatch1:
%cs1 = catchswitch within none [label %handler0, label %handler1] unwind to caller
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
catchret from %catch label %continue
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
cleanupret from %cleanup unwind to caller
cleanupret from %cleanup unwind label %continue
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = add i32 4, %var ; yields i32:result = 4 + %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = fadd float 4.0, %var ; yields float:result = 4.0 + %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = sub i32 4, %var ; yields i32:result = 4 - %var
<result> = sub i32 0, %val ; yields i32:result = -%var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = fsub float 4.0, %var ; yields float:result = 4.0 - %var
<result> = fsub float -0.0, %val ; yields float:result = -%var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = mul i32 4, %var ; yields i32:result = 4 * %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = fmul float 4.0, %var ; yields float:result = 4.0 * %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = udiv i32 4, %var ; yields i32:result = 4 / %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = sdiv i32 4, %var ; yields i32:result = 4 / %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = fdiv float 4.0, %var ; yields float:result = 4.0 / %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = urem i32 4, %var ; yields i32:result = 4 % %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = srem i32 4, %var ; yields i32:result = 4 % %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = frem float 4.0, %var ; yields float:result = 4.0 % %var
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = shl i32 4, %var ; yields i32: 4 << %var
<result> = shl i32 4, 2 ; yields i32: 16
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = lshr i32 4, 1 ; yields i32:result = 2
<result> = lshr i32 4, 2 ; yields i32:result = 1
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = ashr i32 4, 1 ; yields i32:result = 2
<result> = ashr i32 4, 2 ; yields i32:result = 1
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = and i32 4, %var ; yields i32:result = 4 & %var
<result> = and i32 15, 40 ; yields i32:result = 8
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = xor i32 4, %var ; yields i32:result = 4 ^ %var
<result> = xor i32 15, 40 ; yields i32:result = 39
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = extractelement <4 x i32> %vec, i32 0 ; yields i32
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32>
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
<4 x i32> <i32 0, i32 4, i32 1, i32 5> ; yields <4 x i32>
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = extractvalue {i32, float} %agg, 0 ; yields i32
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
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = icmp eq i32 4, 5 ; yields: result=false
<result> = icmp ne float* %X, %X ; yields: result=false
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
<result> = fcmp oeq float 4.0, 5.0 ; yields: result=false
<result> = fcmp one float 4.0, 5.0 ; yields: result=true
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
dispatch:
%cs = catchswitch within none [label %handler0] unwind to caller
Example:
""""""""
-.. code-block:: llvm
+.. code-block:: text
%tok = cleanuppad within %cs []
``@llvm.experimental.deoptimize`` -- its body is defined to be
equivalent to:
-.. code-block:: llvm
+.. code-block:: text
-
define void @llvm.experimental.guard(i1 %pred, <args...>) {
- %realPred = and i1 %pred, undef
- br i1 %realPred, label %continue, label %leave [, !make.implicit !{}]
+ define void @llvm.experimental.guard(i1 %pred, <args...>) {
+ %realPred = and i1 %pred, undef
+ br i1 %realPred, label %continue, label %leave [, !make.implicit !{}]
- leave:
-
call void @llvm.experimental.deoptimize(<args...>) [ "deopt"() ]
- ret void
+ leave:
+ call void @llvm.experimental.deoptimize(<args...>) [ "deopt"() ]
+ ret void
- continue:
- ret void
- }
+ continue:
+ ret void
+ }
with the optional ``[, !make.implicit !{}]`` present if and only if it
.. code-block:: llvm
- --- |
define i32 @inc(i32* %x) {
entry:
%0 = load i32, i32* %x
store i32 %1, i32* %x
ret i32 %1
}
- ...
.. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688
The remaining YAML documents contain the machine functions. This is an example
of such YAML document:
-.. code-block:: llvm
+.. code-block:: text
---
name: inc
that contains the block's ID.
The example below defines two blocks that have an ID of zero and one:
-.. code-block:: llvm
+.. code-block:: text
bb.0:
<instructions>
A machine basic block can also have a name. It should be specified after the ID
in the block's definition:
-.. code-block:: llvm
+.. code-block:: text
bb.0.entry: ; This block's name is "entry"
<instructions>
The machine basic blocks are identified by their ID numbers. Individual
blocks are referenced using the following syntax:
-.. code-block:: llvm
+.. code-block:: text
%bb.<id>[.<name>]
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
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)
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
The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be
specified in brackets after the block's definition:
-.. code-block:: llvm
+.. code-block:: text
bb.0.entry (address-taken):
<instructions>
below shows an instance of the X86 ``RETQ`` instruction with a single machine
operand:
-.. code-block:: llvm
+.. code-block:: text
RETQ %eax
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
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
The physical registers are identified by their name. They use the following
syntax:
-.. code-block:: llvm
+.. code-block:: text
%<name>
The example below shows three X86 physical registers:
-.. code-block:: llvm
+.. code-block:: text
%eax
%r15
The virtual registers are identified by their ID number. They use the following
syntax:
-.. code-block:: llvm
+.. code-block:: text
%<id>
Example:
-.. code-block:: llvm
+.. code-block:: text
%0
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
and a reference to the tied register operand.
The full syntax of a register operand is shown below:
-.. code-block:: llvm
+.. code-block:: text
[<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]
This example shows an instance of the X86 ``XOR32rr`` instruction that has
5 register operands with different register flags:
-.. code-block:: llvm
+.. code-block:: text
dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags, implicit-def %al
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
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, _
For example, a possible annotation of an ARM load of a stack-relative location
might be annotated as:
-.. code-block:: nasm
+.. code-block:: text
ldr <reg gpr:r0>, <mem regoffset:[<reg gpr:sp>, <imm:#4>]>
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
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
declare a function as a kernel function. This metadata is attached to the
``nvvm.annotations`` named metadata object, and has the following format:
-.. code-block:: llvm
+.. code-block:: text
!0 = !{<function-ref>, metadata !"kernel", i32 1}
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
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 {
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,
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)
a C/C++ front-end would generate the following descriptors:
-.. code-block:: llvm
+.. code-block:: text
;;
;; Define the global itself.
a C/C++ front-end would generate the following descriptors:
-.. code-block:: llvm
+.. code-block:: text
;;
;; Define the anchor for subprograms.
``%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" {
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" {
--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
As an example, given this code:
-.. code-block:: llvm
+.. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" {
The pass would produce this IR:
-.. code-block:: llvm
+.. code-block:: text
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj)
gc "statepoint-example" {
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)
Here is a simple TableGen file:
-.. code-block:: llvm
+.. code-block:: text
class C { bit V = 1; }
def X : C;
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;
bindings (which may optionally have defaults) that are bound when used. Here is
a simple example:
-.. code-block:: llvm
+.. code-block:: text
class FPFormat<bits<3> val> {
bits<3> Value = val;
The more esoteric forms of `TableGen expressions`_ are useful in conjunction
with template arguments. As an example:
-.. code-block:: llvm
+.. code-block:: text
class ModRefVal<bits<2> val> {
bits<2> Value = val;
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;
Here is an example TableGen fragment that shows this idea:
-.. code-block:: llvm
+.. code-block:: text
def ops;
def GPR;
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;
A ``defm`` can also be used inside a multiclass providing several levels of
multiclass instantiations.
-.. code-block:: llvm
+.. code-block:: text
class Instruction<bits<4> opc, string Name> {
bits<4> opcode = opc;
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; }
specified as a double quoted string immediately after the '``include``' keyword.
Example:
-.. code-block:: llvm
+.. code-block:: text
include "foo.td"
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)]>;
levels of multiclass instantiations. This also avoids the need of using "let"
expressions within subsequent records inside a multiclass.
-.. code-block:: llvm
+.. code-block:: text
multiclass basic_r<bits<4> opc> {
let Predicates = [HasSSE2] in {
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<...>;
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<...>;
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
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
**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">;
the classes that are used to build up a definition, so the backend can find all
definitions of a particular class, such as "Instruction".
-.. code-block:: llvm
+.. code-block:: text
class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>;
sub-multiclass become part of the current multiclass, as if they were declared
in the current multiclass.
-.. code-block:: llvm
+.. code-block:: text
multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
dag address, ValueType sty> {
``Name`` of the register. The basic ``Register`` object does not have any
subregisters and does not specify any aliases.
-.. code-block:: llvm
+.. code-block:: text
class Register<string n> {
string Namespace = "";
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]>;
``RegisterWithSubRegs`` class that is used to define registers that need to
specify subregisters in the ``SubRegs`` list, as shown here:
-.. code-block:: llvm
+.. code-block:: text
class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> {
let SubRegs = subregs;
override values that are initially defined in a superclass (such as ``SubRegs``
field in the ``Rd`` class).
-.. code-block:: llvm
+.. code-block:: text
class SparcReg<string n> : Register<n> {
field bits<5> Num;
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]>;
``XXXRegisterInfo.td`` that uses ``Target.td`` can construct register classes
using the following class:
-.. code-block:: llvm
+.. code-block:: text
class RegisterClass<string namespace,
list<ValueType> regTypes, int alignment, dag regList> {
``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)>;
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 = "";
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",
The fourth parameter is the input source, which uses the address operand
``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``:
-.. code-block:: llvm
+.. code-block:: text
def MEMrr : Operand<i32> {
let PrintMethod = "printMemOperand";
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",
pattern ``F3_12`` is defined to create 2 instruction classes each time
``F3_12`` is invoked:
-.. code-block:: llvm
+.. code-block:: text
multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
def rr : F3_1 <2, Op3Val,
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>;
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
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),
The instruction templates in ``SparcInstrFormats.td`` show the base class for
``F3_1`` is ``InstSP``.
-.. code-block:: llvm
+.. code-block:: text
class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
field bits<32> Inst;
``InstSP`` leaves the ``op`` field unbound.
-.. code-block:: llvm
+.. code-block:: text
class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
: InstSP<outs, ins, asmstr, pattern> {
fields. ``F3`` format instructions will bind the operands ``rd``, ``op3``, and
``rs1`` fields.
-.. code-block:: llvm
+.. code-block:: text
class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
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
instances of the TableGen ``Operand`` class, which represent branch target
operands:
-.. code-block:: llvm
+.. code-block:: text
def brtarget : Operand<OtherVT>;
def brtarget8 : Operand<OtherVT>;
this entry defines a register store operation, and the last parameter describes
a pattern with the store DAG operator.
-.. code-block:: llvm
+.. code-block:: text
def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
"st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>;
``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``:
-.. code-block:: llvm
+.. code-block:: text
def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
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), [{
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]>>
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]>>,
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.
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]>>,
``RetCC_X86_32_Fast`` is invoked. If the ``SSECall`` calling convention is in
use, then ``RetCC_X86_32_SSE`` is invoked.
-.. code-block:: llvm
+.. code-block:: text
def RetCC_X86_32 : CallingConv<[
CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
fifth parameter is a list of features whose presence is implied, and its
default value is an empty array.)
-.. code-block:: llvm
+.. code-block:: text
class SubtargetFeature<string n, string a, string v, string d,
list<SubtargetFeature> i = []> {
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">;
define particular SPARC processor subtypes that may have the previously
described features.
-.. code-block:: llvm
+.. code-block:: text
class Proc<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>;
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:
projects / llvm / commitdiff