[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
Log:
changing BOF notes from pdf to html
Added:
www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.html
www/trunk/devmtg/2013-11/slides/DebugBOFNotes.html
www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.html
Removed:
www/trunk/devmtg/2013-11/slides/BenchmarkBOFNotes.pdf
www/trunk/devmtg/2013-11/slides/DebugBOFNotes.pdf
www/trunk/devmtg/2013-11/slides/TableGenBOFNotes.pdf
Modified:
www/trunk/devmtg/2013-11/index.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 @@
+<html>
+<head><title>Benchmarking BOF</title></head>
+<body>
+
+<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
+LLVM.</p>
+
+<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
+regression.</p>
+
+<p>At the BoF, we identified the following issues blocking us from being able to
+detect significant regressions more easily:</p>
+
+<ul>
+<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>
+<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>
+</ul>
+
+<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>
+
+
+</body>
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 @@
+<html>
+<head><title>Debug Info BOF</title></head>
+<body>
+
+<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>
+
+</body>
+
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 @@
+<html>
+<head><title>TableGen BOF</title></head>
+<body>
+
+<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>
+
+<ul>
+<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>
+</ul>
+
+<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>
+
+<blockquote><i>
+"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>
+</blockquote>
+
+<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>
+
+</body>
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