llvm.org GIT mirror llvm / 272e308
document filecheck. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79110 91177308-0d34-0410-b5e6-96231b3b80d8 Chris Lattner 10 years ago
1 changed file(s) with 92 addition(s) and 8 deletion(s). Raw diff Collapse all Expand all
456456

A powerful feature of the RUN: lines is that it allows any arbitrary commands

457457 to be executed as part of the test harness. While standard (portable) unix
458458 tools like 'grep' work fine on run lines, as you see above, there are a lot
459 of caveats due to interaction with Tcl syntax, and we want to make that the
459 of caveats due to interaction with Tcl syntax, and we want to make sure the
460460 run lines are portable to a wide range of systems. Another major problem is
461461 that grep is not very good at checking to verify that the output of a tools
462462 contains a series of different output in a specific order. The FileCheck
463463 tool was designed to help with these problems.

464464
465
466
467
468
469
470
471 <div class="doc_subsection">Variables and substitutions
465 <p>FileCheck (whose basic command line arguments are described in
466 href="http://llvm.org/cmds/FileCheck.html">the FileCheck man page is
467 designed to read a file to check from standard input, and the set of things
468 to verify from a file specified as a command line argument. A simple example
469 of using FileCheck from a RUN line looks like this:

470
471
472

                  
                
473 ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
474
475
476
477

This syntax says to pipe the current file ("%s") into llvm-as, pipe that into

478 llc, then pipe the output of llc into FileCheck. This means that FileCheck will
479 be verifying its standard input (the llc output) against the filename argument
480 specified (the original .ll file specified by "%s"). To see how this works,
481 lets look at the rest of the .ll file (after the RUN line):

482
483
484

                  
                
485 define void @sub1(i32* %p, i32 %v) {
486 entry:
487 ; CHECK: sub1:
488 ; CHECK: subl
489 %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
490 ret void
491 }
492
493 define void @inc4(i64* %p) {
494 entry:
495 ; CHECK: inc4:
496 ; CHECK: incq
497 %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
498 ret void
499 }
500
501
502
503

Here you can see some "CHECK:" lines specified in comments. Now you can see

504 how the file is piped into llvm-as, then llc, and the machine code output is
505 what we are verifying. FileCheck checks the machine code output to verify that
506 it matches what the "CHECK:" lines specify.

507
508

The syntax of the CHECK: lines is very simple: they are fixed strings that

509 must occur in order. FileCheck defaults to ignoring horizontal whitespace
510 differences (e.g. a space is allowed to match a tab) but otherwise, the contents
511 of the CHECK: line is required to match some thing in the test file exactly.

512
513

One nice thing about FileCheck (compared to grep) is that it allows merging

514 test cases together into logical groups. For example, because the test above
515 is checking for the "sub1:" and "inc4:" labels, it will not match unless there
516 is a "subl" in between those labels. If it existed somewhere else in the file,
517 that would not count: "grep subl" matches if subl exists anywhere in the
518 file.

519
520
521 name="FileCheck-check-prefix">The FileCheck -check-prefix option
522
523

The FileCheck -check-prefix option allows multiple test configurations to be

524 driven from one .ll file. This is useful in many circumstances, for example,
525 testing different architectural variants with llc. Here's a simple example:

526
527
528
529

                  
                
530 ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
531 ; RUN: | FileCheck %s -check-prefix=X32
532 ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
533 ; RUN: | FileCheck %s -check-prefix=X64
534
535 define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
536 %tmp1 = insertelement <4 x i32> %tmp, i32 %s, i32 1
537 ret <4 x i32> %tmp1
538 ; X32: pinsrd_1:
539 ; X32: pinsrd $1, 4(%esp), %xmm0
540
541 ; X64: pinsrd_1:
542 ; X64: pinsrd $1, %edi, %xmm0
543 }
544
545
546
547

In this case, we're testing that we get the expected code generation with

548 both 32-bit and 64-bit code generation.

549
550
551
552
553
554
555 substitutions
472556
473557
474558

With a RUN line there are a number of substitutions that are permitted. In