[www] r197487 - changing BOF notes from pdf to html

Renato Golin renato.golin at linaro.org
Tue Dec 17 02:52:21 PST 2013

Author: rengolin
Date: Tue Dec 17 04:52:20 2013
New Revision: 197487

URL: http://llvm.org/viewvc/llvm-project?rev=197487&view=rev
changing BOF notes from pdf to html


Modified: www/trunk/devmtg/2013-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/index.html?rev=197487&r1=197486&r2=197487&view=diff
--- www/trunk/devmtg/2013-11/index.html (original)
+++ www/trunk/devmtg/2013-11/index.html Tue Dec 17 04:52:20 2013
@@ -49,16 +49,16 @@ We also invite you to sign up for the <a
 <tr><td><a href="slides/Zakai-Emscripten.pdf">Slides</a><br><a href="videos/Zakai-Emscripten-720.mov">Video</a> (Computer)<br><a href="videos/Zakai-Emscripten-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk2">Emscripten: Compiling LLVM bitcode to JavaScript
 </a></b><br>Alon Zakai, <i>Mozilla</i></td></tr>
   <tr><td><a href="slides/Koch-FunctionMerging.pdf">Slides</a><br><a href="videos/Koch-CodeSize-720.mov">Video</a> (Computer)<br><a href="videos/Koch-CodeSize-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk3">Code Size Reduction using Similar Function Merging</a></b><br>Tobias Edler von Koch, <i>University of Edinburgh / QuIC</i><br> Pranav Bhandarkar, <i>QuIC</i></td></tr>
-  <tr><td><a href="slides/BenchmarkBOFNotes.pdf">Notes</a></td><td><a href="#bof1"><b>BOF: Performance Tracking & Benchmarking Infrastructure</b></a><br>Kristof Beyls, <i>ARM</i></td></tr>
+  <tr><td><a href="slides/BenchmarkBOFNotes.html">Notes</a></td><td><a href="#bof1"><b>BOF: Performance Tracking & Benchmarking Infrastructure</b></a><br>Kristof Beyls, <i>ARM</i></td></tr>
  <tr><td><a href="slides/Fischer-Julia.html">Slides</a><br><a href="videos/Fischer-Julia-720.mov">Video</a> (Computer)<br><a href="videos/Koch-CodeSize-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk4">Julia: An LLVM-based approach to scientific computing</a></b><br>Keno Fischer, <i>Harvard College/MIT CSAIL</i></td></tr>
   <tr><td><a href="slides/Lopes-SMT.pdf">Slides</a><br><a href="videos/Lopes-SMTSolvers-720.mov">Video</a> (Computer)<br><a href="videos/Lopes-SMTSolvers-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk5">Verifying optimizations using SMT solvers</a></b><br>Nuno Lopes, <i>INESC-ID / U. Lisboa</i></td></tr>
-  <tr><td><a href="slides/TableGenBOFNotes.pdf">Notes</a></td><td><a href="#bof2"><b>BOF: TableNextGen</b></a><br>Mihail Popa, <i>ARM</i></td></tr>
+  <tr><td><a href="slides/TableGenBOFNotes.html">Notes</a></td><td><a href="#bof2"><b>BOF: TableNextGen</b></a><br>Mihail Popa, <i>ARM</i></td></tr>
 <tr><td><a href="slides/Serebryany-ASAN.pdf">Slides</a><br><a href="videos/Serebryany-ASAN-720.mov">Video</a> (Computer)<br><a href="videos/Serebryany-ASAN-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk6">New Address Sanitizer Features</a></b><br>Kostya Serebryany,<i>Google</i><br> Alexey Samsonov, <i>Google</i></td></tr>
   <tr><td><a href="slides/Stellard-R600.pdf">Slides</a><br><a href="videos/Stellard-R600-720.mov">Video</a> (Computer)<br><a href="videos/Stellard-R600-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk7">A Detailed Look at the R600 Backend</a></b><br>Tom Stellard, <i>Advanced Micro Devices Inc.</i></td></tr>
-  <tr><td><a href="slides/DebugBOFNotes.pdf">Notes</a></td><td><a href="#bof3"><b>BOF: Debug Info</b></a><br>Eric Christopher, <i>Google</i></td></tr>
+  <tr><td><a href="slides/DebugBOFNotes.html">Notes</a></td><td><a href="#bof3"><b>BOF: Debug Info</b></a><br>Eric Christopher, <i>Google</i></td></tr>
 <tr><td><a href="slides/Robinson-PS4Toolchain.pdf">Slides</a><br>Video</td><td><b><a href="#talk8">Developer Toolchain for the PlayStation®4</a></b><br>Paul T. Robinson, <i>Sony Computer Entertainment America</i></td></tr>
   <tr><td>Slides<br><a href="videos/Tzannes-ASaP-720.mov">Video</a> (Computer)<br><a href="videos/Tzannes-ASaP-360.mov">Video</a> (Mobile)</td><td><b><a href="#talk9">Annotations for Safe Parallelism in Clang</a></b><br>Alexandros Tzannes, <i>University of Illinois, Urbana-Champaign</i></td></tr>

