mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-19 01:27:40 +00:00
Some formatting and grammar fixes in the FileCheck documentation
llvm-svn: 154990
This commit is contained in:
Eli Bendersky
parent
c37741ca5a
commit
893761e242
@ -67,20 +67,20 @@ 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):
|
||||
let's 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>
|
||||
; CHECK: sub1:
|
||||
; CHECK: subl
|
||||
%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>
|
||||
; CHECK: inc4:
|
||||
; CHECK: incq
|
||||
%0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
|
||||
ret void
|
||||
}
|
||||
@ -111,18 +111,18 @@ 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: | FileCheck %s -check-prefix=X32>
|
||||
; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
|
||||
; RUN: | <b>FileCheck %s -check-prefix=X64</b>
|
||||
; RUN: | FileCheck %s -check-prefix=X64>
|
||||
|
||||
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
|
||||
; X32: pinsrd_1:
|
||||
; X32: pinsrd $1, 4(%esp), %xmm0
|
||||
|
||||
; <b>X64:</b> pinsrd_1:
|
||||
; <b>X64:</b> pinsrd $1, %edi, %xmm0
|
||||
; X64: pinsrd_1:
|
||||
; X64: pinsrd $1, %edi, %xmm0
|
||||
}
|
||||
|
||||
In this case, we're testing that we get the expected code generation with
|
||||
@ -147,13 +147,13 @@ example, something like this works as you'd expect:
|
||||
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: t2:
|
||||
; CHECK: movl 8(%esp), %eax
|
||||
; CHECK-NEXT: movapd (%eax), %xmm0
|
||||
; CHECK-NEXT: movhpd 12(%esp), %xmm0
|
||||
; CHECK-NEXT: movl 4(%esp), %eax
|
||||
; CHECK-NEXT: movapd %xmm0, (%eax)
|
||||
; CHECK-NEXT: ret
|
||||
}
|
||||
|
||||
CHECK-NEXT: directives reject the input unless there is exactly one newline
|
||||
@ -177,9 +177,9 @@ can be used:
|
||||
|
||||
%A = load i8* %P3
|
||||
ret i8 %A
|
||||
; <b>CHECK:</b> @coerce_offset0
|
||||
; <b>CHECK-NOT:</b> load
|
||||
; <b>CHECK:</b> ret i8
|
||||
; CHECK: @coerce_offset0
|
||||
; CHECK-NOT: load
|
||||
; CHECK: ret i8
|
||||
}
|
||||
|
||||
|
||||
@ -195,7 +195,7 @@ 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>
|
||||
; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}
|
||||
|
||||
In this case, any offset from the ESP register will be allowed, and any xmm
|
||||
register will be allowed.
|
||||
@ -217,20 +217,20 @@ 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>
|
||||
; CHECK: notw [[REGISTER:%[a-z]+]]
|
||||
; CHECK: andw {{.*}}[REGISTER]]
|
||||
|
||||
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
|
||||
The first check line matches a regex (B<%[a-z]+>) and captures it into
|
||||
the variable "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
|
||||
always contained in B<[[ ]]> pairs, are named, and their names can be
|
||||
formed with the regex "B<[a-zA-Z_][a-zA-Z0-9_]*>". 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
|
||||
"B<CHECK: [[XYZ:.*]]x[[XYZ]]>", 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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user