| <!--#include virtual="../../header.incl" --> |
| |
| <div class="www_sectiontitle">2013 European LLVM Conference</div> |
| |
| <p align="center"><h3><b>SPONSORED BY:</b> |
| <a href="http://www.arm.com/">ARM</a>, |
| <a href="http://www.ens.fr/">ENS</a>, |
| <a href="http://www.google.com/">Google</a>, |
| <a href="http://www.irill.org">IRILL</a>/<a |
| href="http://www.inria.fr">INRIA</a>, |
| <a href="http://www.intel.com">Intel</a>, |
| <a href="http://www.parrot.com">Parrot</a>, |
| <a href="http://www.qualcomm.com/quicinc/">QuIC</a>, |
| <a href="http://www.samsung.com">Samsung</a> |
| <h3></p> |
| |
| <table> |
| <tr><td valign="top"> |
| <ol> |
| <li><a href="#announcements">Announcement</a></li> |
| <!-- <li><a href="#callfor">Call for Speakers, Posters, Demos</a></li> --> |
| <li><a href="#content">Content</a></li> |
| <li><a href="#questionnaire">Questionnaire Results</a></li> |
| <li><a href="#talkabstract">Talk abstracts</a></li> |
| <li><a href="#tutoabstract">Tutorial abstracts</a></li> |
| <li><a href="#posterabstract">Poster abstracts</a></li> |
| <li><a href="#ltalkabstract">Lightning talk abstract</a></li> |
| </ol> |
| </td><td> |
| <ul> |
| <li><b>What</b>: The third European LLVM meeting</li> |
| <li><b>Why</b>: To get acquainted, learn how LLVM is used, and exchange ideas.</li> |
| <li><b>When</b>: 29/30 April 2013</li> |
| <li><b>Where</b>: Paris, France</li> |
| </ul> |
| </td></tr></table> |
| |
| <h2 id="announcements">Announcement</h2> |
| |
| The conference already took place. Here the original announcement: |
| |
| <p> |
| "We are pleased to announce the third European LLVM conference on April 29-30 2013 in Paris, France. |
| This will be a two day conference which aims to present the latest developments |
| in the LLVM world and help strengthen the network of LLVM developers. The |
| format will be similar to that of the previous meetings held in London but with |
| more time for presentations and networking. The meeting is open to anyone |
| whether from business or academia, professional or enthusiast and is not |
| restricted to those from Europe - attendees from all regions are welcome." |
| </p> |
| |
| The <a href="http://blog.llvm.org/2013/05/eurollvm-2013-paris-france.html">After Conference Blog Post</a> gives an impression of the event.<br /><br /> |
| Videos are also available on the <a href="http://www.irill.org/videos/euro-llvm-2013">IRILL website</a>. |
| |
| <!-- |
| <h2 id="callfor">Call for Speakers, Posters, Demos</h2> |
| |
| We invite academic, industrial and hobbyist speakers to present their work on |
| developing or using LLVM, Clang, etc. Proposals for technical presentations, |
| posters, workshops, demonstrations and BoFs are welcome. Material will be |
| chosen to cover a broad spectrum of themes and topics at various depths, some |
| technical deep-diving, some surface-scratching. |
| |
| <p>We are looking for: |
| <ol> |
| <li>Keynote speakers.</li> |
| <li>Technical presentations (30 minutes plus questions and discussion) related |
| to development of LLVM, Clang etc.</li> |
| <li>Presentations relating to academic or commercial use of LLVM, Clang |
| etc.</li> |
| <li>Lightning talks (5 minutes, no questions, no discussion).</li> |
| <li>Workshops and in-depth tutorials (1-2 hours - please specify in your |
| submission).</li> |
| </ol></p> |
| |
| <p>The deadline for receiving submissions is March 1st, 2013. Speakers will be |
| notified of acceptance or rejection by the 15th of March. Proposals that are |
| not sufficiently detailed (talks lacking a comprehensive abstract for example) |
| are likely to be rejected. Slides and posters must be in PDF format. |
| Submissions should be done by email at |
| <a href="mailto:euro-llvm-2013-technical-committee@googlegroups.com"> |
| euro-llvm-2013-technical-committee@googlegroups.com</a>.</p> |
| |
| <p>Please note that presentation materials and videos for the technical sessions |
| will be posted on llvm.org after the conference. We have reserved additional spots |
| for speakers, such that they can attend the conference even though we have reached |
| our registration limit.</p> |
| |
| <h3 id="submissions">Submission Style</h3> |
| |
| <p>We are looking for: |
| <ul> |
| <li>A title and an extended abstract, <i>OR</i></li> |
| <li>A title, abstract and some slides</li> |
| </ul> |
| |
| <p>Please make clear the status of the slides: Are they a skeleton of your |
| presentation with the detail missing? Or, perhaps a section of detail that lacks |
| introduction and conclusions? The more you can give us and tell us the easier it |
| will be for us to be positive about your submission.</p> |
| |
| <p>For examples of abstracts and introductions please look at papers from any |
| compiler conference such as Code Generation and Optimization. A typical abstract |
| is from one paragraph to half of a column on a 2-column A4 page. A typical |
| introduction is between 0.5 and 2 A4 pages. An A4 page would suffice for an |
| extended abstract. The more slides you give us in near final form the less we |
| need by way of abstract and introduction.</p> |
| --> |
| |
| <!-- *********************************************************************** --> |
| <h2 id="content">Content</h2> |
| |
| <h3>Keynotes</h3> |
| |
| <table border="1"> |
| <tr> <th>Speaker</th> <th>Subject</th> <th>Media</th> </tr> |
| <tr> |
| <td>Chandler Carruth (Google)</td> |
| <td><a href="#talk3">Optimization in LLVM - Numbers, A Case Study, and Looking Forward</a></td> |
| <td><a href="videos/carruth-lores.mov">Video (small)</a>, <a href="videos/carruth-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Jakob Olesen (Apple)</td> |
| <td><a href="#talk7">How Computers Work</a></td> |
| <td><a href="olesen-slides.pdf">Slides</a>, no video available</td> |
| </tr> |
| </table> |
| |
| <h3>Talks</h3> |
| |
| <table border="1"> |
| <tr> <th>Speaker</th> <th>Subject</th> <th>Media</th> </tr> |
| <tr> |
| <td>Andrey Bokhanko & Alexey Bataev (Intel)</td> |
| <td><a href="#talk2">Towards OpenMP Support in LLVM</a></td> |
| <td><a href="bokhanko-bataev-slides.pdf">Slides</a>, <a href="videos/bokhanko-bataev-lores.mov">Video (small)</a>, <a href="videos/bokhanko-bataev-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Ahmed Bougacha</td> |
| <td><a href="#talk1">Dagger: decompilation to LLVM IR</a></td> |
| <td><a href="bougacha-slides.pdf">Slides</a>, <a href="videos/bougacha-lores.mov">Video (small)</a>, <a href="videos/bougacha-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Eric Christopher (Google)</td> |
| <td><a href="#talk5">Debug Info - Status and Directions</a></td> |
| <td><a href="christopher-slides.pdf">Slides</a>, <a href="videos/christopher-lores.mov">Video (small)</a>, <a href="videos/christopher-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Daniel Jasper (Google)</td> |
| <td><a href="#talk4">clang-format - Automatic formatting for C++</a></td> |
| <td><a href="jasper-slides.pdf">Slides</a>, <a href="videos/jasper-lores.mov">Video (small)</a>, <a href="videos/jasper-hires.mov">Video (large)</a>, <a href="videos/jasper-vhres.mov">Video (very large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Olaf Krzikalla (TU Dresden)</td> |
| <td><a href="#talk9">Performing Source-to-Source Transformations with Clang</a></td> |
| <td><a href="krzikalla-slides.pdf">Slides</a>, <a href="videos/krzikalla-lores.mov">Video (small)</a>, <a href="videos/krzikalla-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Oleg Maslov (Intel)</td> |
| <td><a href="#talk10">LLVM Interpreter, a key component in validation of OpenCL compilers</a></td> |
| <td><a href="maslov-slides.pdf">Slides</a>, <a href="videos/maslov-lores.mov">Video (small)</a>, <a href="videos/maslov-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Simone Pellegrini (U Innsbruck)</td> |
| <td><a href="#talk13">An experimental framework for Pragma Handling in Clang</a></td> |
| <td><a href="pellegrini-slides.pdf">Slides</a>, <a href="videos/pellegrini-lores.mov">Video (small)</a>, <a href="videos/pellegrini-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Michael Spencer (Sony)</td> |
| <td><a href="#talk8">lld - Solving the Linking Performance Problem</a></td> |
| <td><a href="spencer-slides.pdf">Slides</a>, <a href="videos/spencer-lores.mov">Video (small)</a>, <a href="videos/spencer-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Evgeniy Stepanov (Google)</td> |
| <td><a href="#talk6">Run-time tracking of uninitialized data with MemorySanitizer</a></td> |
| <td><a href="stepanov-slides.pdf">Slides</a>, <a href="videos/stepanov-lores.mov">Video (small)</a>, <a href="videos/stepanov-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Ulrich Weigand (IBM)</td> |
| <td><a href="#talk14">LLVM on IBM POWER processors: a progress report</a></td> |
| <td><a href="weigand-slides.pdf">Slides</a>, <a href="videos/weigand-lores.mov">Video (small)</a>, <a href="videos/weigand-hires.mov">Video (large)</a></td> |
| </tr> |
| </table> |
| |
| <h3>Tutorials</h3> |
| |
| <table border="1"> |
| <tr> <th>Speaker</th> <th>Subject</th> <th>Media</th> </tr> |
| |
| <tr> |
| <td>Simon Cook (Embecosm)</td> |
| <td><a href="#talk12">How to implement an LLVM Assembler - a tutorial</a></td> |
| <td><a href="cook-slides.pdf">Slides</a>, <a href="videos/cook-lores.mov">Video (small)</a>, <a href="videos/cook-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Manuel Klimek (Google)</td> |
| <td><a href="#tuto1">The Clang AST - a tutorial</a></td> |
| <td><a href="klimek-slides.pdf">Slides</a>, <a href="videos/klimek-lores.mov">Video (small)</a>, <a href="videos/klimek-hires.mov">Video (large)</a>, <a href="videos/klimek-vhres.mov">Video (very large)</a></td> |
| </tr> |
| </table> |
| |
| <h3><a href="#ltalkabstract">Lightning talks</a></h3> |
| |
| <table border="1"> |
| <tr> <th>Speaker</th> <th>Subject</th> <th>Media</th> </tr> |
| <tr> |
| <td>Diana Chen</td> |
| <td>MCLinker: Design and Implementation of a Fragments-based Target-independent Linker</td> |
| <td><a href="chen-slides.pdf">Slides</a>, <a href="videos/chen-lores.mov">Video (small)</a>, <a href="videos/chen-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Clemens Hammacher</td> |
| <td>Sambamba: A Runtime System for Online Adaptive Parallelization</td> |
| <td><a href="hammacher-slides.pdf">Slides</a>, <a href="videos/hammacher-lores.mov">Video (small)</a>, <a href="videos/hammacher-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Ralf Karrenberg</td> |
| <td>Noise: A Clang Extension for User-Defined Optimization Strategies</td> |
| <td><a href="karrenberg-slides.pdf">Slides</a>, <a href="videos/karrenberg-lores.mov">Video (small)</a>, <a href="videos/karrenberg-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>David Lacey</td> |
| <td>Integrating fine-grained timing constraints into LLVM</td> |
| <td><a href="lacey-slides.pdf">Slides</a>, <a href="videos/lacey-lores.mov">Video (small)</a>, <a href="videos/lacey-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Sylvestre Ledru</td> |
| <td>Rebuild of all Debian packages using Clang instead of gcc</td> |
| <td><a href="ledru-slides.pdf">Slides</a>, <a href="videos/ledru-lores.mov">Video (small)</a>, <a href="videos/ledru-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Diego Novillo</td> |
| <td>FDO-based whole program optimization in LLVM</td> |
| <td><a href="novillo-slides.pdf">Slides</a>, <a href="videos/novillo-lores.mov">Video (small)</a>, <a href="videos/novillo-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| <tr> |
| <td>Henning Thielemann</td> |
| <td>Efficient audio signal processing using LLVM and Haskell</td> |
| <td><a href="thielemann-slides.pdf">Slides</a>, <a href="videos/thielemann-lores.mov">Video (small)</a>, <a href="videos/thielemann-hires.mov">Video (large)</a></td> |
| </tr> |
| |
| </table> |
| |
| <h3><a href="#posterabstract">Posters</a></h3> |
| |
| <table border="1"> |
| <tr> <th>Presenter</th> <th>Subject</th> <th>Media</th> </tr> |
| |
| <tr> |
| <td>Ryan Baird</td> |
| <td>Improving Machine Code Generation Quality by Interfacing VPO with LLVM</td> |
| <td><a href="baird-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Victoria Caparros</td> |
| <td>Using the LLVM Interpreter to Quantify Applications Inherent Properties</td> |
| <td><a href="caparros-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Diana Chen</td> |
| <td>MCLinker: Design and Implementation of a Fragments-based Target-independent Linker</td> |
| <td><a href="chen-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Peter Conn</td> |
| <td>Code Editing in Local Style</td> |
| <td><a href="conn-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Dustin Feld</td> |
| <td>ENHANCE - Enabling heterogeneous hardware acceleration using novel programming and scheduling models</td> |
| <td><a href="feld-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Clemens Hammacher</td> |
| <td>Sambamba: A Runtime System for Online Adaptive Parallelization</td> |
| <td><a href="hammacher-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Muhammad Hataba</td> |
| <td>OJIT: A novel secure remote execution technology by obfuscated Just-In-Time compilation</td> |
| <td><a href="hataba-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Dávid Juhász</td> |
| <td>LLVM backend for TILE64</td> |
| <td><a href="juhasz-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Ralf Karrenberg</td> |
| <td>Noise: A Clang Extension for User-Defined Optimization Strategies</td> |
| <td><a href="karrenberg-poster.pdf">Poster</a></td> |
| </tr> |
| |
| <tr> |
| <td>Ayal Zaks</td> |
| <td>LLVM IR editor plugin for Eclipse</td> |
| <td><a href="zaks-poster.pdf">Poster</a></td> |
| </tr> |
| </table> |
| |
| <!-- *********************************************************************** --> |
| <h2 id="questionnaire">Questionnaire Results</h2> |
| <p> |
| At the end of the event we had 91 questionnaires returned and the |
| results were pretty good. Below are some overall results, but each |
| presenter will receive the results of their own talks by personal email. |
| </p> |
| <p> |
| Each question had a range of four possible results (excellent-poor, |
| very useful-waste of time, etc), and below are the percentage of the |
| results that were 1 or 2 (excellent+good, very useful+useful, etc). |
| We're not considering "average" as a positive result, for obvious reasons. |
| </p> |
| <p> |
| At the end, there's a table with the percentages of a geometric mean of |
| all talks and another for the lightning talks, so you can get a feel of |
| the response without going in too much detail. |
| </p> |
| |
| <p><b>Overall event questions</b></p> |
| |
| <table border=1> |
| <tr><th>Question</th><th>% of positive results</th></tr> |
| <tr><td>Overall event</td><td>98%</td></tr> |
| <tr><td> </td><td> </td></tr> |
| <tr><td>Venue Quality</td><td>96%</td></tr> |
| <tr><td>Venue Food & Drinks</td><td>77%</td></tr> |
| <tr><td>Venue Rooms & Equipment</td><td>73%</td></tr> |
| <tr><td>Venue Location</td><td>99%</td></tr> |
| <tr><td> </td><td> </td></tr> |
| <tr><td>Quality of Lectures/Papers</td><td>100%</td></tr> |
| <tr><td>Quality of Tutorials</td><td>93%</td></tr> |
| <tr><td>Lightning Talks & Posters</td><td>94%</td></tr> |
| <tr><td> </td><td> </td></tr> |
| <tr><td>Overall networking usefulness</td><td>94%</td></tr> |
| <tr><td>Created 5+ new connections</td><td>65%</td></tr> |
| <tr><td>Reinforced 5+ existing connections</td><td>44%</td></tr> |
| <tr><td> </td><td> </td></tr> |
| <tr><td>Dinner Cruise Overall</td><td>100%</td></tr> |
| <tr><td>Dinner Cruise Food & Drinks</td><td>100%</td></tr> |
| <tr><td>Dinner Cruise Location</td><td>100%</td></tr> |
| </table> |
| |
| <p><b>Regarding the Content, they wanted:</b></p> |
| |
| <table border=1> |
| <tr><th>Topic</th><th>More</th><th>Same</th><th>Less</th></tr> |
| <tr><td>Formal Presentations</td><td>19%</td><td>67%</td><td>14%</td></tr> |
| <tr><td>Deeper, Specific Sessions</td><td>42%</td><td>39%</td><td>19%</td></tr> |
| <tr><td>Technical (Soft. Eng.) Sessions</td><td>43%</td><td>48%</td><td>9%</td></tr> |
| <tr><td>Narrowing Towards a Major Theme</td><td>4%</td><td>81%</td><td>15%</td></tr> |
| </table> |
| |
| <p><b>Location and Transport</b></p> |
| |
| <p>Where should we hold EuroLLVM 2014?</p> |
| <ul> |
| <li><b>Paris</b> 18%</li> |
| <li><b>London</b> 16%</li> |
| <li><b>Any Major EU city</b> 66%</li> |
| </ul> |
| |
| <p><b>Geometric Mean of All Talks</b></p> |
| |
| <table border=1> |
| <tr><th>Question</th><th>% of positive results</th></tr> |
| <tr><td>Material clearly presented</td><td>86%</td></tr> |
| <tr><td>Interesting topic to me</td><td>84%</td></tr> |
| <tr><td>Too much knowledge required(*)</td><td>78%</td></tr> |
| <tr><td>Importance to the Community</td><td>90%</td></tr> |
| <tr><td>Would like to hear more</td><td>84%</td></tr> |
| </table> |
| |
| <p><b>Lightning Talks</b></p> |
| |
| <table border=1> |
| <tr><th>Question</th><th>% of positive results</th></tr> |
| <tr><td>Material clearly presented</td><td>90%</td></tr> |
| <tr><td>Interesting topic to me</td><td>93%</td></tr> |
| <tr><td>Too much knowledge required(*)</td><td>93%</td></tr> |
| <tr><td>Importance the Community</td><td>94%</td></tr> |
| <tr><td>Would like to hear more</td><td>90%</td></tr> |
| </table> |
| |
| <p> |
| (*) Positive results for this question are those that answered |
| "disagree" and "strongly disagree", since we expected that the talks |
| shouldn't required too much detailed knowledge to understand, specially |
| from a crowd as specialized as ours. |
| <p> |
| |
| <!-- *********************************************************************** --> |
| <h2 id="talkabstract">Talk abstracts</h2> |
| <p> |
| <b><a id="talk1">Dagger: decompilation to LLVM IR |
| </a></b><br> |
| <i>Ahmed Bougacha</i><br> |
| Dagger is a decompilation framework based on LLVM. |
| It enables existing backends to easily provide instruction-level |
| semantics. These are then used to translate target instructions to an |
| IR-like architecture, Mir (for micro-IR), and further to LLVM IR |
| itself. Dagger also enables easy retargetability of several planned |
| tools, like rewriters, static or dynamic binary translators (with |
| valgrind-like instrumentation), and even simple instruction set |
| emulators. |
| The IR can also be transformed to do static analysis, or even, using a |
| revived and improved C backend, full-blown decompilation. |
| </p> |
| |
| <p> |
| <b><a id="talk2">Towards OpenMP Support in LLVM |
| </a></b><br> |
| <i>Andrey Bokhanko & Alexey Bataev - Intel</i><br> |
| In this talk we present our efforts and plans for OpenMP support in the LLVM |
| compiler infrastructure. |
| </p> |
| |
| <p> |
| <b><a id="talk3">Optimization in LLVM - Numbers, A Case Study, and Looking Forward |
| </a></b><br> |
| <i>Chandler Carruth - Google</i><br> |
| With all of the excitement surrounding Clang, LLD, LLDB, Sanitizers, and other |
| projects in LLVM, it is easy to let its origins slip your mind. |
| However, LLVM was and remains a platform for optimizing compilers and related |
| parts of the toolchain. Today, the LLVM + Clang optimizing C++ compiler is very |
| powerful and can handle a wide range of code, but how well does it compete with |
| modern versions of GCC? What are the root causes of some of the more striking |
| differences? What is coming next in LLVM that will significantly impact the |
| optimizing power of the toolchain? |
| </p> |
| |
| <p> |
| <b><a id="talk4">clang-format - Automatic formatting for C++ |
| </a></b><br> |
| <i>Daniel Jasper - Google</i><br> |
| Source code readability is an important aspect to ensure quality and long-term |
| maintainability. However, manually formatting is a tedious job that simply takes |
| a chunk out of every programmer's productivity. Moreover, the tediousness can |
| actively discourage refactorings, e.g. removing or restructuring a function's |
| parameters. There are tools that can provide some level of intelligent |
| auto-formatting, but no tool has so far been able to keep developers happy |
| in a reasonably-sized codebase. |
| Therefore, we have set out to build clang-format, an intelligent C++ formatter |
| based on Clang's infrastructure. |
| </p> |
| |
| <p> |
| <b><a id="talk5">Debug Info - Status and Directions |
| </a></b><br> |
| <i>Eric Christopher - Google</i><br> |
| In the last few years clang and llvm have made great inroads as the default |
| compilers in the open source world and in industry. It is now seeing daily |
| use as the default compiler for all of the Apple ecosystem, FreeBSD, and as |
| one of the compilers at Google. As a compiler matures and its user base |
| expands the quality of the debug information output becomes more important. |
| In the past users of clang and LLVM have had to deal with poor debug |
| information, but in the last couple years the quality of debug information |
| has improved greatly and in some cases we are pushing the boundaries of |
| existing standards. We've made good progress with gdb testing and |
| implementing DWARF4 including the extensions for C++11. Furthermore, we've |
| implemented and are proposing for inclusion in DWARF5 support for split |
| debug information and faster access to named debug entities. |
| </p> |
| |
| <p> |
| <b><a id="talk6">Run-time tracking of uninitialized data with MemorySanitizer |
| </a></b><br> |
| <i>Evgeniy Stepanov - Google</i><br> |
| <a href="http://clang.llvm.org/docs/MemorySanitizer.html">MemorySanitizer</a> |
| is a detector of uninitialized reads, inspired by Valgrind/Memcheck and |
| DrMemory, but based on compiler instrumentation technology. It was |
| mentioned in the 2012 LLVM DevMtg; since then MemorySanitizer (MSan) |
| has grown and improved and has been accepted in LLVM 3.3 trunk. It is |
| now able to bootstrap Clang with a 3.7x slowdown and has detected |
| multiple bugs in LLVM, Chromium, etc. |
| |
| Unlike AddressSanitizer and ThreadSanitizer, MSan has a very simple |
| run-time library and a complex instrumentation module. Another |
| difference is the need for full program instrumentation. We provide a |
| helper tool based on DynamoRio instrumentation framework to deal with |
| this. This talk will concentrate on MSan internals and implementation |
| issues. |
| </p> |
| |
| <p> |
| <b><a id="talk7">How Computers Work |
| </a></b><br> |
| <i>Jakob Olesen - Apple</i><br> |
| Most high-performance CPU micro-architectures designed in the last 20 years are |
| super-scalar and execute instructions out of order. I intend to give an |
| overview of how out-of-order CPUs work, and how we can generate code that |
| performs well on modern micro-architectures. Some optimisations are only |
| beneficial if the compiler has a detailed understanding of how the code is |
| going to be executed, and the new machine trace metrics analysis can be used |
| to guide these optimisations. I'll talk about current and future optimisations |
| that can take advantage of this detailed execution information. |
| </p> |
| |
| <p> |
| <b><a id="talk8">lld - Solving the Linking Performance Problem |
| </a></b><br> |
| <i>Michael Spencer - Sony Computer Entertainment America</i><br> |
| lld is a LLVM subproject with the goal of building a fast, modular, and cross |
| platform linker. lld is under very active development. It can currently link |
| moderately complex programs, including itself and LLVM. |
| Link time performance is a critical part of lld, and it takes several measures |
| to improve it. The Atom graph model simplifies linking which also makes |
| parallelizing the link simpler. It also provides a method to evaluate linker |
| scripts without serializing the entire link. We have also taken a step back to |
| look at the entire linking process and have found a major area for improvement. |
| A significant amount of time while linking is spent reading object files and |
| converting the information they contain into a format suitable for the linker. |
| We can improve this by reading in parallel and reading lazily, however this can |
| only take us so far. The real solution is to have the compiler emit object files |
| designed for linking performance. |
| Since we have a simple internal model in the linker, we have developed a native |
| object file format that matches this model and that is designed specifically |
| for linking performance. It is designed around the data structures and |
| algorithms used in linking, while still maintaining all of the semantics of |
| various object file formats. It is also very easy for compilers to generate. |
| This allows us to bypass the work of processing traditional object files and |
| jump directly to the core linking process. |
| This talk will explore the the linking performance problem and lld's solutions. |
| </p> |
| |
| <p> |
| <b><a id="talk9">Performing Source-to-Source Transformations with Clang |
| </a></b><br> |
| <i>Olaf Krzikalla - TU Dresden</i><br> |
| Back in 2009 we started to develop a configurable source-to-source |
| transformation tool designed to automatically vectorize C/C++ source code using |
| SIMD instructions. Meanwhile the tool, called Scout, is an industrial-strength |
| vectorizing preprocessor, which is used on a day-to-day basis in the software |
| production process of the German Aerospace Center. The code is published as |
| Open Source and can be downloaded from |
| <a href="http://scout.zih.tu-dresden.de">http://scout.zih.tu-dresden.de</a>. |
| The source-to-source transformation framework of Scout is based on the AST |
| and the accompanying infrastructure of Clang. Beside the actual vectorization |
| the framework provides function inlining, loop-unrolling and loop-unswitching |
| at AST level. For this a C/C++ file is parsed, the generated AST is transformed and |
| then written back to a target file. However this approach is critical, since |
| the AST of Clang is actually immutable by design. On the other hand there is a |
| lot of interest in source-to-source transformation tools based on Clang, |
| as can be seen on cfe-dev and in other talks. |
| In our talk we will present our experiences, the technologies used and possible |
| future directions of the development of source-to-source transformation tools. |
| </p> |
| |
| <p> |
| <b><a id="talk10">LLVM Interpreter, a key component in validation of OpenCL compilers |
| </a></b><br> |
| <i>Oleg Maslov - Intel</i><br> |
| In this presentation we show how we use LLVM interpreter to create a validation |
| tool chain for OpenCL compilers which is isolated from the OpenCL runtime. |
| LLVM interpreter produces bitwise accurate results and is used as a reference |
| OpenCL engine. This infrastructure is used in pre silicon enablement of MIC |
| and X86 OpenCL compilers. It is also used to validate correctness of the |
| workloads during ongoing development of the compilers. As part of the work |
| we extended existing interpreter to support the missing vector and aggregate |
| data types and plan to upstream the changes to llvm.org. |
| </p> |
| |
| <p> |
| <b><a id="talk12">How to implement an LLVM Assembler - a tutorial |
| </a></b><br> |
| <i>Simon Cook - Embecosm</i><br> |
| During late 2012, working with colleague from the OpenCores |
| project, the speaker implemented a full LLVM assembler for the |
| OpenRISC 1000 architecture. This assembler was subsequently |
| integrated into the main OpenRISC LLVM compiler tool chain. |
| |
| The details of how to do this were written up as Embecosm |
| <a href="http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html"> |
| application note 11</a>, since shared on the main LLVM website. |
| In this talk the speaker will explain how to build an LLVM |
| assembler, test it and integrate it into a the LLVM compiler |
| tool chain. The talk will consider the benefits that come from |
| using an integrated LLVM assembler rather than a GNU binutils |
| standalone assembler. |
| </p> |
| |
| <p> |
| <b><a id="talk13">An experimental framework for Pragma Handling in Clang |
| </a></b><br> |
| <i>Simone Pellegrini - University of Innsbruck</i><br> |
| Clang is one of the fully featured C/C++ frontend which |
| managed to bring compiler research into the mainstream. |
| Its clean interfaces and structure enabled several new |
| research ideas to be applied to real codes in a scale that was |
| never possible in the past. However, one of the main sin |
| of researchers is the need to extend the language. Since C |
| allows language extensions through the #pragma preprocessor |
| directive, many have used this medium for feeding |
| meta-information to the compiler analysis module. A |
| very famous example is the OpenMP standard. This is |
| an extension to the semantics of C/C++ which grants to |
| the compiler the possibility of parallelizing a portion of |
| the input code. |
| However Clang's support for pragmas is lacking and |
| primitive at most. Clang allows pragma handlers to be |
| registered for a particular pragma but the user is left with |
| the burden of parsing the tokens returned by the lexer. |
| This is not a problem for many extensions which rely on |
| simple keywords and integer identifiers, however it can |
| become a parsing nightmare if a C expression is allowed |
| in the pragma (as it is the case for OpenMP). In those |
| cases, the user has to provide its own expression parser |
| which basically means rewriting Clang's parser. |
| My solution relies on a simple idea, i.e. exposing the |
| full Clang parser to pragma handlers. Together with a |
| framework which allows pragma definition to be specified |
| in EBNF form, new language extensions can be easily |
| defined in a single line of C++ code. |
| </p> |
| |
| <p> |
| <b><a id="talk14">LLVM on IBM POWER processors: a progress report |
| </a></b><br> |
| <i>Ulrich Weigand - IBM</i><br> |
| Until recently, use of LLVM on IBM processors, in particular POWER, |
| was not an issue of particular interest to IBM, and we were not |
| directly involved in LLVM development. |
| |
| This situation changed significantly during the past year, as a result |
| of more widespread use of LLVM, in particular its just-in-time compiler, |
| as an essential component of widely used open-source and proprietary |
| applications, and increased customer requests for LLVM capabilities on |
| IBM platforms. |
| |
| This led to the decision to get actively involved with the LLVM |
| community, and form a team within the IBM Linux Technology Center |
| to help enable full support for LLVM on PowerLinux. Over the past |
| several months, we have made significant progress towards that |
| goal; in particular, the LLVM 3.2 release now bootstraps and |
| passes all test suites on PowerLinux, and provides a working |
| (MC) JIT implementation. |
| |
| In this presentation I plan to report on IBM's involvement with LLVM |
| as described above and the work we've done so far, including various |
| missing features that were contributed, like support for the JIT, |
| the assembler parser and disassembler, full TLS support, medium and |
| large code models, full ABI compatibility, and Altivec enhancements. |
| I will also present methods we used to verify correctness of the |
| port, and show some examples of the more interesting bugs we found |
| and fixed in the process. |
| |
| As a long-time GCC developer with no prior experience with LLVM, |
| I will also try to give some impressions on my "learning curve" with |
| the LLVM design and code base, in particular from the perspective |
| of a processor back-end: which parts were easy to get into, and what |
| took significant effort getting used to. |
| |
| Finally, I will conclude by presenting ongoing work on features |
| that are still missing to provide first-class support for POWER, |
| and our plans for future continued involvement with LLVM. |
| </p> |
| |
| <!-- *********************************************************************** --> |
| <h2 id="tutoabstract">Tutorial abstracts</h2> |
| <p> |
| <b><a id="tuto1">The Clang AST - a tutorial |
| </a></b><br> |
| <i>Manuel Klimek - Google</i><br> |
| For engineers starting to contribute to Clang or writing tools based on Clang, |
| the AST is often the first big stumbling stone. While it merely mirrors the |
| complexity of the languages it represents, learning how to navigate between |
| the nodes can be a daunting task. |
| In this tutorial I will present the structure of Clang's AST, how the nodes |
| match to C++ language constructs and how to make good use of the documentation |
| and tools available to navigate the maze to find what you need. |
| |
| We will take an in-depth look at various common connections, like templates and |
| their definitions, source locations and types, dependent types, typedefs, and |
| more. |
| |
| Using simple code samples I'll walk through the basic handling of AST nodes, |
| and dive into more advanced topics focusing on the C++ specific parts of the |
| AST. |
| </p> |
| |
| <!-- *********************************************************************** --> |
| <h2 id="posterabstract">Poster abstracts</h2> |
| <p> |
| <b><a id="poster9">LLVM IR editor plugin for Eclipse |
| </a></b><br> |
| <i>Alon Mishne & Ayal Zaks - Intel</i><br> |
| LLVM IR SDK is an Eclipse plugin that adds an LLVM IR (.ll files) editor to |
| Eclipse. Intended for LLVM developers, it is designed to provide nearly the |
| same level of support for IR files that other programming languages enjoy under |
| Eclipse, making it easier to write tests and analyze pass output. By |
| incorporating a wide range of validation checks <q>as you type</q> - from simple |
| syntax checks through full type validation and up to dominance analysis - the |
| plugin enables a quick modify-and-run cycle for IR files, without having to run |
| LLVM module validation in-between. In addition, the plugin exposes a variety of |
| <q>quick-fix</q> options for common code actions, such as fixing broken number |
| sequence for local names, inserting conversions between types, inserting |
| function declarations inferred from a function call, and more. |
| </p> |
| |
| <p> |
| <b><a id="poster1">Sambamba: A Runtime System for Online Adaptive Parallelization |
| </a></b><br> |
| <i>Clemens Hammacher - Saarland University, Germany</i><br> |
| Automatic parallelization is a classical compiler problem: Using static analyses, the compiler |
| tries to prove computations independent from each other, and estimates the benefit that would |
| be gained by executing these codes in parallel. Both of these tasks represent huge challenges, |
| as neither the input data nor characteristics of the execution platform are typically known |
| at compile time. However, those factors mainly determine where parallelization is applicable |
| and beneficial. Because of this discrepancy, the effectiveness of parallelizing compilers is |
| very limited. |
| On the other hand, manual parallelization has also proven to be a serious hurdle for the |
| majority of developers. A lot of new languages and programming libraries have been built |
| to support programmers in that task, but all of them still require expertise in order to build |
| efficient applications. Sometimes runtime support is installed, such as software transactional |
| memory, to enable speculative parallelization where the independence of computations can not |
| be proven. This makes it even harder to estimate whether the overhead will pay off at runtime, |
| in the sense of an overall performance improvement. |
| Therefore, we propose an automatic runtime-adaptive system. It executes the target application |
| in a lightweight virtual machine, and constantly monitors its runtime behaviour. This |
| information is then used to decide where and how to parallelize. This way, alternative variants |
| of individual functions are provided, which have been optimized for the observed input. Those |
| variants do not immediately replace previous code by installing them into the running |
| application, but it is the runtime system's responsibility to identify the best performing |
| variant for the situation at hand. |
| </p> |
| |
| <p> |
| <b><a id="poster2">LLVM backend for TILE64 |
| </a></b><br> |
| <i>Dávid Juhász</i><br> |
| LLVM provides a platform-independent intermediate layer for developers of highlevel |
| programming languages. Benefits of transforming high-level programs into LLVM |
| IR are twofold: high-level to intermediate compilation does not have to deal with |
| platform-specific details, still executables for many different architectures can be compiled |
| using back-ends already implemented for the LLVM toolchain. |
| Programs in platform-independent intermediate representation are to be analyzed |
| and transformed in order to be optimized, e.g. run faster or consume less memory, |
| and to generate executable code. The last major step of processing programs is code |
| generation which can be done using LLVM back-ends. LLVM has a target-independent |
| code generator, in which the most common features for turning a target-independent |
| representation into a platform-specific assembly or binary are implemented. An LLVM |
| back-end is mainly the parameterization of the target-independent code generator with |
| platform-specific properties. In many cases, the default implementation of different |
| parts of the code generation fits well to the target. However, overriding some features |
| is necessary for architectures which are to some extents different from the mainstream |
| ones. |
| Tile64 was the first commercial product of Tilera Corporation back in 2007, that has |
| been followed by other more sophisticated Tilera processors. Tile64 is an energy-efficient |
| massively parallel processor architecture. It consists of 64 general purpose processor |
| cores (tiles) connected by a mesh-network. Each core has 3 pipelines, two of them are |
| for integer and logical operations and the third one is a load-store unit. The shortpipeline, |
| in-order, three-issue (there are two-issue bundles as well) cores implement a |
| VLIW instruction set supporting RISC instructions extended with various SIMD and |
| DSP-related operations. The processor is very capable of communication both inside |
| and outside the mesh-network. The speed of the interconnection between tiles is one |
| hop per tick, and the edges of the mesh are connected to different I/O interfaces (four |
| DDR2 controllers, two 10-gigabit Ethernet interfaces, two four-lane PCIe interfaces, |
| and a software-configured "flexible" I/O interface). |
| Tile64 is in many ways different from the mainstream processor architectures, thus |
| implementing an LLVM back-end for Tile64 posed several questions. Some of those |
| questions and tricky parts of implementation are to be revealed in the poster. |
| </p> |
| |
| <p> |
| <b><a id="poster3">MCLinker: Design and Implementation of a Fragments-based Target-independent Linker |
| </a></b><br> |
| <i>Diana Chen - MediaTek Inc.</i><br> |
| MCLinker is a system linker that uses fragments as its internal intermediate |
| representations (IRs) to process inputs, such as a .o file, and generate |
| desired output file. Valid inputs for now are: .o, .a, .so, and a piece of |
| in-memory of code; and valid outputs are: .o, .so, and executable binary. |
| Fragments are good IRs for a linker in a way that these fragments can easily |
| generate data structures to be used by linkers. Fragments can be either a |
| function, a block of code, or a defined symbol with a memory region. For |
| instance, the global offset table in a typical .so and the frame description |
| table in DWARF format of MCLinker are made directly from fragments. Another |
| reason is linking finer-grained fragments could lead to a more optimized |
| result as opposed to coarse-grained sections, because finer-grained fragments |
| would facilitate better data-stripping and reordering. |
| However, LLVM MC fragments are originally designed for assembler so they could |
| not fulfill some requirements from linkers. Thus, MCLinker needs to define some |
| additional fragment types. For example, MCLinker defines general "relocation |
| fragments" and "stub fragments" to represent stubs of the branch islands. |
| MCLinker also defines “region fragment” to hold arbitrary blocks of code or |
| data. Furthermore, MCLinker introduces a general reference linkage between |
| two fragments to represent their relocation relationship. |
| MCLinker is a full-fledged system linker. It is capable of linking ELF object |
| files on various platforms, such as ARM, x86, and MIPS. Some additional targets, |
| such as x86-64 and x32, are still in development and will be available soon. |
| MCLinker fully supports complex ELF features, such as DWARF debugging, Itanium |
| exception handling, COMDAT sections, instruction relaxation, and GNU archive |
| format. |
| </p> |
| |
| <p> |
| <b><a id="poster4">ENHANCE - Enabling heterogeneous hardware acceleration using novel programming and scheduling models |
| </a></b><br> |
| <i>Dustin Feld</i><br> |
| Developers faced with the task of creating parallel applications on |
| heterogeneous computing architectures often fail to reach acceptable |
| performance and speed-up values due to sub-optimal communication patterns |
| in their application. At the same time, the operating system often is |
| not able to reach optimal resource utilization, due to missing possibilities |
| for relocating user threads and user processes across hardware boundaries. |
| Some of these issues can already be tackled at compile time if the compiler is |
| able to understand coding and design patterns and acts accordingly. |
| |
| In this presentation we introduce an automatic framework for parallelization, |
| check-pointing, and task scheduling based on the LLVM compiler framework. Our |
| work includes techniques which facilitate an efficient usage of heterogeneous |
| resources with a dynamic and automated approach. Furthermore, a task scheduling |
| framework on a single node basis takes care of the fair use scheduling of |
| available hardware resource in a multi-user environment. |
| </p> |
| |
| <p> |
| <b><a id="poster10">OJIT: A novel secure remote execution technology by obfuscated Just-In-Time compilation |
| </a></b><br> |
| <i>Muhammad Hataba - Egypt-Japan University for Science and Technology</i><br> |
| This poster presents the Obfuscating Just-In-Time compilation (OJIT) technique. |
| OJIT is a novel security technique for a trustworthy and secured code execution |
| on a remote premise such as the cloud-computing environment. We rely on the |
| principles of obscurity for the sake of security, which is a concept widely |
| popular in software protection. LLVM's just-in-time (JIT) compilation is used |
| to dynamically obfuscate code, making the generated code unintelligible and |
| hence difficult to reverse engineer. We obfuscate the code by an array of |
| randomly yet dynamically changing techniques that are independent of the source |
| language of the executed program yet neutral to the platform that we are |
| executing on. We evaluated the technique by measuring a variety of obfuscation |
| metrics running a set of benchmark programs. |
| </p> |
| |
| <p> |
| <b><a id="poster5">Code Editing in Local Style |
| </a></b><br> |
| <i>Peter Conn - Cambridge University</i><br> |
| Coding styles contain a variety of elements, from indenting rules to variable |
| and function names. They also place different constraints on variable declarations, |
| for example requiring them at the start of the function or in the smallest |
| possible scope. |
| Some of these can be automatically checked with purely syntactic checkers, |
| such as typical implementations of the UNIX indent tool. Others require |
| semantic knowledge. For example, moving a variable declaration requires knowing |
| where all of its uses are. |
| The goal of the CELS (Code Editing in Local Style) tool is to allow each |
| developer to edit code in their preferred style, while preserving a uniform style |
| in the repository. It includes the ability to specify complex styles, to infer styles |
| from an existing corpus of source code, and to perform automatic formatting. |
| CELS is written as a library on top of libclang, allowing it to be embedded in |
| code editors and IDEs without relying on unstable binary interfaces. It traverses |
| the AST exposed by libclang and builds a scope tree, renames symbols, moves |
| declarations, and wraps lines. |
| The line-wrapping algorithm used is based on the TEX line breaking algorithm. |
| The user may specify different penalties for different line breaking |
| locations, for example encoding rules such as `prefer to break after an operator, |
| try to avoid breaking before a comma, breaking after a semicolon is best' and |
| have the lines wrapped accordingly. Additionally, the typesetter is aware of |
| the distinction between whitespace used for indentation and whitespace used |
| for alignment and so can use different characters for either, for example using |
| tabs for indentation and spaces for alignment, allowing the resulting code to be |
| viewed with any tab size without losing alignment. |
| </p> |
| |
| <p> |
| <b><a id="poster6">Noise: A Clang Extension for User-Defined Optimization Strategies |
| </a></b><br> |
| <i>Ralf Karrenberg - Saarland University</i><br> |
| In this talk, we present "Noise", a language extension to Clang that enables a |
| programmer to control the optimization process on a code region. |
| Noise is a language extension that allows a programmer to create custom |
| optimization strategies and apply them to specific code segments. |
| This enables fine-grained control over the optimizations applied by the compiler |
| to conveniently tune code without actually rewriting it. |
| With Noise, the programmer can easily choose optimizations and their order |
| without interfering with the standard optimizations being applied to the |
| remaining program. |
| This is especially important for legacy code in the High-Performance Computing |
| (HPC) environment, but is also relevant in other performance-sensitive fields |
| such as computer graphics. |
| We present our implementation for C/C++ within the Clang frontend using |
| attributes. In addition to exposing LLVM's internal optimization phases, |
| Noise also has special transformations built-in, for example data-parallel loop |
| vectorization on the basis of "Whole-Function Vectorization". |
| We show first results demonstrating the effectiveness of Noise on HPC code in |
| production. |
| </p> |
| |
| <p> |
| <b><a id="poster7">Improving Machine Code Generation Quality by Interfacing VPO with LLVM |
| </a></b><br> |
| <i>Ryan Baird - Boise State University</i><br> |
| Very Portable Optimizer (VPO) is a research compiler backend |
| that performs optimizations on a single intermediate representation |
| called Register Transfer Lists (RTLs). RTLs are at the level of machine |
| instructions, and therefore most of VPO's code improving |
| optimizations can be performed in a machine independent way and |
| optimization phases can be repeated in an arbitrary order. For these |
| merits, VPO is widely used to optimize machine code that exploits |
| various architecture features on low-power embedded processors. |
| However, VPO uses LCC as a front-end, which does not support |
| current language standards (C99,C++98) and has no mid-level |
| code improving transformations. The contributions of this poster |
| are two-fold. First, it describes our approach to extend both the |
| code coverage and the quality of VPO machine code generation by |
| streamlining the compiler with LLVM instead of LCC. Second, |
| it provides some insight to the LLVM community into alternative |
| machine code generation, which can be effectively achieved by interfacing |
| with an existing optimizing compiler instead of creating |
| a different machine port within LLVM. |
| </p> |
| |
| <p> |
| <b><a id="poster8">Using the LLVM Interpreter to Quantify Applications Inherent Properties |
| </a></b><br> |
| <i>Victoria Caparros - ETH Zurich</i><br> |
| This poster presents a tool based on the LLVM |
| interpreter for quantifying application's inherent properties. |
| Our approach to quantifying applications properties |
| is based on previous studies that use a microarchitectural |
| simulator to emulate a machine with unlimited hardware |
| resources, and quantify application behavior from |
| the analysis of the data dependences and data movement |
| properties of the dynamic instruction trace during execution |
| on the simulator [2]. This approach has several |
| advantages. First, application properties are measured |
| for the particular input considered, as opposed to the |
| theoretical analysis of the algorithm, which does not consider |
| input size. Second, it provides a better insight into |
| application behavior, since it exposes a broader range of |
| application properties, not only those that are exploitable |
| with existing microarchitectural features (what can be |
| measured with hardware performance counters on a |
| target platform), but also properties that may require |
| new hardware features in order to be exploited. Finally, |
| this approach enables us to reason about application's |
| performance across different platforms with just a single |
| pass of the analysis, not requiring to repeat the analysis |
| for every hardware configuration of interest. |
| </p> |
| |
| |
| <!-- *********************************************************************** --> |
| <h2 id="ltalkabstract">Lightning talk abstracts</h2> |
| <p> |
| <b><a href="#poster1">Sambamba: A Runtime System for Online Adaptive Parallelization |
| </a></b><br> |
| <i>Clemens Hammacher - Saarland University, Germany</i><br> |
| </p> |
| |
| <p> |
| <b><a id="ltalk2">Integrating fine-grained timing constraints into LLVM |
| </a></b><br> |
| <i>David Lacey - XMOS Ltd</i><br> |
| This talk covers a problem we are just beginning to tackle of |
| integrating fine-grained timing constraints into LLVM. |
| |
| Code written for real-time tasks often comes with worst case |
| timing constraints on paths within the program (usually between I/O |
| operations). These paths can be quite short or can cross across |
| basic blocks and function boundaries. |
| |
| Unfortunately, the optimizations within LLVM are not aware of these |
| constraints and code motion or control flow optimizations |
| can move calculations into a critical path quite easily. |
| |
| I'll cover the experiences we've had with the optimizations in the |
| compiler and go over the initial ideas we have to tackle the problem. |
| </p> |
| |
| <p> |
| <b><a href="#poster3">MCLinker: Design and Implementation of a Fragments-based Target-independent Linker |
| </a></b><br> |
| <i>Diana Chen - MediaTek Inc.</i><br> |
| </p> |
| |
| <p> |
| <b><a id="ltalk4">FDO-based whole program optimization in LLVM |
| </a></b><br> |
| <i>Diego Novillo - Google</i><br> |
| At Google, we achieve the highest levels of performance using whole program optimization. |
| However, traditional whole program optimization does not scale to the size of applications |
| that we are interested in optimizing. |
| |
| In this lightning talk, I will briefly describe the FDO technologies that we have implemented, |
| how we apply them to whole program optimization and our plans to port this technology to |
| the LLVM compiler. |
| </p> |
| |
| <p> |
| <b><a id="ltalk5">Efficient audio signal processing using LLVM and Haskell |
| </a></b><br> |
| <i>Henning Thielemann</i><br> |
| I am using LLVM for audio signal processing via Haskell. |
| My goal is to combine the safety and elegance of Haskell |
| with the speed of code generated by LLVM. |
| |
| My approach is an embedded domain specific language (EDSL), |
| that is, my library provides Haskell functions |
| that look like signal processing functions, |
| but actually they represent pieces of LLVM assembly code. |
| Composing such signal functions means |
| assembling large LLVM code blocks from smaller ones. |
| |
| I use the JIT for turning the LLVM code into executable C functions. |
| This also allows me to adapt to available processor extensions like SSE and AVX |
| at startup time of a signal processing program. |
| |
| I make intensive use of the vector instructions of LLVM. |
| </p> |
| |
| <p> |
| <b><a href="#poster6">Noise: A Clang Extension for User-Defined Optimization Strategies |
| </a></b><br> |
| <i>Ralf Karrenberg - Saarland University</i><br> |
| </p> |
| |
| <p> |
| <b><a id="poster7">Rebuild of all Debian packages using Clang instead of gcc |
| </a></b><br> |
| <i>Sylvestre Ledru - Debian / IRILL</i><br> |
| Besides the GNU/Linux kernel, Debian is now able to run with two others |
| kernels (KFreeBSD & HURD). However, in terms of compilation, Debian is |
| still coupled to gcc. |
| This lightning talk will present the results of the rebuild of the whole |
| Debian archive with various clang versions. A necessary step to make |
| Debian compiler agnostic. |
| </p> |
| <!-- *********************************************************************** --> |
| <hr> |
| |
| <!--#include virtual="../../footer.incl" --> |