diff options
Diffstat (limited to 'docs/CommandGuide')
| -rw-r--r-- | docs/CommandGuide/FileCheck.pod | 58 | ||||
| -rw-r--r-- | docs/CommandGuide/lit.pod | 50 | ||||
| -rw-r--r-- | docs/CommandGuide/llc.pod | 2 |
3 files changed, 80 insertions, 30 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> %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 diff --git a/docs/CommandGuide/lit.pod b/docs/CommandGuide/lit.pod index e0b1a8c..81fc2c9 100644 --- a/docs/CommandGuide/lit.pod +++ b/docs/CommandGuide/lit.pod @@ -301,6 +301,9 @@ reported as unsupported. Used by: I<ShTest>, I<TclTest>. B<parent> The parent configuration, this is the config object for the directory containing the test suite, or None. +B<root> The root configuration. This is the top-most B<lit> configuration in +the project. + B<on_clone> The config is actually cloned for every subdirectory inside a test suite, to allow local configuration on a per-directory basis. The I<on_clone> variable can be set to a Python function which will be called whenever a @@ -338,6 +341,53 @@ define subdirectories of optional tests, or to change other configuration parameters -- for example, to change the test format, or the suffixes which identify test files. +=head2 TEST RUN OUTPUT FORMAT + +The b<lit> output for a test run conforms to the following schema, in both short +and verbose modes (although in short mode no PASS lines will be shown). This +schema has been chosen to be relatively easy to reliably parse by a machine (for +example in buildbot log scraping), and for other tools to generate. + +Each test result is expected to appear on a line that matches: + +<result code>: <test name> (<progress info>) + +where <result-code> is a standard test result such as PASS, FAIL, XFAIL, XPASS, +UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and +REGRESSED are also allowed. + +The <test name> field can consist of an arbitrary string containing no newline. + +The <progress info> field can be used to report progress information such as +(1/300) or can be empty, but even when empty the parentheses are required. + +Each test result may include additional (multiline) log information in the +following format. + +<log delineator> TEST '(<test name>)' <trailing delineator> +... log message ... +<log delineator> + +where <test name> should be the name of a preceeding reported test, <log +delineator> is a string of '*' characters I<at least> four characters long (the +recommended length is 20), and <trailing delineator> is an arbitrary (unparsed) +string. + +The following is an example of a test run output which consists of four tests A, +B, C, and D, and a log message for the failing test C. + +=head3 Example Test Run Output Listing + +PASS: A (1 of 4) +PASS: B (2 of 4) +FAIL: C (3 of 4) +******************** TEST 'C' FAILED ******************** +Test 'C' failed as a result of exit code 1. +******************** +PASS: D (4 of 4) + +=back + =head2 LIT EXAMPLE TESTS The B<lit> distribution contains several example implementations of test suites diff --git a/docs/CommandGuide/llc.pod b/docs/CommandGuide/llc.pod index 50b45c8..35abdae 100644 --- a/docs/CommandGuide/llc.pod +++ b/docs/CommandGuide/llc.pod @@ -45,7 +45,7 @@ Print a summary of command line options. =item B<-O>=I<uint> Generate code at different optimization levels. These correspond to the I<-O0>, -I<-O1>, I<-O2>, I<-O3>, and I<-O4> optimization levels used by B<llvm-gcc> and +I<-O1>, I<-O2>, and I<-O3> optimization levels used by B<llvm-gcc> and B<clang>. =item B<-mtriple>=I<target triple> |