Home | History | Annotate | Download | only in CommandGuide
      1 FileCheck - Flexible pattern matching file verifier
      2 ===================================================
      3 
      4 SYNOPSIS
      5 --------
      6 
      7 :program:`FileCheck` *match-filename* [*--check-prefix=XXX*] [*--strict-whitespace*]
      8 
      9 DESCRIPTION
     10 -----------
     11 
     12 :program:`FileCheck` reads two files (one from standard input, and one
     13 specified on the command line) and uses one to verify the other.  This
     14 behavior is particularly useful for the testsuite, which wants to verify that
     15 the output of some tool (e.g. :program:`llc`) contains the expected information
     16 (for example, a movsd from esp or whatever is interesting).  This is similar to
     17 using :program:`grep`, but it is optimized for matching multiple different
     18 inputs in one file in a specific order.
     19 
     20 The ``match-filename`` file specifies the file that contains the patterns to
     21 match.  The file to verify is always read from standard input.
     22 
     23 OPTIONS
     24 -------
     25 
     26 .. option:: -help
     27 
     28  Print a summary of command line options.
     29 
     30 .. option:: --check-prefix prefix
     31 
     32  FileCheck searches the contents of ``match-filename`` for patterns to match.
     33  By default, these patterns are prefixed with "``CHECK:``".  If you'd like to
     34  use a different prefix (e.g. because the same input file is checking multiple
     35  different tool or options), the :option:`--check-prefix` argument allows you
     36  to specify a specific prefix to match.
     37 
     38 .. option:: --input-file filename
     39 
     40   File to check (defaults to stdin).
     41 
     42 .. option:: --strict-whitespace
     43 
     44  By default, FileCheck canonicalizes input horizontal whitespace (spaces and
     45  tabs) which causes it to ignore these differences (a space will match a tab).
     46  The :option:`--strict-whitespace` argument disables this behavior. End-of-line
     47  sequences are canonicalized to UNIX-style '\n' in all modes.
     48 
     49 .. option:: -version
     50 
     51  Show the version number of this program.
     52 
     53 EXIT STATUS
     54 -----------
     55 
     56 If :program:`FileCheck` verifies that the file matches the expected contents,
     57 it exits with 0.  Otherwise, if not, or if an error occurs, it will exit with a
     58 non-zero value.
     59 
     60 TUTORIAL
     61 --------
     62 
     63 FileCheck is typically used from LLVM regression tests, being invoked on the RUN
     64 line of the test.  A simple example of using FileCheck from a RUN line looks
     65 like this:
     66 
     67 .. code-block:: llvm
     68 
     69    ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
     70 
     71 This syntax says to pipe the current file ("``%s``") into ``llvm-as``, pipe
     72 that into ``llc``, then pipe the output of ``llc`` into ``FileCheck``.  This
     73 means that FileCheck will be verifying its standard input (the llc output)
     74 against the filename argument specified (the original ``.ll`` file specified by
     75 "``%s``").  To see how this works, let's look at the rest of the ``.ll`` file
     76 (after the RUN line):
     77 
     78 .. code-block:: llvm
     79 
     80    define void @sub1(i32* %p, i32 %v) {
     81    entry:
     82    ; CHECK: sub1:
     83    ; CHECK: subl
     84            %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
     85            ret void
     86    }
     87 
     88    define void @inc4(i64* %p) {
     89    entry:
     90    ; CHECK: inc4:
     91    ; CHECK: incq
     92            %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
     93            ret void
     94    }
     95 
     96 Here you can see some "``CHECK:``" lines specified in comments.  Now you can
     97 see how the file is piped into ``llvm-as``, then ``llc``, and the machine code
     98 output is what we are verifying.  FileCheck checks the machine code output to
     99 verify that it matches what the "``CHECK:``" lines specify.
    100 
    101 The syntax of the "``CHECK:``" lines is very simple: they are fixed strings that
    102 must occur in order.  FileCheck defaults to ignoring horizontal whitespace
    103 differences (e.g. a space is allowed to match a tab) but otherwise, the contents
    104 of the "``CHECK:``" line is required to match some thing in the test file exactly.
    105 
    106 One nice thing about FileCheck (compared to grep) is that it allows merging
    107 test cases together into logical groups.  For example, because the test above
    108 is checking for the "``sub1:``" and "``inc4:``" labels, it will not match
    109 unless there is a "``subl``" in between those labels.  If it existed somewhere
    110 else in the file, that would not count: "``grep subl``" matches if "``subl``"
    111 exists anywhere in the file.
    112 
    113 The FileCheck -check-prefix option
    114 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    115 
    116 The FileCheck :option:`-check-prefix` option allows multiple test
    117 configurations to be driven from one `.ll` file.  This is useful in many
    118 circumstances, for example, testing different architectural variants with
    119 :program:`llc`.  Here's a simple example:
    120 
    121 .. code-block:: llvm
    122 
    123    ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
    124    ; RUN:              | FileCheck %s -check-prefix=X32
    125    ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
    126    ; RUN:              | FileCheck %s -check-prefix=X64
    127 
    128    define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
    129            %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
    130            ret <4 x i32> %tmp1
    131    ; X32: pinsrd_1:
    132    ; X32:    pinsrd $1, 4(%esp), %xmm0
    133 
    134    ; X64: pinsrd_1:
    135    ; X64:    pinsrd $1, %edi, %xmm0
    136    }
    137 
    138 In this case, we're testing that we get the expected code generation with
    139 both 32-bit and 64-bit code generation.
    140 
    141 The "CHECK-NEXT:" directive
    142 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    143 
    144 Sometimes you want to match lines and would like to verify that matches
    145 happen on exactly consecutive lines with no other lines in between them.  In
    146 this case, you can use "``CHECK:``" and "``CHECK-NEXT:``" directives to specify
    147 this.  If you specified a custom check prefix, just use "``<PREFIX>-NEXT:``".
    148 For example, something like this works as you'd expect:
    149 
    150 .. code-block:: llvm
    151 
    152    define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
    153  	%tmp3 = load <2 x double>* %A, align 16
    154  	%tmp7 = insertelement <2 x double> undef, double %B, i32 0
    155  	%tmp9 = shufflevector <2 x double> %tmp3,
    156                                <2 x double> %tmp7,
    157                                <2 x i32> < i32 0, i32 2 >
    158  	store <2 x double> %tmp9, <2 x double>* %r, align 16
    159  	ret void
    160 
    161    ; CHECK:          t2:
    162    ; CHECK: 	        movl	8(%esp), %eax
    163    ; CHECK-NEXT: 	movapd	(%eax), %xmm0
    164    ; CHECK-NEXT: 	movhpd	12(%esp), %xmm0
    165    ; CHECK-NEXT: 	movl	4(%esp), %eax
    166    ; CHECK-NEXT: 	movapd	%xmm0, (%eax)
    167    ; CHECK-NEXT: 	ret
    168    }
    169 
    170 "``CHECK-NEXT:``" directives reject the input unless there is exactly one
    171 newline between it and the previous directive.  A "``CHECK-NEXT:``" cannot be
    172 the first directive in a file.
    173 
    174 The "CHECK-NOT:" directive
    175 ~~~~~~~~~~~~~~~~~~~~~~~~~~
    176 
    177 The "``CHECK-NOT:``" directive is used to verify that a string doesn't occur
    178 between two matches (or before the first match, or after the last match).  For
    179 example, to verify that a load is removed by a transformation, a test like this
    180 can be used:
    181 
    182 .. code-block:: llvm
    183 
    184    define i8 @coerce_offset0(i32 %V, i32* %P) {
    185      store i32 %V, i32* %P
    186 
    187      %P2 = bitcast i32* %P to i8*
    188      %P3 = getelementptr i8* %P2, i32 2
    189 
    190      %A = load i8* %P3
    191      ret i8 %A
    192    ; CHECK: @coerce_offset0
    193    ; CHECK-NOT: load
    194    ; CHECK: ret i8
    195    }
    196 
    197 FileCheck Pattern Matching Syntax
    198 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    199 
    200 The "``CHECK:``" and "``CHECK-NOT:``" directives both take a pattern to match.
    201 For most uses of FileCheck, fixed string matching is perfectly sufficient.  For
    202 some things, a more flexible form of matching is desired.  To support this,
    203 FileCheck allows you to specify regular expressions in matching strings,
    204 surrounded by double braces: ``{{yourregex}}``.  Because we want to use fixed
    205 string matching for a majority of what we do, FileCheck has been designed to
    206 support mixing and matching fixed string matching with regular expressions.
    207 This allows you to write things like this:
    208 
    209 .. code-block:: llvm
    210 
    211    ; CHECK: movhpd	{{[0-9]+}}(%esp), {{%xmm[0-7]}}
    212 
    213 In this case, any offset from the ESP register will be allowed, and any xmm
    214 register will be allowed.
    215 
    216 Because regular expressions are enclosed with double braces, they are
    217 visually distinct, and you don't need to use escape characters within the double
    218 braces like you would in C.  In the rare case that you want to match double
    219 braces explicitly from the input, you can use something ugly like
    220 ``{{[{][{]}}`` as your pattern.
    221 
    222 FileCheck Variables
    223 ~~~~~~~~~~~~~~~~~~~
    224 
    225 It is often useful to match a pattern and then verify that it occurs again
    226 later in the file.  For codegen tests, this can be useful to allow any register,
    227 but verify that that register is used consistently later.  To do this,
    228 :program:`FileCheck` allows named variables to be defined and substituted into
    229 patterns.  Here is a simple example:
    230 
    231 .. code-block:: llvm
    232 
    233    ; CHECK: test5:
    234    ; CHECK:    notw	[[REGISTER:%[a-z]+]]
    235    ; CHECK:    andw	{{.*}}[[REGISTER]]
    236 
    237 The first check line matches a regex ``%[a-z]+`` and captures it into the
    238 variable ``REGISTER``.  The second line verifies that whatever is in
    239 ``REGISTER`` occurs later in the file after an "``andw``".  :program:`FileCheck`
    240 variable references are always contained in ``[[ ]]`` pairs, and their names can
    241 be formed with the regex ``[a-zA-Z][a-zA-Z0-9]*``.  If a colon follows the name,
    242 then it is a definition of the variable; otherwise, it is a use.
    243 
    244 :program:`FileCheck` variables can be defined multiple times, and uses always
    245 get the latest value.  Variables can also be used later on the same line they
    246 were defined on. For example:
    247 
    248 .. code-block:: llvm
    249 
    250     ; CHECK: op [[REG:r[0-9]+]], [[REG]]
    251 
    252 Can be useful if you want the operands of ``op`` to be the same register,
    253 and don't care exactly which register it is.
    254 
    255 FileCheck Expressions
    256 ~~~~~~~~~~~~~~~~~~~~~
    257 
    258 Sometimes there's a need to verify output which refers line numbers of the
    259 match file, e.g. when testing compiler diagnostics.  This introduces a certain
    260 fragility of the match file structure, as "``CHECK:``" lines contain absolute
    261 line numbers in the same file, which have to be updated whenever line numbers
    262 change due to text addition or deletion.
    263 
    264 To support this case, FileCheck allows using ``[[@LINE]]``,
    265 ``[[@LINE+<offset>]]``, ``[[@LINE-<offset>]]`` expressions in patterns. These
    266 expressions expand to a number of the line where a pattern is located (with an
    267 optional integer offset).
    268 
    269 This way match patterns can be put near the relevant test lines and include
    270 relative line number references, for example:
    271 
    272 .. code-block:: c++
    273 
    274    // CHECK: test.cpp:[[@LINE+4]]:6: error: expected ';' after top level declarator
    275    // CHECK-NEXT: {{^int a}}
    276    // CHECK-NEXT: {{^     \^}}
    277    // CHECK-NEXT: {{^     ;}}
    278    int a
    279 
    280