mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-10-31 08:16:47 +00:00
824c10ece2
A CHECK-NOT pattern without a following CHECK pattern simply checks that the pattern doesn't match before the end of the input file. You can even have only CHECK-NOT patterns to check that strings appear nowhere in the input file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116592 91177308-0d34-0410-b5e6-96231b3b80d8
246 lines
9.0 KiB
Plaintext
246 lines
9.0 KiB
Plaintext
|
|
=pod
|
|
|
|
=head1 NAME
|
|
|
|
FileCheck - Flexible pattern matching file verifier
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
B<FileCheck> I<match-filename> [I<--check-prefix=XXX>] [I<--strict-whitespace>]
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
B<FileCheck> reads two files (one from standard input, and one specified on the
|
|
command line) and uses one to verify the other. This behavior is particularly
|
|
useful for the testsuite, which wants to verify that the output of some tool
|
|
(e.g. llc) contains the expected information (for example, a movsd from esp or
|
|
whatever is interesting). This is similar to using grep, but it is optimized
|
|
for matching multiple different inputs in one file in a specific order.
|
|
|
|
The I<match-filename> file specifies the file that contains the patterns to
|
|
match. The file to verify is always read from standard input.
|
|
|
|
=head1 OPTIONS
|
|
|
|
=over
|
|
|
|
=item B<-help>
|
|
|
|
Print a summary of command line options.
|
|
|
|
=item B<--check-prefix> I<prefix>
|
|
|
|
FileCheck searches the contents of I<match-filename> for patterns to match. By
|
|
default, these patterns are prefixed with "CHECK:". If you'd like to use a
|
|
different prefix (e.g. because the same input file is checking multiple
|
|
different tool or options), the B<--check-prefix> argument allows you to specify
|
|
a specific prefix to match.
|
|
|
|
=item B<--strict-whitespace>
|
|
|
|
By default, FileCheck canonicalizes input horizontal whitespace (spaces and
|
|
tabs) which causes it to ignore these differences (a space will match a tab).
|
|
The --strict-whitespace argument disables this behavior.
|
|
|
|
=item B<-version>
|
|
|
|
Show the version number of this program.
|
|
|
|
=back
|
|
|
|
=head1 EXIT STATUS
|
|
|
|
If B<FileCheck> verifies that the file matches the expected contents, it exits
|
|
with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero
|
|
value.
|
|
|
|
=head1 TUTORIAL
|
|
|
|
FileCheck is typically used from LLVM regression tests, being invoked on the RUN
|
|
line of the test. A simple example of using FileCheck from a RUN line looks
|
|
like this:
|
|
|
|
; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
|
|
|
|
This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
|
|
llc, then pipe the output of llc into FileCheck. This means that FileCheck will
|
|
be verifying its standard input (the llc output) against the filename argument
|
|
specified (the original .ll file specified by "%s"). To see how this works,
|
|
lets look at the rest of the .ll file (after the RUN line):
|
|
|
|
define void @sub1(i32* %p, i32 %v) {
|
|
entry:
|
|
; <b>CHECK: sub1:</b>
|
|
; <b>CHECK: subl</b>
|
|
%0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
|
|
ret void
|
|
}
|
|
|
|
define void @inc4(i64* %p) {
|
|
entry:
|
|
; <b>CHECK: inc4:</b>
|
|
; <b>CHECK: incq</b>
|
|
%0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
|
|
ret void
|
|
}
|
|
|
|
Here you can see some "CHECK:" lines specified in comments. Now you can see
|
|
how the file is piped into llvm-as, then llc, and the machine code output is
|
|
what we are verifying. FileCheck checks the machine code output to verify that
|
|
it matches what the "CHECK:" lines specify.
|
|
|
|
The syntax of the CHECK: lines is very simple: they are fixed strings that
|
|
must occur in order. FileCheck defaults to ignoring horizontal whitespace
|
|
differences (e.g. a space is allowed to match a tab) but otherwise, the contents
|
|
of the CHECK: line is required to match some thing in the test file exactly.
|
|
|
|
One nice thing about FileCheck (compared to grep) is that it allows merging
|
|
test cases together into logical groups. For example, because the test above
|
|
is checking for the "sub1:" and "inc4:" labels, it will not match unless there
|
|
is a "subl" in between those labels. If it existed somewhere else in the file,
|
|
that would not count: "grep subl" matches if subl exists anywhere in the
|
|
file.
|
|
|
|
|
|
|
|
=head2 The FileCheck -check-prefix option
|
|
|
|
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 llc. Here's a simple example:
|
|
|
|
; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
|
|
; RUN: | <b>FileCheck %s -check-prefix=X32</b>
|
|
; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
|
|
; RUN: | <b>FileCheck %s -check-prefix=X64</b>
|
|
|
|
define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
|
|
%tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
|
|
ret <4 x i32> %tmp1
|
|
; <b>X32:</b> pinsrd_1:
|
|
; <b>X32:</b> pinsrd $1, 4(%esp), %xmm0
|
|
|
|
; <b>X64:</b> pinsrd_1:
|
|
; <b>X64:</b> pinsrd $1, %edi, %xmm0
|
|
}
|
|
|
|
In this case, we're testing that we get the expected code generation with
|
|
both 32-bit and 64-bit code generation.
|
|
|
|
|
|
|
|
=head2 The "CHECK-NEXT:" directive
|
|
|
|
Sometimes you want to match lines and would like to verify that matches
|
|
happen on exactly consequtive lines with no other lines in between them. In
|
|
this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
|
|
you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
|
|
example, something like this works as you'd expect:
|
|
|
|
define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
|
|
%tmp3 = load <2 x double>* %A, align 16
|
|
%tmp7 = insertelement <2 x double> undef, double %B, i32 0
|
|
%tmp9 = shufflevector <2 x double> %tmp3,
|
|
<2 x double> %tmp7,
|
|
<2 x i32> < i32 0, i32 2 >
|
|
store <2 x double> %tmp9, <2 x double>* %r, align 16
|
|
ret void
|
|
|
|
; <b>CHECK:</b> t2:
|
|
; <b>CHECK:</b> movl 8(%esp), %eax
|
|
; <b>CHECK-NEXT:</b> movapd (%eax), %xmm0
|
|
; <b>CHECK-NEXT:</b> movhpd 12(%esp), %xmm0
|
|
; <b>CHECK-NEXT:</b> movl 4(%esp), %eax
|
|
; <b>CHECK-NEXT:</b> movapd %xmm0, (%eax)
|
|
; <b>CHECK-NEXT:</b> ret
|
|
}
|
|
|
|
CHECK-NEXT: directives reject the input unless there is exactly one newline
|
|
between it an the previous directive. A CHECK-NEXT cannot be the first
|
|
directive in a file.
|
|
|
|
|
|
|
|
=head2 The "CHECK-NOT:" directive
|
|
|
|
The CHECK-NOT: directive is used to verify that a string doesn't occur
|
|
between two matches (or before the first match, or after the last match). For
|
|
example, to verify that a load is removed by a transformation, a test like this
|
|
can be used:
|
|
|
|
define i8 @coerce_offset0(i32 %V, i32* %P) {
|
|
store i32 %V, i32* %P
|
|
|
|
%P2 = bitcast i32* %P to i8*
|
|
%P3 = getelementptr i8* %P2, i32 2
|
|
|
|
%A = load i8* %P3
|
|
ret i8 %A
|
|
; <b>CHECK:</b> @coerce_offset0
|
|
; <b>CHECK-NOT:</b> load
|
|
; <b>CHECK:</b> ret i8
|
|
}
|
|
|
|
|
|
|
|
=head2 FileCheck Pattern Matching Syntax
|
|
|
|
The CHECK: and CHECK-NOT: directives both take a pattern to match. For most
|
|
uses of FileCheck, fixed string matching is perfectly sufficient. For some
|
|
things, a more flexible form of matching is desired. To support this, FileCheck
|
|
allows you to specify regular expressions in matching strings, surrounded by
|
|
double braces: B<{{yourregex}}>. Because we want to use fixed string
|
|
matching for a majority of what we do, FileCheck has been designed to support
|
|
mixing and matching fixed string matching with regular expressions. This allows
|
|
you to write things like this:
|
|
|
|
; CHECK: movhpd <b>{{[0-9]+}}</b>(%esp), <b>{{%xmm[0-7]}}</b>
|
|
|
|
In this case, any offset from the ESP register will be allowed, and any xmm
|
|
register will be allowed.
|
|
|
|
Because regular expressions are enclosed with double braces, they are
|
|
visually distinct, and you don't need to use escape characters within the double
|
|
braces like you would in C. In the rare case that you want to match double
|
|
braces explicitly from the input, you can use something ugly like
|
|
B<{{[{][{]}}> as your pattern.
|
|
|
|
|
|
|
|
=head2 FileCheck Variables
|
|
|
|
It is often useful to match a pattern and then verify that it occurs again
|
|
later in the file. For codegen tests, this can be useful to allow any register,
|
|
but verify that that register is used consistently later. To do this, FileCheck
|
|
allows named variables to be defined and substituted into patterns. Here is a
|
|
simple example:
|
|
|
|
; CHECK: test5:
|
|
; CHECK: notw <b>[[REGISTER:%[a-z]+]]</b>
|
|
; CHECK: andw {{.*}}<b>[[REGISTER]]</b>
|
|
|
|
The first check line matches a regex (<tt>%[a-z]+</tt>) and captures it into
|
|
the variables "REGISTER". The second line verifies that whatever is in REGISTER
|
|
occurs later in the file after an "andw". FileCheck variable references are
|
|
always contained in <tt>[[ ]]</tt> pairs, are named, and their names can be
|
|
formed with the regex "<tt>[a-zA-Z_][a-zA-Z0-9_]*</tt>". If a colon follows the
|
|
name, then it is a definition of the variable, if not, it is a use.
|
|
|
|
FileCheck variables can be defined multiple times, and uses always get the
|
|
latest value. Note that variables are all read at the start of a "CHECK" line
|
|
and are all defined at the end. This means that if you have something like
|
|
"<tt>CHECK: [[XYZ:.*]]x[[XYZ]]<tt>" that the check line will read the previous
|
|
value of the XYZ variable and define a new one after the match is performed. If
|
|
you need to do something like this you can probably take advantage of the fact
|
|
that FileCheck is not actually line-oriented when it matches, this allows you to
|
|
define two separate CHECK lines that match on the same line.
|
|
|
|
|
|
|
|
=head1 AUTHORS
|
|
|
|
Maintained by The LLVM Team (L<http://llvm.org>).
|
|
|
|
=cut
|