Add a |pprint filter, handy for development purposes sometimes.

git-svn-id: https://llvm.org/svn/llvm-project/lnt/trunk@154931 91177308-0d34-0410-b5e6-96231b3b80d8
lnt.server.reporting: Add a new SummaryReport object.

This is pretty ad hoc at the moment, but it provides a way to get an overall
summary of how we are doing on performance across releases. It handles:
 - Aggregate across multiple machines and runs.
 - Aggregate across both the "nightly test" and "compile time" test suites.
 - Present results in a single relatively simple web report.
   o Results get broken down into 4 main charts:
       { Compile Time, Execution Time } x { Debug Builds, Release Builds }
   o Results also include pie chart showing the breakdown of single file times
     (what parts of the compiler time is being spent in).

The aggregation process is currently:

1. "Nightly test" results are aggregated into an ad hoc metric which we label "Lmark":
   - Runs are aggregated into debug vs release, and other optimization flags are
     ignored.
   - Runs are aggregated into 'x86' and 'ARM'.
   - Compile time for all benchmarks is summed. This means longer building
     benchmarks are weighted more heavily currently.
   - Execution time for a limited set of benchmarks is summed. We limit
     ourselves to only consider SPEC and a handful of other tests which we
     non-scientifically believe to be interesting benchmarks. Again, longer
     running benchmarks are weighted more heavily by this.

2. For the "compile time" suite, we:
   - Only pay attention to wall time results for now. Reporting both user time
     and wall time is too much data to concisely present. I do plan to add
     memory usage.

     We may want to revisit this, because actually the user time and wall time
     are quite interesting to both see particularly for full build timings.  -
     Aggregate full builds across all job sizes (by the normalized mean to
     weight each job size equally).  - Aggregate all single file tests
     regardless of input (by mean).

This is close to being useful, but there are lots of areas that need additional
work:
 - Report definition currently has to be defined by hand (inside the instance),
   no UI for it.
 - No way to investigate results further (aggregation is opaque):
   o It would be nice if there was a way to "dive in" on particular results and
     crack open the aggregation function to understand the values behind a
     particular plot.
 - Performance of the report generation sucks.
 - From a design point of view, the code relies heavily on implicit assumptions
   about the test suites. In an ideal world, we would find a way to make the
   information needed to produce this report all data driven.
 - I would like to investigate (or provide explicit options for) some of the
   choices of aggregation functions, and how changing them impacts the results.

git-svn-id: https://llvm.org/svn/llvm-project/lnt/trunk@154932 91177308-0d34-0410-b5e6-96231b3b80d8
SummaryReport: Optimize query / SA overhead for report.

git-svn-id: https://llvm.org/svn/llvm-project/lnt/trunk@154933 91177308-0d34-0410-b5e6-96231b3b80d8
lnt runserver: Add a --profiler option.
 - Writes to a profiler.log in the local directory.

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