[llvm-commits] [llvm] r154990 - /llvm/trunk/docs/CommandGuide/FileCheck.pod
Eli Bendersky
eli.bendersky at intel.com
Wed Apr 18 00:44:03 PDT 2012
Author: eliben
Date: Wed Apr 18 02:44:03 2012
New Revision: 154990
URL: http://llvm.org/viewvc/llvm-project?rev=154990&view=rev
Log:
Some formatting and grammar fixes in the FileCheck documentation
Modified:
llvm/trunk/docs/CommandGuide/FileCheck.pod
Modified: llvm/trunk/docs/CommandGuide/FileCheck.pod
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CommandGuide/FileCheck.pod?rev=154990&r1=154989&r2=154990&view=diff
==============================================================================
--- llvm/trunk/docs/CommandGuide/FileCheck.pod (original)
+++ llvm/trunk/docs/CommandGuide/FileCheck.pod Wed Apr 18 02:44:03 2012
@@ -67,20 +67,20 @@
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 @@
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 @@
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 @@
%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 @@
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 @@
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
More information about the llvm-commits
mailing list