Added: www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.html?rev=197487&view=auto
--- www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.html (added)
+++ www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.html Tue Dec 17 04:52:20 2013
@@ -0,0 +1,87 @@
+<head><title>Benchmarking BOF</title></head>
+<h1>Benchmarking BOF</h1>
+<h3><i>Kristof Beyls</i></h3>
+<p>This is a summary of what was discussed at the Performance Tracking and
+Benchmarking Infrastructure BoF session last week at the LLVM dev meeting.</p>
+<p>At the same time it contains a proposal on a few next steps to improve the
+setup and use of buildbots to track performance changes in code generated by
+<p>The buildbots currently are very valuable in detecting correctness regressions,
+and getting the community to quickly rectify those regressions. However,
+performance regressions are hardly noted and it seems as a community, we don't
+really keep track of those well.</p>
+<p>The goal for the BoF was to try and find a number of actions that could take us
+closer to the point where as a community, we would at least notice some of the
+performance regressions and take action to fix the regressions.  Given that
+this has been discussed already quite a few times at previous BoF sessions at
+multiple developer meetings, we thought we should aim for a small, incremental,
+but sure improvement over the current status. Ideally, we should initially aim
+for getting to the point where at least some of the performance regressions are
+detected and acted upon.</p>
+<p>We already have a central database that stores benchmarking numbers, produced
+for 2 boards, see
+<a href="http://llvm.org/perf/db_default/v4/nts/recent_activity#machines">perf's
+page</a>. However, it seems no-one monitors the produced results, nor is it easy
+to derive from those numbers if a particular patch really introduced a significant
+<p>At the BoF, we identified the following issues blocking us from being able to
+detect significant regressions more easily:</p>
+<li>A lot of the Execution Time and Compile Time results are very noisy, because
+    the individual programs don't run long enough and don't take long enough to
+    compile (e.g. less than 0.1 seconds).</li>
+<li>The proposed actions to improve the execution time is, for the programs under
+    the Benchmarks sub-directories in the test-suite, to:
+    <ul>
+    <li>Increase the run time of the benchmark so it runs long enough to avoid
+        noisy results. "Long enough" probably means roughly 10 seconds. We'd probably
+        need a number of different settings, or a parameter that can be set per
+        program, so that the running time on individual boards can be tuned. E.g.
+        on a faster board, more iterations would be run than on a slower board.</li>
+    <li>Evaluate if the main running time of the benchmark is caused by running code
+        compiled or by something else, e.g. file IO. Programs dominated by file IO
+        shouldn't be used to track performance changes over time. The proposal to
+        resolve this is to create a way to run the test suite in 'benchmark mode',
+        which includes only a subset of the test suite useful for benchmarking.</li>
+    </ul>
+<li>The identified action to improve the compile time measurements is to just add
+    up the compilation time for all benchmarks and measure that, instead of the
+    compile times of the individual benchmarks. It seems this could be implemented
+    by simply changing or adding a view in the web interface, showing the trend of
+    the compilation time for all benchmarks over time, rather than trend graphs for
+    individual programs.</li>
+<li>Furthermore, on each individual board, the noise introduced by the board itself
+    should be minimized. Each board should have a maintainer, who ensures the board
+    doesn't produce a significant level of noise. If the board starts producing a
+    high level of noise, and the maintainer doesn't fix it quickly, the performance
+    numbers coming from the board will be ignored. It's not clear what the best way
+    would be to mark a board as being ignored. The suggestion was made that board
+    maintainers could get a script to run before each benchmarking run, to check
+    whether the board seems in a reasonable state, e.g. by checking the load on the
+    board is near zero; "dd" executes as fast as expected; .... It's expected that
+    the checks in the script might be somewhat dependent on the operating system
+    the board runs.</li>
+<li>To reduce the noise levels further, it would be nice if the execution time
+    of individual benchmarks could be averaged out over a number (e.g. 5)
+    consecutive runs. That way, each individual benchmark run remains relatively
+    fast, by having to run each program just once; while at the same time the
+    averaging should reduce some of the insignificant noise in the individual runs.</li>
+<p>We'd appreciate any feedback on the above proposals. We're also looking for more
+volunteers to implement the above improvements; so if you're interested in
+working on some of the above, please let us know.</p>

