Reapply r166405, teaching tailcallelim to be smarter about nocapture, with a

[oota-llvm.git] / docs / TestingGuide.html
diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html

index 233a157aad40f7fd82b99f4da5c077379ef2dd66..ae2643fe4e83daae5b7c0a2fc1b5a522904af1e0 100644 (file)
--- a/docs/TestingGuide.html
+++ b/docs/TestingGuide.html
@@ -4,7 +4,7 @@
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>LLVM Testing Infrastructure Guide</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
+  <link rel="stylesheet" href="_static/llvm.css" type="text/css">
  </head>
  <body>
        
@@ -626,6 +626,8 @@ define i8 @coerce_offset0(i32 %V, i32* %P) {
  
  <div>
  
+<!-- {% raw %} -->
+
  <p>The CHECK: and CHECK-NOT: directives both take a pattern to match.  For most
  uses of FileCheck, fixed string matching is perfectly sufficient.  For some
  things, a more flexible form of matching is desired.  To support this, FileCheck
@@ -650,6 +652,8 @@ braces like you would in C.  In the rare case that you want to match double
  braces explicitly from the input, you can use something ugly like
  <b>{{[{][{]}}</b> as your pattern.</p>
  
+<!-- {% endraw %} -->
+
  </div>
  
  <!-- _______________________________________________________________________ -->
@@ -659,6 +663,9 @@ braces explicitly from the input, you can use something ugly like
  
  <div>
  
+
+<!-- {% raw %} -->
+
  <p>It is often useful to match a pattern and then verify that it occurs again
  later in the file.  For codegen tests, this can be useful to allow any register,
  but verify that that register is used consistently later.  To do this, FileCheck
@@ -690,6 +697,8 @@ that FileCheck is not actually line-oriented when it matches, this allows you to
  define two separate CHECK lines that match on the same line.
  </p>
  
+<!-- {% endraw %} -->
+
  </div>
  
  </div>
@@ -789,14 +798,15 @@ define two separate CHECK lines that match on the same line.
    <p>Sometimes it is necessary to mark a test case as "expected fail" or XFAIL.
    You can easily mark a test as XFAIL just by including <tt>XFAIL: </tt> on a
    line near the top of the file. This signals that the test case should succeed
-  if the test fails. Such test cases are counted separately by the testing tool. To
-  specify an expected fail, use the XFAIL keyword in the comments of the test
-  program followed by a colon and one or more regular expressions (separated by
-  a comma). The regular expressions allow you to XFAIL the test conditionally by
-  host platform. The regular expressions following the : are matched against the
-  target triplet for the host machine. If there is a match, the test is expected
-  to fail. If not, the test is expected to succeed. To XFAIL everywhere just
-  specify <tt>XFAIL: *</tt>. Here is an example of an <tt>XFAIL</tt> line:</p>
+  if the test fails. Such test cases are counted separately by the testing
+  tool. To specify an expected fail, use the XFAIL keyword in the comments of
+  the test program followed by a colon and one or more failure patterns. Each
+  failure pattern can be either '*' (to specify fail everywhere), or a part of a
+  target triple (indicating the test should fail on that platform), or the name
+  of a configurable feature (for example, "loadable_module"). If there is a
+  match, the test is expected to fail. If not, the test is expected to
+  succeed. To XFAIL everywhere just specify <tt>XFAIL: *</tt>. Here is an
+  example of an <tt>XFAIL</tt> line:</p>
  
  <div class="doc_code">
  <pre>