Vendor import of llvm release_31 branch r155985:

http://llvm.org/svn/llvm-project/llvm/branches/release_31@155985

1 files changed, 29 insertions, 29 deletions

diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod
index dbd626c..2662cc0 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:
-  ; <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&gt; %tmp9, <2 x double&gt;* %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