[llvm-commits] [www] r143844 - /www/trunk/devmtg/2011-11/index.html

Tanya Lattner tonic at nondot.org
Sat Nov 5 17:21:09 PDT 2011 

Author: tbrethou
Date: Sat Nov  5 19:21:09 2011
New Revision: 143844

URL: http://llvm.org/viewvc/llvm-project?rev=143844&view=rev
Log:
Clean up descriptions.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143844&r1=143843&r2=143844&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:21:09 2011
@@ -129,60 +129,71 @@
 <b>Integrating LLVM into FreeBSD</b><br>
 <i>Brooks Davis -  The FreeBSD Project</i><br>
 The FreeBSD Project has been actively working to incorporate tools from the LLVM project into our base system including clang, libc++, and possibly lldb.  This talk will cover our efforts so far including our plans to ship FreeBSD 9.0 with clang in the base system.  I will cover both our current work to replace GPL licensed components with BSD(ish) licensed components and future or experimental work to incorporate new technologies made possible by LLVM.
-<br>
+</p>
 
+<p>
 <b>Clang MapReduce -- Automatic C++ Refactoring at Google Scale</b><br>
 <i>Chandler Carruth -  Google</i><br>
 Google has over 100 million lines of code, and our biggest programming language is C++. We have a single, shared codebase developed primarily on mainline. We build every binary and all of its libraries from scratch every time, allowing us to incrementally evolve APIs and libraries over time. The entire development process is extremely incremental in nature, and even API-breaking changes are a regular occurrence. However, for core libraries used throughout the codebase, this development model is a huge challenge: how do we incrementally evolve an API in use by tens of thousands of other libraries? The answer is to use Clang to automatically refactor APIs and their users across the codebase. How do we scale Clang up to possibly the single largest unified codebase in the world? The same way Google scales anything else: MapReduce. By coupling Clang’s library design and architecture to existing Google infrastructure we can automatically compile, analyze, and refactor the ent
 ire Google codebase in minutes. In this talk, I will dive into the challenges of refactoring C++ code, how we’re using Clang and making it even better at solving them, and how we scale these solutions to the size of our codebase.
-<br>
+</p>
 
+<p>
 <b>Thread Safety Annotations in Clang</b><br>
 <i>DeLesley Hutchins -  Google</i><br>
 This talk introduces the new thread safety annotations for Clang and describes the static analysis used to check them. These annotations can be used to specify properties such as whether a variable is guarded by a particular mutex, or a desired lock acquisition order.  These annotations were originally introduced in gcc, and have recently been reimplemented in Clang.
-<br>
- 
+</p>
+
+<p> 
 <b>Extending Clang</b><br>
 <i>Doug Gregor -  Apple</i><br>
 You have an idea for the next great C(++) language feature, but how do you realize that idea? This talk will describe how to extend Clang to add new language features, from parsing and AST-construction basics to properly handling C++ templates and ensuring smooth integration into IDEs. Particular attention will be given to capturing source information in ASTs, developing bulletproof semantic analysis, and write proper regression tests to exercise the various aspects of a language feature.
-<br>
+</p>
 
+<p>
 <b>Super-optimizing LLVM IR</b><br>
 <i>Duncan Sands -  DeepBlueCapital / CNRS</i><br>
 I will describe a tool to harvest expression sequences from LLVM IR and automatically discover equivalent simplified expressions. The original version of this tool only looked for sub-expressions that were equivalent to the whole, but nonetheless discovered many simplifications missed by the LLVM optimizers (most of these have now been implemented in LLVM). The tool has since been extended to a general super optimizer by Rafael Auler.
-<br>
+</p>
 
+<p>
 <b>Register Allocation in LLVM 3.0</b><br>
 <i>Jakob Olesen -  Apple</i><br>
 An overview of the features in LLVM's new register allocator
-<br>
+</p>
 
