<!--#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 &amp; 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&aacutevid Juh&aacutesz</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>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>Venue Quality</td><td>96%</td></tr>
<tr><td>Venue Food &amp; Drinks</td><td>77%</td></tr>
<tr><td>Venue Rooms &amp; Equipment</td><td>73%</td></tr>
<tr><td>Venue Location</td><td>99%</td></tr>
<tr><td>&nbsp;</td><td>&nbsp;</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 &amp; Posters</td><td>94%</td></tr>
<tr><td>&nbsp;</td><td>&nbsp;</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>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>Dinner Cruise Overall</td><td>100%</td></tr>
<tr><td>Dinner Cruise Food &amp; 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 &amp; 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 &amp; 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&aacutevid Juh&aacutesz</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 &amp; 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" -->