SPONSORED BY:

      ARM, HSA Foundation, Google, Intel, Codeplay, Microsoft, Microsoft Research

The hacker's lab & networking session is sponsored by Solid Sands

The LLVM Foundation announces the sixth annual European LLVM Developers' Meeting will be held March 17th and 18th in Barcelona, Spain.

This year, the conference will be collocated with CGO and CC, enabling collaboration and exchange of ideas with the research community.

The conference will be 2 full days that include technical talks, BoFs, hacker’s lab, tutorials, and a poster session.

The meeting serves as a forum for LLVM, Clang, LLDB and other LLVM project developers and users to get acquainted, learn how LLVM is used, and exchange ideas about LLVM and its (potential) applications. More broadly, we believe the event will be of particular interest to the following people:

• Active developers of projects in the LLVM Umbrella (LLVM core, Clang, LLDB, libc++, compiler_rt, klee, dragonegg, lld, etc).
• Anyone interested in using these as part of another project.
• Compiler, programming language, and runtime enthusiasts.
• Those interested in using compiler and toolchain technology in novel and interesting ways.

Please sign up for the LLVM Developers' Meeting list for future announcements and to ask questions.

You may also contact the organizer: Vladimir Subotic

The schedule may be found here: https://2016europeanllvmdevelopersmeetin.sched.org

Clang, libc++ and the C++ standard
Marshall Clow - Qualcomm
Richard Smith - Google
Slides Video
The C++ standard is evolving at a fairly rapid pace. After almost 15 years of little change (1998-2010), we've had major changes in 2011, 2014, and soon (probably) 2017. There are many parallel efforts to add new functionality to the language and the standard library.

In this talk, we will discuss upcoming changes to the language and the standard library, how they will affect existing code, and their implementation status in LLVM.

Codelet Extractor and REplayer
Chadi Akel - Exascale Computing Research
Pablo De Oliveira Castro - University of Versailles
Michel Popov - University of Versailles
Eric Petit - University of Versailles
William Jalby - University of Versailles
Slides Video
Codelet Extractor and REplayer (CERE) is an LLVM-based framework that finds and extracts hotspots from an application as isolated fragments of code. Codelets can be modified, compiled, run, and measured independently from the original application. Through performance signature clustering, CERE extracts a minimal but representative codelet set from applications, which can significantly reduce the cost of benchmarking and iterative optimization. Codelets have proved successful in auto-tuning target architecture, compiler optimization or amount of parallelism. To do so, CERE goes trough multiple llvm passes. It first outlines at IR level the loop to capture into a function using CodeExtractor pass. Then, depending on the mode, CERE inserts the necessary instructions to either capture or replay the loop. Probes can also be inserted at IR level around loops to enable instrumentation through externals libraries. Finally CERE also provides a python interface to easily use the tool.

New LLD linker for ELF
Rui Ueyama - Google
Slides Video
Since last year, we have been working to rewrite the ELF support in LLD, the LLVM linker, to create a high-performance linker that works as a drop-in replacement for the GNU linker. It is now able to bootstrap LLVM, Clang, and itself and pass all tests on x86-64 Linux and FreeBSD. The new ELF linker is small and fast; it is currently fewer than 10k lines of code and about 2x faster than GNU gold linker.

In order to achieve this performance, we made a few important decisions in the design. This talk will present the design and the performance of the new ELF LLD.

Improving LLVM Generated Code Size for X86 Processors David Kreitzer - Intel
Zia Ansari - Intel
Andrey Turetskiy - Intel
Anton Nadolsky - Intel
Slides Video
Minimizing the size of compiler generated code often takes a back seat to other optimization objectives such as maximizing the runtime performance. For some applications, however, code size is of paramount importance, and this is an area where LLVM has lagged gcc when targeting x86 processors. Code size is of particular concern in the microcontroller segment where programs are often constrained by a relatively small and fixed amount of memory. In this presentation, we will detail the work we did to improve the generated code size for the SPEC CPU2000 C/C++ benchmarks by 10%, bringing clang/LLVM to within 2% of gcc. While the quoted numbers were measured targeting Intel® Quark™ microcontroller D2000, most of the individual improvements apply to all X86 targets. The code size improvement was achieved via new optimizations, tuning of existing optimizations, and fixing existing inefficiencies. We will describe our analysis methodology, explain the impact and LLVM compiler fix for each improvement opportunity, and describe some opportunities for future code size improvements with an eye toward pushing LLVM ahead of gcc on code size.

Towards ameliorating measurement bias in evaluating performance of generated code
Kristof Beyls - ARM
Slides Video
To make sure LLVM continues to optimize code well, we use both post-commit performance tracking and pre-commit evaluation of new optimization patches. As compiler writers, we wish that the performance of code generated could be characterized by a single number, making it straightforward to decide from an experiment whether code generation is better or worse. Unfortunately, performance of generated code needs to be characterized as a distribution, since effects not completely under control of the compiler, such as heap, stack and code layout or initial state in the processors prediction tables, have a potentially large influence on performance. For example, it's not uncommon when benchmarking a new optimization pass that clearly makes code better, the performance results do show some regressions. But are these regressions due to a problem with the patch, or due to noise effects not under the control of the compiler? Often, the noise levels in performance results are much larger than the expected improvement a patch will make. How can we properly conclude what the true effect of a patch is when the noise is larger than the signal we're looking for?