+<p>
 <b>SKIR: Just-in-Time Compilation for Parallelism with LLVM</b><br>
 <i>Jeff Fifield -  University of Colorado</i><br>
 The Stream and Kernel Intermediate Representation (SKIR) is a small set of LLVM intrinsics for expressing parallel computation as a graph of sequential processes (kernels) communicating over abstract data channels (streams). At runtime, programs use the SKIR intrinsics to identify functions to use as kernels, to connect kernels together using streams, and to execute resulting program graphs. Formally, the stream parallelism expressed by SKIR programs can be viewed as a generalization of Kahn process networks. More practically, we can use SKIR as a compilation target for high level languages and frameworks containing this style of program decomposition and communication. We have used SKIR to implement a compiler for the StreamIt language, to create a C++ user library for stream/data/pipeline parallel programming, and to enable parallel programming for JavaScript applications. SKIR is implemented on top of the LLVM JIT compiler and a work stealing task scheduler. We use runtim
 e compilation because of the runtime construction of program graphs, so that we can support dynamic optimization, and so that we can perform dynamic recompilation for heterogeneous targets. In this talk I will describe the SKIR intrinsics and programming model, and briefly describe high level language support that has been implemented for SKIR. I will present the compilation and optimization techniques used to transform the sequential LLVM+SKIR input code into concurrent code which can be executed in parallel using dynamic scheduling techniques. I will also describe how we can use LLVM JIT compilation to dynamically increase or decrease the amount of parallelism in a SKIR program depending on runtime hardware and application characteristics. Finally, I will describe how we can further accelerate SKIR program kernels using JIT compilation, our OpenCL backend, and GPUs.
-<br>
- 
+</p>
+
+<p> 
 <b>LLVM MC In Practice</b><br>
 <i>Jim Grosbach, Owen Anderson -  Apple Inc.</i><br>
 Overview of projects and new developments in the LLVM MC layer, with emphasis on the MCJIT, binary analysis, ARM integrated assembler and ARM disassembler.
-<br>
+</p>
  
+<p>
 <b>Exporting 3D scenes from Maya to WebGL using clang and LLVM</b><br>
 <i>Jochen Wilhelmy -  Engineering consultant Wilhelmy</i><br>
 Modern content creation tools such as Autodesk Maya can be seen as graphical programming language. Features like animation of attributes, embedded scripts, shading networks and vertex deformations can be translated to c++, then compiled to LLVM IR and distributed to CPU and GPU. An award winning WebGL demo is shown which was produced using this approach.
-<br> 
+</p> 
 
+<p>
 <b>DXR: Semantic Code Browsing with Clang</b><br>
 <i>Joshua  Cranmer  - Mozilla</i><br>
 DXR is a source code browser which uses a clang plugin to determine information about all types, variables, and functions in a program to make reading, searching, and understanding source code easier.
-<br>
- 
+</p>
+
+<p> 
 <b>PTX Back-End: GPU Programming With LLVM</b><br>
 <i>Justin Holewinski -  Ohio State University</i><br>
 In this talk, the PTX back-end for LLVM will be discussed, including its' past, present, and future. The current status of the back-end will be explored, with an emphasis on the portions of the LLVM IR instruction set and PTX intrinsics that are currently supported during code generation. This talk will also highlight the difficulties and issues that have been discovered while writing an LLVM back-end for a virtual ISA such as PTX, such as infinite register files. Through-out the talk, examples will be provided to highlight key features of the back-end and show preliminary performance data.
 <br>
 In addition to back-end details, this talk will also highlight the use of Clang as a front-end for generating PTX code for NVIDIA GPUs. Through the use of Clang  and the CUDA Driver API, GPGPU programs can be developed that harness the optimization power of the LLVM compiler infrastructure. Finally, the talk will conclude with an exploration of the open issues that remain in the backend, and a discussion on how the back-end can be used within larger GPGPU compiler projects.
-<br>
+</p>
 
+<p>
 <b>Finding races and memory errors with LLVM instrumentation</b><br>
 <i>Konstantin Serebryany -  Google</i><br>
 We will present two dynamic testing tools based on compile-time instrumentation, both tools use the LLVM compiler.
