Back To Schedule
Thursday, November 3 • 4:15pm - 5:00pm
Lightning Talks

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

1) MemorySSA in Five Minutes - George Burgess Iv
Abstract: MemorySSA is a utility that has recently been landed in LLVM. This talk will give a high-level introduction to what MemorySSA is and how we expect to use it 

2) Polly as an analysis pass in LLVM - Utpal Bora
In this talk, we will introduce a new interface to use polyhedral dependence analysis of Polly in LLVM transformation passes such as Loop Vectorizer. As part of GSoC 2016, we implemented an interface to Polly, and provided new APIs that can be used as an Analysis pass within LLVM's transformation passes. We will describe our implementation and demonstrate some loop transformations using the new interface (PolyhedralInfo). Details on GSoC- http://utpalbora.com/gsoc/2016.html

3) RISC-V: Towards a reference LLVM backend Alex Bradbury
This talk will present work towards establishing RISC-V as a reference quality backend in LLVM. By maintaining a regularly updated patchset that implements a production quality backend alongside a companion tutorial, we can make LLVM development accessible to a much wider audience. We will explore the work that has been done to reach these goals, problems faced, and how you can contribute. 

4) Error -- Structured Error Handling in LLVM Lang Hames
LLVM’s new Error scheme enables rich error handling and recovery by supporting user-defined error types and strict requirements on error checking. This talk provides an overview of how the scheme works, and how it can be used in your code.

5) Reducing the Computational Complexity of RegionInfo - Nandini Singhal
The LLVM RegionInfo pass provides a convenient abstraction to reason about independent single-entry-single-exit regions of the control flow graph. RegionInfo has proven useful in the context of Polly and the AMD GPU backend, but the quadratic complexity of RegionInfo construction due to the use of DominanceFrontier makes the use of control flow regions costly and consequently prevents the use of this convenient abstraction. In this work, we present a new approach for RegionInfo construction that replaces the use of DominanceFrontier with a clever combination of LoopInfo, DominanceInfo, and PostDominanceInfo. As these three analysis are (or will soon be) preserved by LLVM and consequently come at zero cost while the quadratic cost of DominanceFrontier construction is avoided, the overall cost of using RegionInfo has been largely reduced, which makes it practical in a lot more cases. Several other problems in the context of RegionInfo still need to be addressed. These include how to remove the RegionPass framework which makes little sense in the new pass manager, how to connect Regions and Loops better, and how we can move from a built-upfront-everything analysis to an on-demand analysis, which step-by-step builds only the needed regions. We hope to discuss some of these topics with the relevant people of the LLVM community as part of the poster session.

6) Toward Fixed-point Optimization in LLVM Nathan Wilson
As one might imagine, LLVM’s optimization pipeline is not universally optimal. Running the available optimization passes in a different order, and changing the number of times each runs, can improve performance on some programs. Anecdotal evidence has suggested that simply running the current optimization pipeline multiple times often yields better-performing programs. Given compile-time constraints, simply duplicating the current pipeline for all inputs would be unacceptable for many users. How many times is enough? What if we could be smarter about it to get the performance benefits without the compile-time cost? To answer this question, we implemented a fixed-point optimization scheme in LLVM and evaluated its use when compiling LLVM’s test suite. Under this scheme, the function-pass pipeline would continue to execute while the input IR differed from the final IR. This experiment revealed that we will be able to capture the performance benefits of repeating the pipeline at reduced cost, and that four times is enough.

7) FileCheck Follies Paul Robinson
FileCheck is *the* critical tool for LLVM testing.  See how to make it NOT do what you want! Watch it silently pass a bogus test! All examples REAL and "ripped from the headlines" of the commits list! 

avatar for Alex Bradbury

Alex Bradbury

Co-founder and Director, lowRISC CIC

Lang Hames

Apple Inc.

Paul Robinson

Staff Compiler Engineer, Sony Computer Entertainment America

Thursday November 3, 2016 4:15pm - 5:00pm PDT
1 - General Session (Rm LL20ABC)