When we see an experiment that shows a regression while we know that on theoretical grounds the generated code is better, we see a symptom of only measuring a single sample out of the theoretical space of all not-under-the-compiler's-control factors, e.g. code and data layout variation.

In this presentation I'll explain this problem in a bit more detail; I'll summarize suggestions for solving this problem from academic literature; I'll indicate what features in LNT we already have to try and tackle this problem; and I'll show the results of my own experiments on randomizing code layout to try and avoid measurement bias.

A journey of OpenCL 2.0 development in Clang
Anastasia Stulova - ARM
Slides Video
In this talk we would like to highlight some of the recent collaborative work among several institutions (namely ARM, Intel, Tampere University of Technology, and others) for supporting OpenCL 2.0 compilation in Clang. This work is represented by several patches to Clang upstream that enable compilation of the new standard. While the majority of this work is already committed, some parts are still a work in progress that should be finished in the upcoming months.

OpenCL is a C99 based language, standardized and developed by the Khronos Group (www.khronos.org), intended to describe data-parallel general purpose computations. OpenCL 2.0 provides several new features that require compiler support, i.e. generic address space, atomics, program scope variables, pipes, and device side enqueue. In this talk we will give a quick overview of each of these features and the compiler support that had/has to be added. We will focus on the benefits of reusing existing C/OpenCL compiler features as well as difficulties not foreseen with the previous design. At the end of this session we would like to invite people to participate in discussions on improvements and future work, and get an opinion of what they think could be useful for them.

Building a binary optimizer with LLVM
Maksim Panchenko - Facebook
Slides Video
Large-scale applications in data centers are built with the highest level of compiler optimizations and typically use a carefully tuned set of compiler options as every single percent of performance could result in vast savings of power and CPU time. However, code and code-layout optimizations don't stop at compiler level, as further improvements are possible at link-time and beyond that.

At Facebook we use a linker script for an optimal placement of functions in HHVM binary to eliminate instruction-cache misses. Recently, we've developed a binary optimization technology that allows us to further cut instruction cache misses and branch mis-predictions resulting in even greater performance wins.

In this talk we would like to share technical details of how we've used LLVM's MC infrastructure and ORC layered approach to code generation to build in a short time a system that is being deployed to one of the world's biggest data centers. The static binary optimization technology we've developed, uses profile data generated in multi-threaded production environment, and is applicable to any binary compiled from well-formed C/C++ and even assembly. At the moment we use it on a 140MB of X86 binary code compiled from C/C++. The input binary has to be un-stripped and does not have any special requirements for compiler or compiler options. In our current implementation we were able to improve I-cache misses by 7% on top of a linker script for HHVM binary. Branch mis-predictions were improved by 5%.

As with many projects at Facebook, our plan is to open source our binary optimizer.

