2012 LLVM Developers' Meeting

Table of Contents

About

Sponsored by Apple, QuIC, Google, Intel

The meeting served 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:

We also invite you to sign up for the official Developer Meeting mailing list to be kept informed of updates concerning the meeting.

Proceedings

Presentations

Lightning Talks

Project Dependency Impact on Clang’s Build Time

Javier Martinez [Slides] [Video]

Clang and LLVM for Automated Defense (and Great Justice)

John Criswell [Slides] [Video]

A Prototype for Fast Type-Aware Memory Profiling

Nico Weber [Slides] [Video]

Statically Checking MPI Type Safety

Dmitri Gribenko [Slides] [Video]

Annotations for Safe Parallelism

Alexandros Tzannes [Slides] [Video]

SoSlang

Ronan Keryell [Slides] [Video]

Bitcode compatibility

Joe Abbey [Slides] [Video]

Evaluating LLVM for Texas Instruments DSPs

Jonathan Humphreys [Slides] [Video]

BOFs

BOF: Polly: A Loop Nest Optimizer for LLVM

Zino Benaissa (QuIC)

BOF: SelectionDAG & DAGCombiner - how can they be improved?

James Molloy (ARM)

BOF: Instruction scheduling for Superscalar and VLIW platforms. Temporal perspective

Sergei Larin (QuIC), Andy Trick (Apple) [Slides]

BOF: SPIR - A Standard Portable IR for OpenCL Kernel Language

Boaz Ouriel (Intel)

BOF: Memory Safety, Debugging Tools, and Automated Defenses

Santosh Nagarakatte (Rutgers University), John Criswell (University of Illinois)

BOF: Vectorization in LLVM

Nadav Rotem (Apple) [Slides]

Posters

Poster: MemorySanitizer, ThreadSanitizer

Kostya Serebryany (Google) [Slides]
Following the success of AddressSanitizer (asan), a fast detector of use-after-free and buffer overflow bugs, we have developed two more bug detection tools based on similar ideas. MemorySanitizer (msan, http://code.google.com/p/memory-sanitizer/) detects uninitialized memory reads. It shares many ideas with Valgrind/Memcheck, however it is also different in two important ways: it uses compile-time instrumentation (LLVM) and 1:1 direct shadow memory mapping. Unless the entire program (including libc) is instrumented, msan requires a simple binary instrumentation component (we have an implementation based on DynamoRIO). The slowdown introduced by the tool is typically 2x-3x (compare to Valgrind's 20x). ThreadSanitizer (tsan, http://code.google.com/p/thread-sanitizer/) detects data races. The tool has been briefly mentioned at the 2011 llvm dev meeting but has matured since that time. Similarly to asan and msan, it uses compile-time instrumentation (LLVM), but 95% of the logic is contained in the run-time library. Tsan uses 1:4 direct shadow memory mapping (i.e. uses ~5x more memory). It does not have locks or atomic instructions on the fast path, which makes it scale to large and heavily threaded applications. The slowdown varies between 3x and 10x.

Poster: Vuo: Visual programming for multimedia artists

Jaymie Strecker (Kosada) [Slides]
Vuo is a new programming environment for multimedia artists. We’re building Vuo’s compiler and linker on top of LLVM. We chose LLVM because LLVM makes it easy to add features that multimedia artists enjoy — features that would have taken months or years to write from scratch. Why do multimedia artists need a programming environment? Because very often their job is to create software: interactive art and music, animations, visualizations, games, special effects, museum exhibits, and kiosks. Yet their background is in art or music, not programming. Many multimedia artists get around this by using programming environments where, instead of typing a program, they drag-and-drop building blocks onto a canvas and draw lines to connect them. These “node-based” or “visual” programming environments include Max, VVVV, Quartz Composer — and, soon, Vuo. LLVM is helping Vuo become more powerful and flexible. Vuo programs are compiled and therefore faster than interpreted programs — thanks to LLVM’s APIs for code generation and optimization. Vuo programs will be able to target Mac, Windows, Linux, iOS, and Android — thanks to LLVM’s support for various targets. Vuo developers will be able to write new building blocks in C and, eventually, other languages (e.g. C#, Python, JavaScript, PHP, Lua) — thanks to LLVM’s many frontends and Mono’s LLVM backend. LLVM solves problems of parsing and code generation so we don’t have to. Instead, we can focus on adding features that multimedia artists appreciate, like live coding (the ability to edit a program while it’s running) and easy debugging. LLVM is helping Vuo become flexible, feature-rich, and fun.

Poster: Scout: Using Clang/LLVM to Build A Domain-Specific Language for In Situ Data Analysis and Visualization on Emerging Architectures

Christine Ahrens (Los Alamos National Laboratory) [Slides]
As supercomputing architectures change rapidly and larger amounts of data must be processed, it is difficult to create an efficient and versatile workflow for scientific simulations at scale. These large-scale scientific applications require computation, data analysis and visualization. Our approach is to explore building a programming language that can provide appropriate programming abstractions, a development toolchain and runtime layers that support existing scientific applications on emerging architectures without having to significantly rewrite or refactor their code. Towards this goal, we have developed Scout, a domain-specific language that provides conservative extensions to C/C++ via the LLVM/Clang compiler. The poster will provide example Scout programs, a high-level system diagram, visualization support details and architecture support details. It will also contain a discussion of our experiences using LLVM/Clang, Scout design considerations and future goals.