Removed: www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.pdf
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.pdf?rev=197486&view=auto
Binary file - no diff available.

Added: www/trunk/devmtg/2013-11/slides/DebugBOFNotes.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/DebugBOFNotes.html?rev=197487&view=auto
--- www/trunk/devmtg/2013-11/slides/DebugBOFNotes.html (added)
+++ www/trunk/devmtg/2013-11/slides/DebugBOFNotes.html Tue Dec 17 04:52:20 2013
@@ -0,0 +1,32 @@
+<head><title>Debug Info BOF</title></head>
+<h1>Debug Info BOF</h1>
+<h3><i>Eric Christopher</i></h3>
+<p>Optimized debugging is still a big miss with a lof of metadata being lost at
+   various stages, mostly affecting variable tracking, leastly affecting line
+   information.</p>
+<p>Dwarf 4 seems to be the standard that LLVM is being coded to, Dwarf 3 in
+   maintenance mode, Dwarf 2 is dead. Still, would be good to have some mechanism
+   to limit the version of Dwarf symbols, to avoid breaking compatibility with
+   older toolchains for a small feature.</p>
+<p>In time, Dwarf 3 will be deprecated, and the story will repeat, and it’s clear
+   and accepted by all that this is the natural course of thing.</p>
+<p>Verifier will check debug info, so metadata is supposed to be consistent
+   after validation.</p>
+<p>Metadata may lose type information and be left with line, function and scope
+   info. The rest can be inferred from IR.</p>
+<p>Debug metadata is widely known to be huge and methods to reduce the size in
+   IR are being considered, including emitting Dwarf directly in IR, converting
+   the most common constructs to text literals (including small numbers, < 4-8
+   digits), packing (zip) the contents, etc.</p>

Removed: www/trunk/devmtg/2013-11/slides/DebugBOFNotes.pdf
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/DebugBOFNotes.pdf?rev=197486&view=auto
Binary file - no diff available.

Added: www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.html?rev=197487&view=auto
--- www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.html (added)
+++ www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.html Tue Dec 17 04:52:20 2013
@@ -0,0 +1,54 @@
+<head><title>TableGen BOF</title></head>
+<h1>TableGen BOF</h1>
+<h3><i>Mihail Popa</i></h3>
+<p>The BoF was attended by quite a lot of people and there was general agreement
+   that tablegen needs improvement in some shape or form. However there are many
+   divergent ideas as to how to go about this improvement. Of course this is
+   completely natural, tablegen being a versatile tool used by many different
+   people for many different purposes.</p>
+<p>Part of the attendees focused on missing features. Feature requests include:</p>
+<li>support for vector literals</li>
+<li>support for instruction/patterns with multiple outputs</li>
+<li>support complex transforms where types of input and output differ</li>
+<li>remove need of magic vars in complex patterns</li>
+<li>improve support for permutations of operands</li>
+<li>ability to implement DAG combines in tablegen</li>
+<li>auto detect/infer constraints</li>
+<li>add support or missing patterns and/or selectable insts</li>
+<li>extend tablegen unit tests to go beyond simple syntactic constructs</li>
+<li>automatically add MCDesc fields</li>
+<li>improve debug-ability and error reporting</li>
+<li>auto-inversion for predicates</li>
+<p>It was commented that the current state of tablegen is due to its quite rapid
+   growth through the past years. Then point was raised that, probably, we will
+   not be fixing anything by simply bolting on top further functionality.</p>
+<p>My desire was to steer the discussion towards how to design tablegen as a
+   proper domain specific language targeted at compiler construction. I think
+   it was generally agreed that this is a distant goal worth pursuing and that
+   the first steps is to first document what tablegen currently has.</p>
+<p>The root cause for lack of documentation was identified as:</p>
+"People don't feel authoritative enough to go ahead and write docs.
+ Many community members are knowledgeable in small pieces,
+ but don’t feel are qualified to author documentation".</i>
+<p>It was generally agreed that a way to solve this is to create a shared
+   repository where everyone can commit any pieces of information they might
+   have. We hope it will grow to a proper documentation for tablegen's features.
+   Once gotten there we would be in a much better position to decide how to
+   further develop this tool.</p>

Removed: www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.pdf
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.pdf?rev=197486&view=auto
Binary files www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.pdf (original) and www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.pdf (removed) differ

More information about the llvm-commits mailing list