minor tweaks.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58545 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/www/performance.html b/www/performance.html
index 0c98011726f4fa533d33d4510226b9e868af90cb..28ac6a6901156d266b2a5ef7b60f25abaf3e6c35 100644 (file)
--- a/www/performance.html
+++ b/www/performance.html
@@ -45,7 +45,7 @@ interesting benchmarks:
 
 <p>Measurements are done by serially processing each file in the
 respective benchmark, using Clang, gcc, and llvm-gcc as compilers. In
-order to track the performance of various subsystem, the timings have
+order to track the performance of various subsystems, the timings have
 been broken down into separate stages where possible:
 
 <ul>
@@ -55,7 +55,7 @@ been broken down into separate stages where possible:
   <li><tt>-parse-noop</tt>: This option runs the parser on the input,
     but without semantic analysis or any output. gcc and llvm-gcc have
     no equivalent for this option.</li>
-  <li><tt>-fsyntax-only</tt>: This option only runs semantic
+  <li><tt>-fsyntax-only</tt>: This option runs the parser with semantic
     analysis.</li>
   <li><tt>-emit-llvm -O0</tt>: For Clang and llvm-gcc, this option
     converts to the LLVM intermediate representation but doesn't
@@ -76,6 +76,10 @@ with <tt>-parse-noop</tt> (for clang) or <tt>-MM</tt> with gcc and
 llvm-gcc. This amounts to a fairly accurate measure of only the time
 to perform semantic analysis (and parsing, in the case of gcc and llvm-gcc).</p>
 
+<p>Note that we already know that the LLVM optimizers are substantially (30-40%)
+faster than the GCC optimizers at a given -O level, so we only focus on -O0
+compile time here.</p>
+
 <!--*************************************************************************-->
 <h2><a name="enduser">Timing Results</a></h2>
 <!--*************************************************************************-->