From: Eli Bendersky Date: Wed, 18 Apr 2012 07:44:03 +0000 (+0000) Subject: Some formatting and grammar fixes in the FileCheck documentation X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=b89ea68e75e58c7787827eca811ab022a82236d6;p=oota-llvm.git Some formatting and grammar fixes in the FileCheck documentation git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154990 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod index dbd626c7cb7..2662cc01288 100644 --- a/docs/CommandGuide/FileCheck.pod +++ b/docs/CommandGuide/FileCheck.pod @@ -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: - ; CHECK: sub1: - ; CHECK: subl + ; 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: - ; CHECK: inc4: - ; CHECK: incq + ; 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: | FileCheck %s -check-prefix=X32 + ; RUN: | FileCheck %s -check-prefix=X32> ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \ - ; RUN: | FileCheck %s -check-prefix=X64 + ; 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 - ; X32: pinsrd_1: - ; X32: pinsrd $1, 4(%esp), %xmm0 + ; X32: pinsrd_1: + ; X32: pinsrd $1, 4(%esp), %xmm0 - ; X64: pinsrd_1: - ; X64: 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 - ; 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: 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 - ; CHECK: @coerce_offset0 - ; CHECK-NOT: load - ; CHECK: 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 {{[0-9]+}}(%esp), {{%xmm[0-7]}} + ; 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 [[REGISTER:%[a-z]+]] - ; CHECK: andw {{.*}}[[REGISTER]] + ; CHECK: notw [[REGISTER:%[a-z]+]] + ; CHECK: andw {{.*}}[REGISTER]] -The first check line matches a regex (%[a-z]+) 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 [[ ]] pairs, are named, and their names can be -formed with the regex "[a-zA-Z_][a-zA-Z0-9_]*". 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 -"CHECK: [[XYZ:.*]]x[[XYZ]]" that the check line will read the previous +"B", 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