1FileCheck - Flexible pattern matching file verifier 2=================================================== 3 4.. program:: FileCheck 5 6SYNOPSIS 7-------- 8 9:program:`FileCheck` *match-filename* [*--check-prefix=XXX*] [*--strict-whitespace*] 10 11DESCRIPTION 12----------- 13 14:program:`FileCheck` reads two files (one from standard input, and one 15specified on the command line) and uses one to verify the other. This 16behavior is particularly useful for the testsuite, which wants to verify that 17the output of some tool (e.g. :program:`llc`) contains the expected information 18(for example, a movsd from esp or whatever is interesting). This is similar to 19using :program:`grep`, but it is optimized for matching multiple different 20inputs in one file in a specific order. 21 22The ``match-filename`` file specifies the file that contains the patterns to 23match. The file to verify is read from standard input unless the 24:option:`--input-file` option is used. 25 26OPTIONS 27------- 28 29Options are parsed from the environment variable ``FILECHECK_OPTS`` 30and from the command line. 31 32.. option:: -help 33 34 Print a summary of command line options. 35 36.. option:: --check-prefix prefix 37 38 FileCheck searches the contents of ``match-filename`` for patterns to 39 match. By default, these patterns are prefixed with "``CHECK:``". 40 If you'd like to use a different prefix (e.g. because the same input 41 file is checking multiple different tool or options), the 42 :option:`--check-prefix` argument allows you to specify (without the trailing 43 "``:``") one or more prefixes to match. Multiple prefixes are useful for tests 44 which might change for different run options, but most lines remain the same. 45 46 FileCheck does not permit duplicate prefixes, even if one is a check prefix 47 and one is a comment prefix (see :option:`--comment-prefixes` below). 48 49.. option:: --check-prefixes prefix1,prefix2,... 50 51 An alias of :option:`--check-prefix` that allows multiple prefixes to be 52 specified as a comma separated list. 53 54.. option:: --comment-prefixes prefix1,prefix2,... 55 56 By default, FileCheck ignores any occurrence in ``match-filename`` of any check 57 prefix if it is preceded on the same line by "``COM:``" or "``RUN:``". See the 58 section `The "COM:" directive`_ for usage details. 59 60 These default comment prefixes can be overridden by 61 :option:`--comment-prefixes` if they are not appropriate for your testing 62 environment. However, doing so is not recommended in LLVM's LIT-based test 63 suites, which should be easier to maintain if they all follow a consistent 64 comment style. In that case, consider proposing a change to the default 65 comment prefixes instead. 66 67.. option:: --input-file filename 68 69 File to check (defaults to stdin). 70 71.. option:: --match-full-lines 72 73 By default, FileCheck allows matches of anywhere on a line. This 74 option will require all positive matches to cover an entire 75 line. Leading and trailing whitespace is ignored, unless 76 :option:`--strict-whitespace` is also specified. (Note: negative 77 matches from ``CHECK-NOT`` are not affected by this option!) 78 79 Passing this option is equivalent to inserting ``{{^ *}}`` or 80 ``{{^}}`` before, and ``{{ *$}}`` or ``{{$}}`` after every positive 81 check pattern. 82 83.. option:: --strict-whitespace 84 85 By default, FileCheck canonicalizes input horizontal whitespace (spaces and 86 tabs) which causes it to ignore these differences (a space will match a tab). 87 The :option:`--strict-whitespace` argument disables this behavior. End-of-line 88 sequences are canonicalized to UNIX-style ``\n`` in all modes. 89 90.. option:: --ignore-case 91 92 By default, FileCheck uses case-sensitive matching. This option causes 93 FileCheck to use case-insensitive matching. 94 95.. option:: --implicit-check-not check-pattern 96 97 Adds implicit negative checks for the specified patterns between positive 98 checks. The option allows writing stricter tests without stuffing them with 99 ``CHECK-NOT``\ s. 100 101 For example, "``--implicit-check-not warning:``" can be useful when testing 102 diagnostic messages from tools that don't have an option similar to ``clang 103 -verify``. With this option FileCheck will verify that input does not contain 104 warnings not covered by any ``CHECK:`` patterns. 105 106.. option:: --dump-input <value> 107 108 Dump input to stderr, adding annotations representing currently enabled 109 diagnostics. When there are multiple occurrences of this option, the 110 ``<value>`` that appears earliest in the list below has precedence. The 111 default is ``fail``. 112 113 * ``help`` - Explain input dump and quit 114 * ``always`` - Always dump input 115 * ``fail`` - Dump input on failure 116 * ``never`` - Never dump input 117 118.. option:: --dump-input-context <N> 119 120 In the dump requested by ``--dump-input``, print ``<N>`` input lines before 121 and ``<N>`` input lines after any lines specified by ``--dump-input-filter``. 122 When there are multiple occurrences of this option, the largest specified 123 ``<N>`` has precedence. The default is 5. 124 125.. option:: --dump-input-filter <value> 126 127 In the dump requested by ``--dump-input``, print only input lines of kind 128 ``<value>`` plus any context specified by ``--dump-input-context``. When 129 there are multiple occurrences of this option, the ``<value>`` that appears 130 earliest in the list below has precedence. The default is ``error`` when 131 ``--dump-input=fail``, and it's ``all`` when ``--dump-input=always``. 132 133 * ``all`` - All input lines 134 * ``annotation-full`` - Input lines with annotations 135 * ``annotation`` - Input lines with starting points of annotations 136 * ``error`` - Input lines with starting points of error annotations 137 138.. option:: --enable-var-scope 139 140 Enables scope for regex variables. 141 142 Variables with names that start with ``$`` are considered global and 143 remain set throughout the file. 144 145 All other variables get undefined after each encountered ``CHECK-LABEL``. 146 147.. option:: -D<VAR=VALUE> 148 149 Sets a filecheck pattern variable ``VAR`` with value ``VALUE`` that can be 150 used in ``CHECK:`` lines. 151 152.. option:: -D#<FMT>,<NUMVAR>=<NUMERIC EXPRESSION> 153 154 Sets a filecheck numeric variable ``NUMVAR`` of matching format ``FMT`` to 155 the result of evaluating ``<NUMERIC EXPRESSION>`` that can be used in 156 ``CHECK:`` lines. See section 157 ``FileCheck Numeric Variables and Expressions`` for details on supported 158 numeric expressions. 159 160.. option:: -version 161 162 Show the version number of this program. 163 164.. option:: -v 165 166 Print good directive pattern matches. However, if ``-dump-input=fail`` or 167 ``-dump-input=always``, add those matches as input annotations instead. 168 169.. option:: -vv 170 171 Print information helpful in diagnosing internal FileCheck issues, such as 172 discarded overlapping ``CHECK-DAG:`` matches, implicit EOF pattern matches, 173 and ``CHECK-NOT:`` patterns that do not have matches. Implies ``-v``. 174 However, if ``-dump-input=fail`` or ``-dump-input=always``, just add that 175 information as input annotations instead. 176 177.. option:: --allow-deprecated-dag-overlap 178 179 Enable overlapping among matches in a group of consecutive ``CHECK-DAG:`` 180 directives. This option is deprecated and is only provided for convenience 181 as old tests are migrated to the new non-overlapping ``CHECK-DAG:`` 182 implementation. 183 184.. option:: --allow-empty 185 186 Allow checking empty input. By default, empty input is rejected. 187 188.. option:: --color 189 190 Use colors in output (autodetected by default). 191 192EXIT STATUS 193----------- 194 195If :program:`FileCheck` verifies that the file matches the expected contents, 196it exits with 0. Otherwise, if not, or if an error occurs, it will exit with a 197non-zero value. 198 199TUTORIAL 200-------- 201 202FileCheck is typically used from LLVM regression tests, being invoked on the RUN 203line of the test. A simple example of using FileCheck from a RUN line looks 204like this: 205 206.. code-block:: llvm 207 208 ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s 209 210This syntax says to pipe the current file ("``%s``") into ``llvm-as``, pipe 211that into ``llc``, then pipe the output of ``llc`` into ``FileCheck``. This 212means that FileCheck will be verifying its standard input (the llc output) 213against the filename argument specified (the original ``.ll`` file specified by 214"``%s``"). To see how this works, let's look at the rest of the ``.ll`` file 215(after the RUN line): 216 217.. code-block:: llvm 218 219 define void @sub1(i32* %p, i32 %v) { 220 entry: 221 ; CHECK: sub1: 222 ; CHECK: subl 223 %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v) 224 ret void 225 } 226 227 define void @inc4(i64* %p) { 228 entry: 229 ; CHECK: inc4: 230 ; CHECK: incq 231 %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1) 232 ret void 233 } 234 235Here you can see some "``CHECK:``" lines specified in comments. Now you can 236see how the file is piped into ``llvm-as``, then ``llc``, and the machine code 237output is what we are verifying. FileCheck checks the machine code output to 238verify that it matches what the "``CHECK:``" lines specify. 239 240The syntax of the "``CHECK:``" lines is very simple: they are fixed strings that 241must occur in order. FileCheck defaults to ignoring horizontal whitespace 242differences (e.g. a space is allowed to match a tab) but otherwise, the contents 243of the "``CHECK:``" line is required to match some thing in the test file exactly. 244 245One nice thing about FileCheck (compared to grep) is that it allows merging 246test cases together into logical groups. For example, because the test above 247is checking for the "``sub1:``" and "``inc4:``" labels, it will not match 248unless there is a "``subl``" in between those labels. If it existed somewhere 249else in the file, that would not count: "``grep subl``" matches if "``subl``" 250exists anywhere in the file. 251 252The FileCheck -check-prefix option 253~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 254 255The FileCheck `-check-prefix` option allows multiple test 256configurations to be driven from one `.ll` file. This is useful in many 257circumstances, for example, testing different architectural variants with 258:program:`llc`. Here's a simple example: 259 260.. code-block:: llvm 261 262 ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \ 263 ; RUN: | FileCheck %s -check-prefix=X32 264 ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \ 265 ; RUN: | FileCheck %s -check-prefix=X64 266 267 define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind { 268 %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1 269 ret <4 x i32> %tmp1 270 ; X32: pinsrd_1: 271 ; X32: pinsrd $1, 4(%esp), %xmm0 272 273 ; X64: pinsrd_1: 274 ; X64: pinsrd $1, %edi, %xmm0 275 } 276 277In this case, we're testing that we get the expected code generation with 278both 32-bit and 64-bit code generation. 279 280The "COM:" directive 281~~~~~~~~~~~~~~~~~~~~ 282 283Sometimes you want to disable a FileCheck directive without removing it 284entirely, or you want to write comments that mention a directive by name. The 285"``COM:``" directive makes it easy to do this. For example, you might have: 286 287.. code-block:: llvm 288 289 ; X32: pinsrd_1: 290 ; X32: pinsrd $1, 4(%esp), %xmm0 291 292 ; COM: FIXME: X64 isn't working correctly yet for this part of codegen, but 293 ; COM: X64 will have something similar to X32: 294 ; COM: 295 ; COM: X64: pinsrd_1: 296 ; COM: X64: pinsrd $1, %edi, %xmm0 297 298Without "``COM:``", you would need to use some combination of rewording and 299directive syntax mangling to prevent FileCheck from recognizing the commented 300occurrences of "``X32:``" and "``X64:``" above as directives. Moreover, 301FileCheck diagnostics have been proposed that might complain about the above 302occurrences of "``X64``" that don't have the trailing "``:``" because they look 303like directive typos. Dodging all these problems can be tedious for a test 304author, and directive syntax mangling can make the purpose of test code unclear. 305"``COM:``" avoids all these problems. 306 307A few important usage notes: 308 309* "``COM:``" within another directive's pattern does *not* comment out the 310 remainder of the pattern. For example: 311 312 .. code-block:: llvm 313 314 ; X32: pinsrd $1, 4(%esp), %xmm0 COM: This is part of the X32 pattern! 315 316 If you need to temporarily comment out part of a directive's pattern, move it 317 to another line. The reason is that FileCheck parses "``COM:``" in the same 318 manner as any other directive: only the first directive on the line is 319 recognized as a directive. 320 321* For the sake of LIT, FileCheck treats "``RUN:``" just like "``COM:``". If this 322 is not suitable for your test environment, see :option:`--comment-prefixes`. 323 324* FileCheck does not recognize "``COM``", "``RUN``", or any user-defined comment 325 prefix as a comment directive if it's combined with one of the usual check 326 directive suffixes, such as "``-NEXT:``" or "``-NOT:``", discussed below. 327 FileCheck treats such a combination as plain text instead. If it needs to act 328 as a comment directive for your test environment, define it as such with 329 :option:`--comment-prefixes`. 330 331The "CHECK-NEXT:" directive 332~~~~~~~~~~~~~~~~~~~~~~~~~~~ 333 334Sometimes you want to match lines and would like to verify that matches 335happen on exactly consecutive lines with no other lines in between them. In 336this case, you can use "``CHECK:``" and "``CHECK-NEXT:``" directives to specify 337this. If you specified a custom check prefix, just use "``<PREFIX>-NEXT:``". 338For example, something like this works as you'd expect: 339 340.. code-block:: llvm 341 342 define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) { 343 %tmp3 = load <2 x double>* %A, align 16 344 %tmp7 = insertelement <2 x double> undef, double %B, i32 0 345 %tmp9 = shufflevector <2 x double> %tmp3, 346 <2 x double> %tmp7, 347 <2 x i32> < i32 0, i32 2 > 348 store <2 x double> %tmp9, <2 x double>* %r, align 16 349 ret void 350 351 ; CHECK: t2: 352 ; CHECK: movl 8(%esp), %eax 353 ; CHECK-NEXT: movapd (%eax), %xmm0 354 ; CHECK-NEXT: movhpd 12(%esp), %xmm0 355 ; CHECK-NEXT: movl 4(%esp), %eax 356 ; CHECK-NEXT: movapd %xmm0, (%eax) 357 ; CHECK-NEXT: ret 358 } 359 360"``CHECK-NEXT:``" directives reject the input unless there is exactly one 361newline between it and the previous directive. A "``CHECK-NEXT:``" cannot be 362the first directive in a file. 363 364The "CHECK-SAME:" directive 365~~~~~~~~~~~~~~~~~~~~~~~~~~~ 366 367Sometimes you want to match lines and would like to verify that matches happen 368on the same line as the previous match. In this case, you can use "``CHECK:``" 369and "``CHECK-SAME:``" directives to specify this. If you specified a custom 370check prefix, just use "``<PREFIX>-SAME:``". 371 372"``CHECK-SAME:``" is particularly powerful in conjunction with "``CHECK-NOT:``" 373(described below). 374 375For example, the following works like you'd expect: 376 377.. code-block:: llvm 378 379 !0 = !DILocation(line: 5, scope: !1, inlinedAt: !2) 380 381 ; CHECK: !DILocation(line: 5, 382 ; CHECK-NOT: column: 383 ; CHECK-SAME: scope: ![[SCOPE:[0-9]+]] 384 385"``CHECK-SAME:``" directives reject the input if there are any newlines between 386it and the previous directive. 387 388"``CHECK-SAME:``" is also useful to avoid writing matchers for irrelevant 389fields. For example, suppose you're writing a test which parses a tool that 390generates output like this: 391 392.. code-block:: text 393 394 Name: foo 395 Field1: ... 396 Field2: ... 397 Field3: ... 398 Value: 1 399 400 Name: bar 401 Field1: ... 402 Field2: ... 403 Field3: ... 404 Value: 2 405 406 Name: baz 407 Field1: ... 408 Field2: ... 409 Field3: ... 410 Value: 1 411 412To write a test that verifies ``foo`` has the value ``1``, you might first 413write this: 414 415.. code-block:: text 416 417 CHECK: Name: foo 418 CHECK: Value: 1{{$}} 419 420However, this would be a bad test: if the value for ``foo`` changes, the test 421would still pass because the "``CHECK: Value: 1``" line would match the value 422from ``baz``. To fix this, you could add ``CHECK-NEXT`` matchers for every 423``FieldN:`` line, but that would be verbose, and need to be updated when 424``Field4`` is added. A more succint way to write the test using the 425"``CHECK-SAME:``" matcher would be as follows: 426 427.. code-block:: text 428 429 CHECK: Name: foo 430 CHECK: Value: 431 CHECK-SAME: {{ 1$}} 432 433This verifies that the *next* time "``Value:``" appears in the ouput, it has 434the value ``1``. 435 436Note: a "``CHECK-SAME:``" cannot be the first directive in a file. 437 438The "CHECK-EMPTY:" directive 439~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 440 441If you need to check that the next line has nothing on it, not even whitespace, 442you can use the "``CHECK-EMPTY:``" directive. 443 444.. code-block:: llvm 445 446 declare void @foo() 447 448 declare void @bar() 449 ; CHECK: foo 450 ; CHECK-EMPTY: 451 ; CHECK-NEXT: bar 452 453Just like "``CHECK-NEXT:``" the directive will fail if there is more than one 454newline before it finds the next blank line, and it cannot be the first 455directive in a file. 456 457The "CHECK-NOT:" directive 458~~~~~~~~~~~~~~~~~~~~~~~~~~ 459 460The "``CHECK-NOT:``" directive is used to verify that a string doesn't occur 461between two matches (or before the first match, or after the last match). For 462example, to verify that a load is removed by a transformation, a test like this 463can be used: 464 465.. code-block:: llvm 466 467 define i8 @coerce_offset0(i32 %V, i32* %P) { 468 store i32 %V, i32* %P 469 470 %P2 = bitcast i32* %P to i8* 471 %P3 = getelementptr i8* %P2, i32 2 472 473 %A = load i8* %P3 474 ret i8 %A 475 ; CHECK: @coerce_offset0 476 ; CHECK-NOT: load 477 ; CHECK: ret i8 478 } 479 480The "CHECK-COUNT:" directive 481~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 482 483If you need to match multiple lines with the same pattern over and over again 484you can repeat a plain ``CHECK:`` as many times as needed. If that looks too 485boring you can instead use a counted check "``CHECK-COUNT-<num>:``", where 486``<num>`` is a positive decimal number. It will match the pattern exactly 487``<num>`` times, no more and no less. If you specified a custom check prefix, 488just use "``<PREFIX>-COUNT-<num>:``" for the same effect. 489Here is a simple example: 490 491.. code-block:: text 492 493 Loop at depth 1 494 Loop at depth 1 495 Loop at depth 1 496 Loop at depth 1 497 Loop at depth 2 498 Loop at depth 3 499 500 ; CHECK-COUNT-6: Loop at depth {{[0-9]+}} 501 ; CHECK-NOT: Loop at depth {{[0-9]+}} 502 503The "CHECK-DAG:" directive 504~~~~~~~~~~~~~~~~~~~~~~~~~~ 505 506If it's necessary to match strings that don't occur in a strictly sequential 507order, "``CHECK-DAG:``" could be used to verify them between two matches (or 508before the first match, or after the last match). For example, clang emits 509vtable globals in reverse order. Using ``CHECK-DAG:``, we can keep the checks 510in the natural order: 511 512.. code-block:: c++ 513 514 // RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s 515 516 struct Foo { virtual void method(); }; 517 Foo f; // emit vtable 518 // CHECK-DAG: @_ZTV3Foo = 519 520 struct Bar { virtual void method(); }; 521 Bar b; 522 // CHECK-DAG: @_ZTV3Bar = 523 524``CHECK-NOT:`` directives could be mixed with ``CHECK-DAG:`` directives to 525exclude strings between the surrounding ``CHECK-DAG:`` directives. As a result, 526the surrounding ``CHECK-DAG:`` directives cannot be reordered, i.e. all 527occurrences matching ``CHECK-DAG:`` before ``CHECK-NOT:`` must not fall behind 528occurrences matching ``CHECK-DAG:`` after ``CHECK-NOT:``. For example, 529 530.. code-block:: llvm 531 532 ; CHECK-DAG: BEFORE 533 ; CHECK-NOT: NOT 534 ; CHECK-DAG: AFTER 535 536This case will reject input strings where ``BEFORE`` occurs after ``AFTER``. 537 538With captured variables, ``CHECK-DAG:`` is able to match valid topological 539orderings of a DAG with edges from the definition of a variable to its use. 540It's useful, e.g., when your test cases need to match different output 541sequences from the instruction scheduler. For example, 542 543.. code-block:: llvm 544 545 ; CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2 546 ; CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4 547 ; CHECK: mul r5, [[REG1]], [[REG2]] 548 549In this case, any order of that two ``add`` instructions will be allowed. 550 551If you are defining `and` using variables in the same ``CHECK-DAG:`` block, 552be aware that the definition rule can match `after` its use. 553 554So, for instance, the code below will pass: 555 556.. code-block:: text 557 558 ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0] 559 ; CHECK-DAG: vmov.32 [[REG2]][1] 560 vmov.32 d0[1] 561 vmov.32 d0[0] 562 563While this other code, will not: 564 565.. code-block:: text 566 567 ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0] 568 ; CHECK-DAG: vmov.32 [[REG2]][1] 569 vmov.32 d1[1] 570 vmov.32 d0[0] 571 572While this can be very useful, it's also dangerous, because in the case of 573register sequence, you must have a strong order (read before write, copy before 574use, etc). If the definition your test is looking for doesn't match (because 575of a bug in the compiler), it may match further away from the use, and mask 576real bugs away. 577 578In those cases, to enforce the order, use a non-DAG directive between DAG-blocks. 579 580A ``CHECK-DAG:`` directive skips matches that overlap the matches of any 581preceding ``CHECK-DAG:`` directives in the same ``CHECK-DAG:`` block. Not only 582is this non-overlapping behavior consistent with other directives, but it's 583also necessary to handle sets of non-unique strings or patterns. For example, 584the following directives look for unordered log entries for two tasks in a 585parallel program, such as the OpenMP runtime: 586 587.. code-block:: text 588 589 // CHECK-DAG: [[THREAD_ID:[0-9]+]]: task_begin 590 // CHECK-DAG: [[THREAD_ID]]: task_end 591 // 592 // CHECK-DAG: [[THREAD_ID:[0-9]+]]: task_begin 593 // CHECK-DAG: [[THREAD_ID]]: task_end 594 595The second pair of directives is guaranteed not to match the same log entries 596as the first pair even though the patterns are identical and even if the text 597of the log entries is identical because the thread ID manages to be reused. 598 599The "CHECK-LABEL:" directive 600~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 601 602Sometimes in a file containing multiple tests divided into logical blocks, one 603or more ``CHECK:`` directives may inadvertently succeed by matching lines in a 604later block. While an error will usually eventually be generated, the check 605flagged as causing the error may not actually bear any relationship to the 606actual source of the problem. 607 608In order to produce better error messages in these cases, the "``CHECK-LABEL:``" 609directive can be used. It is treated identically to a normal ``CHECK`` 610directive except that FileCheck makes an additional assumption that a line 611matched by the directive cannot also be matched by any other check present in 612``match-filename``; this is intended to be used for lines containing labels or 613other unique identifiers. Conceptually, the presence of ``CHECK-LABEL`` divides 614the input stream into separate blocks, each of which is processed independently, 615preventing a ``CHECK:`` directive in one block matching a line in another block. 616If ``--enable-var-scope`` is in effect, all local variables are cleared at the 617beginning of the block. 618 619For example, 620 621.. code-block:: llvm 622 623 define %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) { 624 entry: 625 ; CHECK-LABEL: C_ctor_base: 626 ; CHECK: mov [[SAVETHIS:r[0-9]+]], r0 627 ; CHECK: bl A_ctor_base 628 ; CHECK: mov r0, [[SAVETHIS]] 629 %0 = bitcast %struct.C* %this to %struct.A* 630 %call = tail call %struct.A* @A_ctor_base(%struct.A* %0) 631 %1 = bitcast %struct.C* %this to %struct.B* 632 %call2 = tail call %struct.B* @B_ctor_base(%struct.B* %1, i32 %x) 633 ret %struct.C* %this 634 } 635 636 define %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) { 637 entry: 638 ; CHECK-LABEL: D_ctor_base: 639 640The use of ``CHECK-LABEL:`` directives in this case ensures that the three 641``CHECK:`` directives only accept lines corresponding to the body of the 642``@C_ctor_base`` function, even if the patterns match lines found later in 643the file. Furthermore, if one of these three ``CHECK:`` directives fail, 644FileCheck will recover by continuing to the next block, allowing multiple test 645failures to be detected in a single invocation. 646 647There is no requirement that ``CHECK-LABEL:`` directives contain strings that 648correspond to actual syntactic labels in a source or output language: they must 649simply uniquely match a single line in the file being verified. 650 651``CHECK-LABEL:`` directives cannot contain variable definitions or uses. 652 653FileCheck Regex Matching Syntax 654~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 655 656All FileCheck directives take a pattern to match. 657For most uses of FileCheck, fixed string matching is perfectly sufficient. For 658some things, a more flexible form of matching is desired. To support this, 659FileCheck allows you to specify regular expressions in matching strings, 660surrounded by double braces: ``{{yourregex}}``. FileCheck implements a POSIX 661regular expression matcher; it supports Extended POSIX regular expressions 662(ERE). Because we want to use fixed string matching for a majority of what we 663do, FileCheck has been designed to support mixing and matching fixed string 664matching with regular expressions. This allows you to write things like this: 665 666.. code-block:: llvm 667 668 ; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}} 669 670In this case, any offset from the ESP register will be allowed, and any xmm 671register will be allowed. 672 673Because regular expressions are enclosed with double braces, they are 674visually distinct, and you don't need to use escape characters within the double 675braces like you would in C. In the rare case that you want to match double 676braces explicitly from the input, you can use something ugly like 677``{{[}][}]}}`` as your pattern. Or if you are using the repetition count 678syntax, for example ``[[:xdigit:]]{8}`` to match exactly 8 hex digits, you 679would need to add parentheses like this ``{{([[:xdigit:]]{8})}}`` to avoid 680confusion with FileCheck's closing double-brace. 681 682FileCheck String Substitution Blocks 683~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 684 685It is often useful to match a pattern and then verify that it occurs again 686later in the file. For codegen tests, this can be useful to allow any 687register, but verify that that register is used consistently later. To do 688this, :program:`FileCheck` supports string substitution blocks that allow 689string variables to be defined and substituted into patterns. Here is a simple 690example: 691 692.. code-block:: llvm 693 694 ; CHECK: test5: 695 ; CHECK: notw [[REGISTER:%[a-z]+]] 696 ; CHECK: andw {{.*}}[[REGISTER]] 697 698The first check line matches a regex ``%[a-z]+`` and captures it into the 699string variable ``REGISTER``. The second line verifies that whatever is in 700``REGISTER`` occurs later in the file after an "``andw``". :program:`FileCheck` 701string substitution blocks are always contained in ``[[ ]]`` pairs, and string 702variable names can be formed with the regex ``[a-zA-Z_][a-zA-Z0-9_]*``. If a 703colon follows the name, then it is a definition of the variable; otherwise, it 704is a substitution. 705 706:program:`FileCheck` variables can be defined multiple times, and substitutions 707always get the latest value. Variables can also be substituted later on the 708same line they were defined on. For example: 709 710.. code-block:: llvm 711 712 ; CHECK: op [[REG:r[0-9]+]], [[REG]] 713 714Can be useful if you want the operands of ``op`` to be the same register, 715and don't care exactly which register it is. 716 717If ``--enable-var-scope`` is in effect, variables with names that 718start with ``$`` are considered to be global. All others variables are 719local. All local variables get undefined at the beginning of each 720CHECK-LABEL block. Global variables are not affected by CHECK-LABEL. 721This makes it easier to ensure that individual tests are not affected 722by variables set in preceding tests. 723 724FileCheck Numeric Substitution Blocks 725~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 726 727:program:`FileCheck` also supports numeric substitution blocks that allow 728defining numeric variables and checking for numeric values that satisfy a 729numeric expression constraint based on those variables via a numeric 730substitution. This allows ``CHECK:`` directives to verify a numeric relation 731between two numbers, such as the need for consecutive registers to be used. 732 733The syntax to define a numeric variable is ``[[#%<fmtspec>,<NUMVAR>:]]`` where: 734 735* ``%<fmtspec>`` is an optional scanf-style matching format specifier to 736 indicate what number format to match (e.g. hex number). Currently accepted 737 format specifiers are ``%u``, ``%d``, ``%x`` and ``%X``. If absent, the 738 format specifier defaults to ``%u``. 739 740* ``<NUMVAR>`` is the name of the numeric variable to define to the matching 741 value. 742 743For example: 744 745.. code-block:: llvm 746 747 ; CHECK: mov r[[#REG:]], 0x[[#%X,IMM:]] 748 749would match ``mov r5, 0xF0F0`` and set ``REG`` to the value ``5`` and ``IMM`` 750to the value ``0xF0F0``. 751 752The syntax of a numeric substitution is 753``[[#%<fmtspec>: <constraint> <expr>]]`` where: 754 755* ``%<fmtspec>`` is the same matching format specifier as for defining numeric 756 variables but acting as a printf-style format to indicate how a numeric 757 expression value should be matched against. If absent, the format specifier 758 is inferred from the matching format of the numeric variable(s) used by the 759 expression constraint if any, and defaults to ``%u`` if no numeric variable 760 is used. In case of conflict between matching formats of several numeric 761 variables the format specifier is mandatory. 762 763* ``<constraint>`` is the constraint describing how the value to match must 764 relate to the value of the numeric expression. The only currently accepted 765 constraint is ``==`` for an exact match and is the default if 766 ``<constraint>`` is not provided. No matching constraint must be specified 767 when the ``<expr>`` is empty. 768 769* ``<expr>`` is an expression. An expression is in turn recursively defined 770 as: 771 772 * a numeric operand, or 773 * an expression followed by an operator and a numeric operand. 774 775 A numeric operand is a previously defined numeric variable, an integer 776 literal, or a function. Spaces are accepted before, after and between any of 777 these elements. Numeric operands have 64-bit precision. Overflow and underflow 778 are rejected. There is no support for operator precedence, but parentheses 779 can be used to change the evaluation order. 780 781The supported operators are: 782 783 * ``+`` - Returns the sum of its two operands. 784 * ``-`` - Returns the difference of its two operands. 785 786The syntax of a function call is ``<name>(<arguments>)`` where: 787 788* ``name`` is a predefined string literal. Accepted values are: 789 790 * add - Returns the sum of its two operands. 791 * div - Returns the quotient of its two operands. 792 * max - Returns the largest of its two operands. 793 * min - Returns the smallest of its two operands. 794 * mul - Returns the product of its two operands. 795 * sub - Returns the difference of its two operands. 796 797* ``<arguments>`` is a comma separated list of expressions. 798 799For example: 800 801.. code-block:: llvm 802 803 ; CHECK: load r[[#REG:]], [r0] 804 ; CHECK: load r[[#REG+1]], [r1] 805 ; CHECK: Loading from 0x[[#%x,ADDR:]] 806 ; CHECK-SAME: to 0x[[#ADDR + 7]] 807 808The above example would match the text: 809 810.. code-block:: gas 811 812 load r5, [r0] 813 load r6, [r1] 814 Loading from 0xa0463440 to 0xa0463447 815 816but would not match the text: 817 818.. code-block:: gas 819 820 load r5, [r0] 821 load r7, [r1] 822 Loading from 0xa0463440 to 0xa0463443 823 824Due to ``7`` being unequal to ``5 + 1`` and ``a0463443`` being unequal to 825``a0463440 + 7``. 826 827The syntax also supports an empty expression, equivalent to writing {{[0-9]+}}, 828for cases where the input must contain a numeric value but the value itself 829does not matter: 830 831.. code-block:: gas 832 833 ; CHECK-NOT: mov r0, r[[#]] 834 835to check that a value is synthesized rather than moved around. 836 837A numeric variable can also be defined to the result of a numeric expression, 838in which case the numeric expression constraint is checked and if verified the 839variable is assigned to the value. The unified syntax for both defining numeric 840variables and checking a numeric expression is thus 841``[[#%<fmtspec>,<NUMVAR>: <constraint> <expr>]]`` with each element as 842described previously. One can use this syntax to make a testcase more 843self-describing by using variables instead of values: 844 845.. code-block:: gas 846 847 ; CHECK: mov r[[#REG_OFFSET:]], 0x[[#%X,FIELD_OFFSET:12]] 848 ; CHECK-NEXT: load r[[#]], [r[[#REG_BASE:]], r[[#REG_OFFSET]]] 849 850which would match: 851 852.. code-block:: gas 853 854 mov r4, 0xC 855 load r6, [r5, r4] 856 857The ``--enable-var-scope`` option has the same effect on numeric variables as 858on string variables. 859 860Important note: In its current implementation, an expression cannot use a 861numeric variable defined earlier in the same CHECK directive. 862 863FileCheck Pseudo Numeric Variables 864~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 865 866Sometimes there's a need to verify output that contains line numbers of the 867match file, e.g. when testing compiler diagnostics. This introduces a certain 868fragility of the match file structure, as "``CHECK:``" lines contain absolute 869line numbers in the same file, which have to be updated whenever line numbers 870change due to text addition or deletion. 871 872To support this case, FileCheck expressions understand the ``@LINE`` pseudo 873numeric variable which evaluates to the line number of the CHECK pattern where 874it is found. 875 876This way match patterns can be put near the relevant test lines and include 877relative line number references, for example: 878 879.. code-block:: c++ 880 881 // CHECK: test.cpp:[[# @LINE + 4]]:6: error: expected ';' after top level declarator 882 // CHECK-NEXT: {{^int a}} 883 // CHECK-NEXT: {{^ \^}} 884 // CHECK-NEXT: {{^ ;}} 885 int a 886 887To support legacy uses of ``@LINE`` as a special string variable, 888:program:`FileCheck` also accepts the following uses of ``@LINE`` with string 889substitution block syntax: ``[[@LINE]]``, ``[[@LINE+<offset>]]`` and 890``[[@LINE-<offset>]]`` without any spaces inside the brackets and where 891``offset`` is an integer. 892 893Matching Newline Characters 894~~~~~~~~~~~~~~~~~~~~~~~~~~~ 895 896To match newline characters in regular expressions the character class 897``[[:space:]]`` can be used. For example, the following pattern: 898 899.. code-block:: c++ 900 901 // CHECK: DW_AT_location [DW_FORM_sec_offset] ([[DLOC:0x[0-9a-f]+]]){{[[:space:]].*}}"intd" 902 903matches output of the form (from llvm-dwarfdump): 904 905.. code-block:: text 906 907 DW_AT_location [DW_FORM_sec_offset] (0x00000233) 908 DW_AT_name [DW_FORM_strp] ( .debug_str[0x000000c9] = "intd") 909 910letting us set the :program:`FileCheck` variable ``DLOC`` to the desired value 911``0x00000233``, extracted from the line immediately preceding "``intd``". 912