SVF: Static Value-Flow Analysis in LLVM
Yulei Sui - University of New South Wales
Peng Di - University of New South Wales
Ding Ye - University of New South Wales
Hua Yan - University of New South Wales
Jingling Xue - University of New South Wales
Slides Video
This talk presents SVF, a research tool that enables scalable and precise interprocedural Static Value-Flow analysis for sequential and multithreaded C programs by leveraging recent advances in sparse analysis. SVF, which is fully implemented in LLVM (version 3.7.0) with over 50 KLOC core C++ code, allows value-flow construction and pointer analysis to be performed in an iterative manner, thereby providing increasingly improved precision for both. SVF accepts points-to information generated by any pointer analysis (e.g., Andersen's analysis) and constructs an interprocedural memory SSA form, in which the def-use chains of both top-level and address-taken variables are captured. Such value-flows can be subsequently exploited to support various forms of program analysis or enable more precise pointer analysis (e.g., flow-sensitive analysis) to be performed sparsely. SVF provides an extensible interface for users to write their own analysis easily. SVF is publicly available at http://unsw-corg.github.io/SVF.

We first describe the design and internal workings of SVF, based on a years-long effort in developing the state-of-the-art algorithms of precise pointer analysis, memory SSA construction and value-flow analysis for C programs. Then, we describe the implementation details with code examples in the form of LLVM IR. Next, we discuss some usage scenarios and our previous experiences in using SVF in several client applications including detecting software bugs (e.g., memory leaks, data races), and accelerating dynamic program analyses (e.g., MSAN, TSAN). Finally, our future work and some open discussions.

Note: this presentation will be shared with CC.

Run-time type checking with clang, using libcrunch
Chris Diamand - University of Cambridge
Stephen Kell - Computer Laboratory, University of Cambridge
David Chisnall - Computer Laboratory, University of Cambridge
Slides Video
Existing sanitizers ASan and MSan add run-time checking for memory errors, both spatial and temporal. However, currently there is no analogous way to check for type errors. This talk describes a system for adding run-time type checks, largely checking pointer casts, at the Clang AST level.

Run-time type checking is important for three reasons. Firstly, type bugs such as bad pointer casts can lead to type-incorrect accesses that are spatially valid (in bounds) and temporally valid (accessing live memory), so are missed by MSan or ASan. Secondly, type-incorrect accesses which do trigger memory errors often do so only many instructions later, meaning that spatial or temporal violation warnings fail to pinpoint the root problem, making debugging difficult. Finally, given an awareness of type, it becomes possible to perform more precise spatial and temporal checking -- for example, recalculating pointer bounds after a cast, or perhaps even mark-and-sweep garbage collection.

Although still a research prototype, libcrunch can cope well with real C codebases, and supports a good complement of awkward language features. Experience shows that libcrunch reliably finds questionable pointer use, and often uncovers minor other bugs. It also naturally detects certain format string exploits. However, its main value is in debugging fresh, not-yet-committed code ("why is this segfaulting?"). Beside the warnings generated by failing checks, the runtime API is also available from the debugger, so can interactively answer questions like "what type is this really pointing to?".

Molly: Parallelizing for Distributed Memory using LLVM
Michael Kruse - INRIA/ENS
Slides Video
Motivated by modern day physics which in addition to experiments also tries to verify and deduce laws of nature by simulating the state-of-the-art physical models using large computers, we explore means of accelerating such simulations by improving the simulation programs they run. The primary focus is Lattice Quantum Chromodynamics (QCD), a branch of quantum field theory, running on IBM newest supercomputer, the Blue Gene/Q.

Molly is an LLVM compiler extension, complementary to Polly, which optimizes the distribution of data and work between the nodes of a cluster machine such as Blue Gene/Q. Molly represents arrays using integer polyhedra and uses another already existing compiler extension Polly which represents statements and loops using polyhedra. When Molly knows how data is distributed among the nodes and where statements are executed, it adds code that manages the data flow between the nodes. Molly can also permute the order of data in memory.

Molly's main task is to cluster data into sets that are sent to the same target into the same buffer because single transfers involve a massive overhead. We present an algorithm that minimizes the number of transfers for unparametrized loops using anti-chains of data flows. In addition, we implement a heuristic that takes into account how the programmer wrote the code. Asynchronous communication primitives are inserted right after the data is available respectively just before it is used. A runtime library implements these primitives using MPI. Molly manages to distribute any code that is representable in the polyhedral model, but does so best for stencils codes such as Lattice QCD. Compiled using Molly, the Lattice QCD stencil reaches 2.5% of the theoretical peak performance. The performance gap is mostly because all the other optimizations are missing, such as vectorization. Future versions of Molly may also effectively handle non-stencil codes and use make use of all the optimizations that make the manually optimized Lattice QCD stencil fast.

How Polyhedral Modeling enables compilation to Heterogeneous Hardware
Tobias Grosser - ETH
Slides Video
Polly, as a polyhedral loop optimizer for LLVM, is not only a sophisticated tool for data locality optimizations, but also has precise information about loop behavior that can be used to automatically generate accelerator code.

In this presentation we present a set of new Polly features that have been introduced throughout the last two years (and as part of two GSoC projects) that enable the use of Polly in the context of compilation for heterogeneous systems. As part of this presentation we discuss how we use Polly to derive the precise memory footprints of compute regions for both flat arrays as well as multi-dimensional arrays of parametric size. We then present a new, high-level interface that allows for the automatic remapping of memory access functions to new locations or data-layouts and show how this functionality can be used to target software managed caches. Finally, we present our latest results in terms of automatic PTX/CUDA code generation using Polly as a core component.

Bringing RenderScript to LLDB
Luke Drummond - Codeplay
Ewan Crawford - Codeplay
Slides Video
RenderScript is Android's compute framework for parallel computation via heterogeneous acceleration. It supports multiple target architectures and uses a two-stage compilation process, with both off-line and on-line stages, using LLVM bitcode as its intermediate representation. This split allows code to be written and compiled once, before execution on multiple architectures transparently from the perspective of the programmer.

In this talk, we give a technical tour of our upstream RenderScript LLDB plugin, and how it interacts with Android applications executing RenderScript code. We provide a brief overview of RenderScript, before delving into the LLDB specifics. We will discuss some of the challenges that we encountered in connecting to the runtime, and present some of the specific implementation techniques we used to hook into it and inspect its state. In addition, we will describe how we tweaked LLDB's JIT compiler for expression evaluation, and how we added commands specific to RenderScript data objects. This talk will cover topics such as the plug-in architecture of LLDB, the debugger's powerful hook mechanism, remote debugging, and generating debug information with LLVM.

C++ on Accelerators: Supporting Single-Source SYCL and HSA Programming Models Using Clang
Victor Lomuller - Codeplay
Ralph Potter - Codeplay
Uwe Dolinsky - Codeplay
Slides Video
Heterogeneous systems have been massively adopted across a wide range of devices. Multiple initiatives, such as OpenCL and HSA, have appeared to efficiently program these types of devices.

Recent initiatives attempt to bring modern C++ applications to heterogeneous devices. The Khronos Group published SYCL in mid-2015. SYCL offers a single-source C++ programming environment built on top of OpenCL. Codeplay and the University of Bath are currently collaborating on a C++ front-end for HSAIL (HSA Intermediate Language) from the HSA Foundation. Both models use a similar single-source C++ approach, in which the host and device kernel C++ code is interleaved. A kernel always starts using specific function calls, which take a functor object. To support the compilation of these two high-level programming models, Codeplay's compilers rely on a common engine based on Clang and LLVM to extract and manipulate those kernels.

In this presentation we will briefly present both programming models and then focus on Codeplay's usage of Clang to manage both models.

A closer look at ARM code size
Tilmann Scheller - Samsung Electronics
Slides Video
The ARM LLVM backend has been around for many years and generates high quality code which executes very efficiently. However, LLVM is also increasingly used for resource-constrained embedded systems where code size is more of an issue. Historically, very few code size optimizations have been implemented in LLVM. When optimizing for code size, GCC typically outperforms LLVM significantly.

The goal of this talk is to get a better understanding of why the GCC-generated code is more compact and also about finding out what we need to do on the LLVM side to address those code size deficiencies. As a case study we will have a detailed look at the generated code of an application running on a resource-constrained microcontroller.

Scalarization across threads
Alexander Timofeev - Luxoft
Boris Ivanovsky - Luxoft
Slides Video
Some of the modern highly parallel architectures include separate vector arithmetic units to achieve better performance on parallel algorithms. On the other hand, real world applications never operate on vector data only. In most cases whole data flow is intended to be processed by vector units. In fact, vector operations on some platforms (for instance, with massive data parallelism) may be expensive, especially for parallel memory operations. Sometimes instructions operating on vectors of identical values could be transformed into corresponding scalar form.

The goal of this presentation is to outline a technique which allows to split program data flow to separate vector and scalar parts so that they can be executed on vector and scalar arithmetic units separately.

The analysis has been implemented in the HSA compiler as an iterative solver over SSA form. The result of the analysis is a set of memory operations legitimate to be transformed into a scalar form. The subsequent transformations resulted in a small performance increase across the board, and gain up to 10% increase in a few benchmarks, one of them being HEVC decoder.

LLDB Tutorial: Adding debugger support for your target
Deepak Panickal - Codeplay
Andrzej Warzynski - Codeplay
Slides Video
This tutorial explains how to get started with adding a new architecture to LLDB. It walks through all the major steps required and how LLDB's various plugins work together in making this a maintainable and easily approachable task. It will cover: basic definition of the architecture, implementing register read/write through adding a RegisterContext, manipulating breakpoints, single-stepping, adding an ABI for stack walking, adding support for disassembly of the architecture, memory read/write through modifying Process plugins, and everything else that is needed in order to provide a usable debugging experience. The required steps will be demonstrated for a RISC architecture not yet supported in LLDB, but simple enough so that no expert knowledge of the underlying target is required. Practical debugging tips, as well as solutions to common issues, will be given.

Analyzing and Optimizing your Loops with Polly
Tobias Grosser - ETH
Johannes Doerfert - Saarland University
Zino Benaissa - Quic Inc.
Slides Video
The Polly Loop Optimizer is a framework for the analysis and optimization of (possibly imperfectly) nested loops. It provides various transformations such as loop fusion, loop distribution, loop tiling as well as outer loop vectorization. In this tutorial we introduce the audience to the Polly loop optimizer and show how Polly can be used to analyze and improve the performance of their code. We start off with basic questions such as "Did Polly understand my loops?", "What information did Polly gather?", "How does the optimized loop nest look like?", "Can I provide more information to enable better optimizations?", and "How can I utilize Polly's analysis for other purposes?". Starting from these foundations we continue with a deeper look in more advanced uses of Polly: This includes the analysis and optimization of some larger benchmarks, the programming interfaces to Polly as well as the connection between Polly and other LLVM-IR passes. At the end of this tutorial we expect the audience to not only be able to optimize their codes with Polly, but also to have a first understanding of how to use it as a framework to implement their own loop transformations.

Building, Testing and Debugging a Simple out-of-tree LLVM Pass
Serge Guelton - Quarkslab
Adrien Guinet - Quarkslab
Slides Video
This tutorial aims at providing solid ground to develop out-of-tree LLVM passes. It presents all the required building blocks, starting from scratch: cmake integration, llvm pass management, opt / clang integration. It presents the core IR concepts through two simple obfuscating passes: the SSA form, the CFG, PHI nodes, IRBuilder etc. We also take a quick tour on analysis integration through dominators. Finally, it showcases how to use cl and lit to parametrize and test the toy passes developed in the tutorial.

Note from the program committee: this was a succesful tutorial at the 2015 US LLVM dev meeting, and we thought it made sense to have it again for a EuroLLVM audience, especially when considering we are collocated with CGO and CC.

Video for all lightning talks.

Random Testing of the LLVM Code Generator
Bevin Hansson - SICS Swedish ICT
Slides
LLVM is a large, complex piece of software with many interlocking components. Testing a system of this magnitude is an arduous task. Random testing is an increasingly popular technique used to test complex systems. A successful example of this is Csmith, a tool which generates random, semantically valid C programs.

We present a generic method to generate random but structured intermediate representation code. Our method is implemented in LLVM to generate random Machine IR code for testing the post-instruction selection stages of code generation.

ARCHER: Effectively Spotting Data Races in Large OpenMP Applications
Simone Atzeni - University of Utah
Ganesh Gopalakrishnan - University of Utah
Zvonimir Rakamaric - University of Utah
Dong H. Ahn - Lawrence Livermore National Laboratory
Ignacio Laguna - Lawrence Livermore National Laboratory
Martin Schulz - Lawrence Livermore National Laboratory
Gregory L. Lee - Lawrence Livermore National Laboratory
Slides
Although the importance OpenMP as a parallel programming model and its adoption in Clang/LLVM is increasing (OpenMP 3.1 is now fully supported by Clang/LLVM 3.7), existing data-race checkers for OpenMP have high overheads and generate many false positives. In this work, we propose the first OpenMP data race checker, ARCHER, that achieves high accuracy and low overheads on large OpenMP applications. Built on top of LLVM/Clang and the ThreadSanitizer (TSan) dynamic race checker, ARCHER incorporates scalable happens-before tracking, and exploits structured parallelism via combined static and dynamic analysis, and modularly interfaces with OpenMP runtimes. ARCHER significantly outperforms TSan and Intel Inspector XE, while providing the same or better precision. It has helped detect critical data races in the Hypre library that is central to many projects at the Lawrence Livermore National Laboratory (LLNL) and elsewhere.

Note: this lightning has an associated poster

Hierarchical Graph Coloring Register Allocation in LLVM
Aaron Smith - Microsoft Research
Slides
This talk will present a new register allocator for LLVM based on a hierarchical graph coloring approach. In this allocator a program's control structure is represented as a tree of tiles and a two phase algorithm colors the tiles based on both local and global information. This talk will describe our implementation in LLVM along with an initial comparison to LLVM's existing greedy allocator.

Retargeting LLVM to an Explicit Data Graph Execution (EDGE) Architecture
Aaron Smith - Microsoft Research
Slides
This talk will describe recent work to retarget LLVM to an Explicit Data Graph Execution (EDGE) architecture. EDGE architectures utilize a hybrid von Neumann/dataflow execution model which provides out of order execution with near in-order power efficiency. We will describe the challenges with targeting an EDGE ISA with LLVM and compare our LLVM based EDGE compiler with a mature production quality Visual Studio based EDGE toolchain.

Optimal Register Allocation and Instruction Scheduling for LLVM
Roberto Castañeda Lozano - SICS & Royal Institute of Technology (KTH)
Gabriel Hjort Blindell - Royal Institute of Technology (KTH)
Mats Carlsson - SICS
Christian Schulte - SICS & Royal Institute of Technology (KTH)
Slides
This talk presents Unison - a simple, flexible and potentially optimal tool that solves register allocation and instruction scheduling simultaneously. Experiments using MediaBench and Hexagon show that Unison can speed up the code code generated by LLVM by up to 30%.

Unison is fully integrated with LLVM's code generator and hence can be used as a complement to the existing heuristic algorithms. From a LLVM developer's perspective, the ability to deliver optimal code makes Unison a powerful tool to design and evaluate heuristics. From a user's perspective, Unison allows compilation time to be traded for code quality beyond the usual -O{0,1,2,3,..} optimization levels.

Towards fully open source GPU accelerated molecular dynamics simulation
Vedran Miletić - Heidelberg Institute for Theoretical Studies
Szilárd Páll - Royal Institute of Technology (KTH)
Frauke Gräter - Heidelberg Institute for Theoretical Studies
Slides
Molecular dynamics is a simulation method for studying movements of atoms and molecules, usually applied in the study of biomolecules and materials. GROMACS open source molecular dynamics simulator supports GPU acceleration using both CUDA and OpenCL. While using CUDA is limited to NVIDIA GPUs and NVIDIA proprietary drivers, compilers and libraries, OpenCL in GROMACS targets both NVIDIA and AMD GPUs. Until this point, OpenCL in GROMACS was only tested on proprietary drivers from NVIDIA and AMD.

Advances in AMDGPU LLVM backend and radeonsi Gallium compute stack for Radeon Graphics Core Next (GCN) GPUs are steadily closing the feature gap between the open source and proprietary drivers. Recent announcement from AMD regarding the plan to support the existing open source OpenCL driver and open source their (currently proprietary) OpenCL driver makes it feasible to run GPU accelerated molecular dynamics on fully open source OpenCL stack.

Under the guidance and with help from AMD's developers working on LLVM, we are working on improving AMDGPU LLVM backend, radeonsi Gallium compute stack, and libclc to support the OpenCL features GROMACS requires to run. The lightning talk will present the challenges we encountered in the process.

CSiBE in the LLVM ecosystem
Gabor Ballabas - Department of Software Engineering, University of Szeged
Gabor Loki - Department of Software Engineering, University of Szeged
Slides
More than a decade ago, we have started to set up a code size benchmarking environment for compilers - called CSiBE - which became the official code size benchmark of GNU GCC. Since then, lots of open source and industrial compilers and testing frameworks have integrated it in their system for benchmarking and testing purpose. Nowadays CSiBE is getting increasing attention on the field of IoT again. Since the benchmark environment of CSiBE feels old and complex for the current modularized world, we have started to update its core. We are extending CSiBE with a user friendly interface, modularized testbeds, support for embedders and support for LLVM-based compilers (e.g., Clang and Rust). We will share our experiences and the possibilities about CSiBE for the community.

ARCHER: Effectively Spotting Data Races in Large OpenMP Applications
Simone Atzeni - University of Utah
Ganesh Gopalakrishnan - University of Utah
Zvonimir Rakamaric - University of Utah
Dong H. Ahn - Lawrence Livermore National Laboratory
Ignacio Laguna - Lawrence Livermore National Laboratory
Martin Schulz - Lawrence Livermore National Laboratory
Gregory L. Lee - Lawrence Livermore National Laboratory
Although the importance OpenMP as a parallel programming model and its adoption in Clang/LLVM is increasing (OpenMP 3.1 is now fully supported by Clang/LLVM 3.7), existing data-race checkers for OpenMP have high overheads and generate many false positives. In this work, we propose the first OpenMP data race checker, ARCHER, that achieves high accuracy and low overheads on large OpenMP applications. Built on top of LLVM/Clang and the ThreadSanitizer (TSan) dynamic race checker, ARCHER incorporates scalable happens-before tracking, and exploits structured parallelism via combined static and dynamic analysis, and modularly interfaces with OpenMP runtimes. ARCHER significantly outperforms TSan and Intel Inspector XE, while providing the same or better precision. It has helped detect critical data races in the Hypre library that is central to many projects at the Lawrence Livermore National Laboratory (LLNL) and elsewhere.

Note: this poster has an associated lightning talk

Design-space exploration of LLVM pass order with simulated annealing
Nicholas Timmons - Cambridge University
David Chisnall - Cambridge University
We undertook an automated design space exploration of the optimisation pass order and inliner thresholds in Clang using simulated annealing. It was performed separately on multiple input programs so that the results could be validated against each other. Superior configurations to the preset optimisation levels were found, such as those which produce similar run times to the presets whilst reducing build times, and those which offer improved run-time performance than the '-O3' optimisation level. Contrary to our expectation, we also found that the preset optimisation levels did not provide a uniform distribution in the tradeoff space between run and build-time performance.

ConSerner: Compiler Driven Context Switches between Accelerators and CPUs
Ramy Gad - Johannes Gutenberg University
Tim Suess - University of Mainz
Andre Brinkmann - Johannes Gutenberg-Universität Mainz
Computer systems provide different heterogeneous resources (e.g., GPUs, DSPs and FPGAs) that accelerate applications and that can reduce the energy consumption by using them. Usually, these resources have an isolated memory and a require target specific code to be written. There exist tools that can automatically generate target specific codes for program parts, so-called kernels. The data objects required for a target kernel execution need to be moved to the target resource memory. It is the programmers' responsibility to serialize these data objects used in the kernel and to copy them to or from the resource's memory. Typically, the programmer writes his own serializing function or uses existing serialization libraries. Unfortunately, both approaches require code modifications, and the programmer needs knowledge of the used data structure format. There is a need for a tool that is able to automatically extract the original kernel data objects, serialize them, and migrate them to a target resource without requiring intervention from the programmer.

In this work, we present a tool collection ConSerner that automatically identifies, gathers, and serializes the context of a kernel and migrates it to a target resource's memory where a target specific kernel is executed with this data. This is all done transparently to the programmer. Complex data structures can be used without making a modification of the program code by a programmer necessary. Predefined data structures in external libraries (e.g., the STL's vector) can also be used as long as the source code of these libraries is available.

