[www] r178963 - Euro-LLVM-2013: Add talk, poster and lightning talk abstracts

[Arnaud A. de Grandmaison]

Author: aadg
Date: Sat Apr  6 15:34:29 2013
New Revision: 178963

URL: http://llvm.org/viewvc/llvm-project?rev=178963&view=rev
Log:
Euro-LLVM-2013: Add talk, poster and lightning talk abstracts

Modified:
    www/trunk/devmtg/2013-04/index.html

Modified: www/trunk/devmtg/2013-04/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2013-04/index.html?rev=178963&r1=178962&r2=178963&view=diff
==============================================================================
--- www/trunk/devmtg/2013-04/index.html (original)
+++ www/trunk/devmtg/2013-04/index.html Sat Apr  6 15:34:29 2013
@@ -17,13 +17,16 @@
         <tr><td valign="top">
 <ol>
         <li><a href="#announcements">Announcements</a></li>
-        <li><a href="#callfor">Call for Speakers, Posters, Demos</a></li>
+        <!-- <li><a href="#callfor">Call for Speakers, Posters, Demos</a></li> -->
+        <li><a href="#schedule">Schedule</a></li>
+        <li><a href="#talkabstract">Talk abstracts</a></li>
+        <li><a href="#posterabstract">Poster abstracts</a></li>
+        <li><a href="#ltalkabstract">Lightning talk abstract</a></li>
         <li><a href="#registration">Registration</a></li>
         <li><a href="#location">Location</a></li>
         <li><a href="#hotel">Hotels</a></li>
         <li><a href="#organisation">Organization</a></li>
         <li><a href="#support">Financial Support</a></li>
-        <li><a href="#schedule">Schedule</a></li>
 </ol>
 </td><td>
     <ul>
@@ -50,6 +53,7 @@ more time for presentations and networki
 whether from business or academia, professional or enthusiast and is not
 restricted to those from Europe - attendees from all regions are welcome.
 
+<!--
 <h2 id="callfor">Call for Speakers, Posters, Demos</h2>
 
 We invite academic, industrial and hobbyist speakers to present their work on
@@ -102,7 +106,597 @@ is from one paragraph to half of a colum
 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="schedule">Schedule</h2>
+
+The detailed schedule is not yet announced. However, we plan to have talks
+between Monday noon and Tuesday noon, supplemented by more informal meetings
+and workshops on Tuesday afternoon. There will be the social on Monday evening
+and possibly an informal evening meetup on Tuesday.
+
+<!-- *********************************************************************** -->
+<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 - 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="talk11">Implementing Data Layout Optimizations in LLVM Framework
+</a></b><br>
+<i>Prashantha Naduthota</i><br>
+The difference in speeds between processor and memory are increasing day by
+day. Compilers try to alleviate the same by different strategies.
+For regular array accesses in loops, array access patterns are modifed
+for better cache behaviour subject to program correctness.
+Large structure fields can be reordered for better cache behaviour
+by modifying the layout of the data. In this work, we discuss the different
+Data Layout Optimizations implemented in LLVM frame work to gain better
+memory behaviour. CPU 2006 SPEC benchmarks showed impressive gains upto 140
+percent because of the optimizations.
+</p>
+
+<p>
+<b><a id="talk12">How to implement an LLVM Assembler
+</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="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>
+</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>
+</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</i><br>
+</p>
+
+
+<!-- *********************************************************************** -->
 <h2 id="registration">Registration</h2>
 
 <p>We have reached the limit of 150 attendees for the conference. Registration
@@ -180,13 +774,6 @@ sponsorship and companies' interest in s
 If you need funding to attend the meeting, or can help sponsor, please tell us
 on the registration form.
 
-<h2 id="schedule">Schedule</h2>
-
-The detailed schedule is not yet announced. However, we plan to have talks
-between Monday noon and Tuesday noon, supplemented by more informal meetings
-and workshops on Tuesday afternoon. There will be the social on Monday evening
-and possibly an informal evening meetup on Tuesday.
-
 <!-- *********************************************************************** -->
 <hr>
 <address>