@@ -191,17 +202,21 @@
 <ul<li>ThreadSanitizer (TSan) finds data races. It uses the same race detection algorithm as the Valgrind-based TSan, but compile-time instrumentation allows it to be much faster (2x-4x slowdown).
 </li></ul>
 We will also share our experience in deploying theses testing tools in large software projects.
+</p>
 
+<p>
 <b>Intel OpenCL SDK Vectorizer</b><br>
 <i>Nadav Rotem -  Intel</i>
 In this talk, we will present our OpenCL SDK and its core technology – the vectorizer compiler. We plan to present an overview of our vectorizer and discuss our experience with the LLVM compiler toolkit over the last few years. We will discuss some of our design decisions and our and plans for future features (future instruction sets, vector select, predicated instructions, etc).
-<br>
+</p>
 
+<p>
 <b>Using clang in the Chromium project</b><br>
 <i>Nico Weber, Hans Wennborg -  Google</i><br>
 The Chromium project is the open-source foundation on which the Google Chrome web browser is built. It is a multi-million line codebase that uses open source libraries such as WebKit, libpng, skia, ffmpeg, and leveldb. We have been able to build Chromium using clang since October 2010, and since then we've continuously expanded what we use clang for: as continuous build compiler to catch bugs with clang's superior diagnostics, with project-specific clang plugins that enforce coding-style guidelines or find domain-specific bugs in V8, and starting with Chrome 15 as production compiler on Mac OS X. We will share our experiences using clang in a mature open-source project and cover, e.g., how clang's fabled compilation speed fares in a distributed build system with 100 parallel jobs, which parts of a browser blow up when the default compiler is changed, and which of clang's warnings catch the most bugs in practice.
-<br>
+</p>
 
+<p>
 <b>Android Renderscript</b><br>
 <i>Stephen Hines -  Google</i><br>
 Renderscript is Android's advanced 3D graphics rendering and compute API. It provides a portable C99-based language with extensions to facilitate common use cases for enhancing graphics and thread level parallelism. The Renderscript compiler frontend is based on Clang/LLVM. It emits a portable bitcode format for the actual compiled script code, as well as reflects a Java interface for developers to control the execution of the compiled bitcode. Executable machine code is then generated from this bitcode by an LLVM backend on the device. Renderscript is thus able to provide a mechanism by which Android developers can improve performance of their applications while retaining portability.
@@ -211,15 +226,18 @@
 Interesting facts:
 <ul>
 <li>Difference in Clang source: 6 lines (all upstreamable with a bit of configuration logic)</li>
-<li>Difference in LLVM source: ~300 lines (possibly worth upstreaming, but some fixes for legacy JIT mode are no longer relevant to TOT)
-<li>The frontend compiler is layered completely on top of Clang, so everything we use is sub-classed and/or recombined for our purposes in the llvm-rs-cc compiler driver.
-<li>The backend compiler is stripped down to fit on a tablet/smartphone stack.
+<li>Difference in LLVM source: ~300 lines (possibly worth upstreaming, but some fixes for legacy JIT mode are no longer relevant to TOT)</li>
+<li>The frontend compiler is layered completely on top of Clang, so everything we use is sub-classed and/or recombined for our purposes in the llvm-rs-cc compiler driver.</li>
+<li>The backend compiler is stripped down to fit on a tablet/smartphone stack.</li>
+</ul></p>
 
+<p>
 <b>Porting LLVM to a Next Generation DSP</b><br>
 <i>Taylor Simpson -  Qualcomm Innovation Center</i><br>
 This talk will describe our experiences in porting LLVM to Qualcomm's latest generation DSP, Hexagon.  The overall experience of porting to a new architecture will be discussed. The challenges of achieving high quality code generation for a VLIW with LLVM with also be outlined.
-<br>
+</p>
 
+<p>
 <b>Polly - First successful optimizations - How to proceed?</b><br>
 <i>Tobias Grosser -  ENS/INRIA</i><br>
 Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es

More information about the llvm-commits mailing list