Evaluation of State-of-the-art Static Checkers for Detecting Objective-C Bugs in iOS Applications
Thai San Phan - University of New South Wales
Yulei Sui - University of New South Wales
The pervasive usage of mobile phone applications is now changing the way people use traditional software. Smartphone apps generated an impressive USD 35 billion in full-year 2014, and in total 138 billion apps were downloaded in the year. The last few years have seen an unprecedented number of people rushing to develop mobile apps. Apple iOS has always played a major role in the smart-devices industry ever since the evolution of it. On average, around 45,000 newly developed apps are submitted for release to the iTunes App Store in 2014. Similar as desktop software, any mobile applications are prone to bugs and it is difficult to completely make them bug-free. As a fundamental tool to help programmers effectively locate program defects during compile time, static analysis approximates the runtime behaviour of a program without actually executing it. It is extremely helpful to catch bugs earlier during software development cycle before the produced is shipped in order to avoid high maintenance cost. This poster is hence to evaluate the state-of-the-art static checkers for detecting Objective-C bugs to systematically investigate the advantages and disadvantages of using different checkers on a wide variety bug patterns in iOS applications.

Objective-C, as the primary language for iOS application, is an object-oriented superset of C such that it inherits syntax, primitive types and flow control statements of C. Though it has many new features that distinguish it from C such as message passing (equivalent to C or Java's method calling), interface and implementation for objects (equivalent to "class" in C++), garbage collector or now ARC (C does not have this feature), and most importantly, it is a runtime-driven language where decisions such as memory allocations, object creation, reflection API are decided at runtime as oppose to be determined during compilation. All these features significantly complicated scalable and precise static analysis.

Stack Size Estimation on Machine-Independent Intermediate Code for OpenCL Kernels
Stefano Cherubin - Politecnico di Milano
Michele Scandale - Politecnico di Milano
Giovanni Agosta - Politecnico di Milano
Stack size is an important factor in the mapping decision when dealing with embedded heterogeneous architectures, where fast memory is a scarce resource. Trying to map a kernel onto a device with insufficient memory may lead to reduced performance or even failure to run the kernel. OpenCL kernels are often compiled just-in-time, starting from the source code or an intermediate machine-independent representation. Precise stack size information, however, is only available in machine-dependent code. We provide a method for computing the stack size with sufficient accuracy on machine-independent code, given knowledge of the target ABI and register file architecture. This method can be applied to make mapping decisions early, thus avoiding to compile multiple times the code for each possible accelerator in a complex embedded heterogeneous system.

AAP: The Compiler Writer's Architecture from hell
Simon Cook - Embecosm
Edward Jones - Embecosm
Jeremy Bennett - Embecosm
Contending with the blistering pace of LLVM advancement is a challenge for out of tree targets. Many out of tree targets, often for widely used embedded processors, have hardware features which are not well represented by the mainstream LLVM project.

We introduced An Altruistic Processor (AAP) at EuroLLVM 2015. AAP's architecture encapsulates as many of these features as possible. AAP is a RISC, Harvard architecture with up to 64kB of byte addressed data, up to 16MW of word addressed code, and a configurable register bank of between 4 and 64 registers.

In this poster we will present an update on the AAP architecture. We'll look at some of the most challenging features, and how we have extended LLVM to support them. This includes :

• different sizes of code and address pointers,
• how to handle code pointers that do not fit in the default address space,
• operations where stack access is cheaper than register access,
• how to relax call/return when you have multiple return address sizes.

Automatic Identification of Accelerators for Hybrid HW-SW Execution
Georgios Zacharopoulos - University of Lugano
Giovanni Ansaloni - University of Lugano
Laura Pozzi - University of Lugano
While the number of transistors that can be put on a chip significantly increases, as suggested by Moore's law, the dark silicon problem rises. This is due to the power consumption not dropping at a corresponding rate, which generates overheating issues. Accelerator-enhanced architectures can provide an efficient solution to this and lead us to a hybrid HW-SW execution, where computationally intensive parts can be performed by custom hardware. An automation of this process is needed, so that applications in high-level languages can be mapped to hardware and software directly. The process needs, first, an automatic technique for identifying the parts of the computation that should be accelerated, and secondly, an automated way of synthesising these parts onto hardware. Under the scope of this paper, we are focusing on the first part of this process, and we present the automatic identification of the most computationally demanding parts, also known as custom instructions. The state-of-the-art identification approaches have certain limitations, as custom instruction selection is mostly performed within the scope of single Basic Blocks. We introduce a novel selection strategy, implemented within the LLVM framework, that carries out identification beyond the scope of a single Basic Block and identifies Regions within the Control Flow Graph, as subgraphs of it. Specific I/O constraints and area occupation metrics are taken into consideration, in order to obtain Regions that would provide maximum speedup, under architectural constraints, when transferred to hardware. For our final experimentation and evaluation phase, kernels from the signal and image processing domain are evaluated, and promising initial results show that the identification technique proposed is often capable of mimicking manual designer decisions.

Static Analysis for Automated Partitioning of Single-GPU Kernels
Alexander Matz - Ruprecht-Karls University of Heidelberg
Christoph Klein - Ruprecht-Karls University of Heidelberg
Holger Fröning - Ruprecht-Karls University of Heidelberg
GPUs have established themselves in the computing landscape, convincing users and designers by their excellent performance and energy efficiency. They differ in many aspects from general-purpose CPUs, for instance their highly parallel architecture, their thread-collective bulk-synchronous execution model, and their programming model. Their use has been pushed by the introduction of data-parallel languages like CUDA or OpenCL.

The inherent domain decomposition principle for these languages ensures a fine granularity when partitioning the code, typically resulting in a mapping of one single output element to one thread and reducing the need for work agglomeration.

The BSP programming paradigm and its associated slackness regarding the ratio of virtual to physical processors allows effective latency hiding techniques that make large caching structures obsolete. At the same time, a typical BSP code exhibits substantial amounts of locality, as the rather flat memory hierarchy of thread-parallel processors has to rely on large amounts of data reuse to keep their vast amount of processing units busy.

While these languages are rather easy to learn and use for single GPUs, programming multiple GPUs has to be done in an explicit and manual fashion that dramatically increases the complexity. The user has to manually orchestrate data movements and kernel launches on the different processors. Even though there exist concepts that span up global addresses like shared-virtual memory, the significant bandwidth disparity between on-device (GDDR) and off-device (PCIe) accesses usually results in no performance gains.

We leverage these observations for deriving a methodology to scale out single-device programs to an execution on multiple devices, aggregating compute and memory resources. Our approach comprises three steps: 1. collect information about data dependency and memory access patterns using static code analysis 2. merge information in order to choose an appropriate partitioning strategy 3. apply code transformations to implement the chosen partitioning and insert calls to a dynamic runtime library.

LLVM Foundation
LLVM Foundation board of directors
BoF notes
This BoF will give the EuroLLVM attendees a chance to talk with some of the board members of the LLVM Foundation. We will discuss the Code of Conduct and Apache2 license proposal and answer any questions about the LLVM Foundation.

Compilers in Education
Roel Jordans - Eindhoven University of Technology
Henk Corporaal - Eindhoven University of Technology
BoF notes
While computer architecture and hardware optimization is generally well covered in education, compilers are still often a poorly represented subject. Classical compiler lecture series seem to mostly cover the front-end parts of the compiler but usually lack an in-depth discussion of newer optimization and code generation techniques. Important aspects such as auto-vectorization, complex instruction support for DSP architectures, and instruction scheduling for highly parallel for VLIW architectures are often touched only lightly. However, creating new processor designs requires a properly optimizing compiler in order for it to be usable by your customers. As such, there is a good market for well-trained compiler engineers which does not match with the classical style of teaching compilers in education.

At Eindhoven University of Technology, we are currently starting a new compiler course that should provide such an improved lecture series to our students and we plan to make this available to the wider community. The focus of this lecture series is on tool-flow organization of modern parallelizing compilers, their internal techniques, and the advantages and limitations of these techniques. We try to train the students so that they can understand how the compiler works internally, but also apply this new knowledge in writing C program code that allows the compiler to utilize its advanced optimizations to generate better and portable code. As a result, we hope to provide better qualified compiler engineers, but also train them to write better high-performance code at a high-level by applying their compiler knowledge in guiding the compiler to an efficient implementation of the program.

As part this process we would like to get in contact with institutes and companies that will be taking advantage of our newly educated students and discuss with them the contents of our lecture series. What do you guys think are important topics that new engineers should know about to be useful in your organization and what would make this course interesting for yourself?

Surviving Downstream
Paul Robinson - Sony Computer Entertainment America
BoF notes
We presented "Living Downstream Without Drowning" as a tutorial/BOF session at the US LLVM meeting in October. After the session, Paul had people coming to talk to him for most of the evening social event and half of the next day (and so missed several other talks!). Clearly a lot of people are in this situation and there are many good ideas to share.

Come to this follow-up BOF and share your practices, problems and solutions for surviving the "flood" of changes from the upstream LLVM projects.

Polly - Loop Optimization Infrastructure
Tobias Grosser - ETH
Johannes Doerfert - Saarland University
Zino Benaissa - Quic Inc.
BoF notes
The Polly Loop Optimization infrastructure has seen active development throughout 2015 with contributions from a larger group of developers located at various places around the globe. With three successful Polly sessions at the US developers meeting and larger interest at the recent HiPEAC conference in Prag, we expect various Polly developers to be able to attend EuroLLVM. To facilitate in-persona collaboration between the core developers and to reach out to the wider loop optimization community, we propose a BoF session on Polly and the LLVM loop optimization infrastructure. Current hot topics are the usability of Polly in an '-O3' compiler pass sequence, profile driven optimizations as well as the definition of future development milestones. The Polly developers community will present ideas on these topics, but very much invites input from interested attendees.

LLVM on PowerPC and SystemZ
Ulrich Weigand - IBM
BoF notes
This Birds of a Feather session is intended to bring together developers and users interested in LLVM on the two IBM platforms PowerPC and SystemZ.

Topics for discussion include:

• Status of platform support in the two LLVM back ends: feature completeness, architecture support, performance, ...
• Platform support in other parts of the overall LLVM portfolio: LLD, LLDB, sanitizers, ...
• Support for new languages and other emerging use cases: Swift, Rust, Impala, ...
• Any other features currently in development for the platform(s)
• User experiences on the platform(s), additional requirements

How to make LLVM more friendly to out-of-tree consumers ?
David Chisnall - Computer Laboratory, University of Cambridge
BoF notes
LLVM has always had the goal of a library-oriented design. This implicitly assumes that the libraries that are parts of LLVM can be used by consumers that are not part of the LLVM umbrella. In this BoF, we will discuss how well LLVM has achieved this objective and what it could do better. Do you use LLVM in an external project? Do you track trunk, or move between releases? What has worked well for you, what has caused problems? Come along and share your experiences.