Topics Include: Clang Tools, Clang (CodeGen, Sema, ..), Static Analyzer, Exception Handling, ORC, MCJIT, Windows Support
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!
1) Stack-use-after-scope detector in AddressSanitizer - Vitaly Buka
Stack-use-after-scope is the check in AddressSanitizer which detects access to variables from outside the scope it was declared. This talk covers issues we had to resolve to make the feature usable, results of applying the check to the Google code, and examples of bugs it detected.
2) How compiler frontend is different from what IDE needs? - Ilya Biryukov
We’ve been writing our own C++ frontends at JetBrains for a few years now. Given that most people use clang these days, this may come as a surprise that we don’t. In this small talk we’ll cover the reasons that were driving our decision to roll out our own implementation and try to highlight how it’s different from what’s being done in clang.
3) Enabling Polyhedral Optimizations in Julia - Matthias Reisinger
Julia is a relatively young programming language with a focus on technical computing. While being dynamic it is designed to achieve high performance comparable to that of statically compiled languages. The execution of Julia programs is driven by a just-in-time compiler that relies on LLVM to produce efficient code at run-time. This talk highlights the recent integration of Polly into this environment which has enabled the use of polyhedral optimization in Julia programs.
4) Extending Clang AST Matchers to Preprocessor Constructs - Jeff Trull
Clang's libTooling provides powerful mechanisms for identifying and modifying source code via the AST. However, parts of the source code are hidden or obfuscated from these tools due to the action of the preprocessor. This is particularly true of legacy code, where applying refactoring tools is highly desirable. The speaker will demonstrate how to write an AST Matcher that identifies sections of code associated with preprocessor conditional directives, and will make suggestions on how to improve tooling in this area.
5) SMACK Software Verification Toolchain - Zvonimir Rakamaric
Tool prototyping is an essential step in developing novel software verification algorithms and techniques. However, implementing a verifier prototype that can handle real-world programs is a large endeavor. In this talk, we present the SMACK software verification toolchain. SMACK provides a modular and extensible software verification ecosystem that decouples the front-end source language details from back-end verification algorithms. It achieves that by translating from the LLVM compiler intermediate representation into the Boogie intermediate verification language. SMACK offers the following benefits: (1) it can be used as an automated off-the-shelf software verifier in an applied software verification project, (2) it enables researchers to rapidly develop and release new verification algorithms, and (3) it allows for adding support for new languages in its front-end. We have used SMACK to verify numerous C/C++ programs, including industry examples, showing it is mature and competitive. Likewise, SMACK is already being used in several existing verification projects.
6) Finding code clones in the AST with clang - Raphael Isemann
This talk will introduce clang’s new clone detection framework that uses hash-code comparison to search for groups of AST nodes that are similar in a certain configurable sense.
The current concept of poison in LLVM is known to be broken, leaving LLVM in a state where certain miscompilation bugs are hard or even impossible to fix. Moreover, the concepts of poison and undef values in LLVM are hard to reason about and are often misunderstood by developers.
However, we need concepts similar to poison and undef to enable certain important optimizations.
In this talk, we will present the motivation behind poison and undef and why they are broken. We'll also present a proposal to kill undef and extend poison, while retaining their performance benefits.
This talk is meant to increase awareness of the issues and motivations behind poison/undef and discuss how to fix it.
Joint work with: Sanjoy Das, Gil Hur, Yoonseung Kim, Juneyoung Lee, David Majnemer, John Regehr, and Youngju Song.
CFL-based context sensitive alias analysis in LLVM - Jia Chen
This poster presents CFL-Steens-AA and CFL-Anders-AA.
Enabling Polyhedral Optimizations in Julia - Matthias Reisinger
Julia is a relatively young programming language with a focus on technical computing. While being dynamic it is designed to achieve high performance comparable to that of statically compiled languages. The execution of Julia programs is driven by a just-in-time compiler that relies on LLVM to produce efficient code at run-time. This poster highlights the recent integration of Polly into this environment which has enabled the use of polyhedral optimization in Julia programs.
Towards a generic accelerator offloading approach: implementing OpenMP 4.5 offloading constructs in Clang and LLVM - Gheorghe-Teodor Bercea
The OpenMP 4.5 programming model enables users to run on multiple types of accelerators from a single application source code. Our goal is to integrate a high-performance implementation of OpenMP’s programming model for accelerators in the Clang/LLVM project. This poster is a snapshot of our ongoing efforts towards fully supporting the generation of code for OpenMP device offloading constructs. We have submitted several Clang patches that address some of the major issues that, in our view, prevent the adoption of a generic accelerator offloading strategy. At compiler level, we introduce a new OpenMP-enabled driver implementation which generalizes the current Clang-CUDA approach. The new driver can handle the compilation of several host and device architecture types and can be extended to other offloading programming models such as OpenACC. We developed libomptarget, a runtime library that supports execution of OpenMP 4.5 constructs on NVIDIA architectures and is extensible to other ELF-enabled devices. In this poster we describe two features of libomptarget: the mapping of data to devices and compilation of code sections for different architectures into a single binary. The aforementioned changes have been integrated locally with the Clang/LLVM repositories resulting in a fully functional OpenMP 4.5 compliant prototype. We demonstrate the robustness of our extensions and show preliminary performance results on the LULESH proxy application.
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
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.
Binary Decompilation to LLVM IR - Sandeep Dasgupta
This work is about developing a binary to LLVM IR translator to generate higher quality IR than that generated by the existing tools. Such an IR includes variable information, type information and individual stack frames per procedure, which in turn facilitates many sophisticated analysis and optimizations. We are using an open source tool McSema for the purpose and our goal is to extend the tool to 1) extract variable and type information, 2) improve the quality of recovered IR by mitigating some of its limitations and 3) re-construct stack for each procedure. The current status is we have extended the McSema recovered IR to re-construct the stack for each procedure which in turn will help in doing variable recovery and its promotion.
Dynamic Autovectorization - Joshua Cranmer
We present our ongoing work on augmenting LLVM with a dynamic autovectorizer. This tool uses dynamic information to circumvent the shortfalls of imprecise static analysis when performing loop vectorization, as well as leveraging dynamic transformations of code and memory to make autovectorization and other optimization passes more effective. The key transformations we illustrate in this poster are the extraction of hot paths in innermost loops (with a current speedup of 5% on SPEC against vanilla LLVM) and the conversion of memory from array-of-structs to a struct-of-array representation.
RV: A Unified Region Vectorizer for LLVM - Simon Moll
The Region Vectorizer (RV) is a general-purpose vectorization framework for LLVM. RV provides a unified interface to vectorize code regions, such as inner and outer loops, up to whole functions. Being a vectorization framework, RV is not another vectorization pass but rather enables users to vectorize IR directly from their own code. Currently, vectorization in LLVM is performed by stand-alone optimization passes. Users who want to vectorize IR have to roll their own vectorization code or hope for the existing vectorization passes to operate as the user intends them to. Polly, for example, features a simple built-in vectorizer but also communicates with LLVMs loop vectorizer through metadata. All these vectorizers pursue the same goal that of vectorizing some code region. However, their quality varies wildly and their code bases are redundant. In contrast, with RV users vectorize IR directly from their own code and through a simple unified API. The current prototype is a complete re-design of the earlier Whole-Function Vectorizer by Ralf Karrenberg. Unlike the Whole-Function Vectorizer or any vectorizer in LLVM, RV operates on regions, which are a more general concept. In terms of RV, a valid region is any connected subgraph of the CFG including loop nests. Regions make RV applicable for inner and outer loop vectorization. At the same time, RV attains the capability of its predecessor to vectorize functions into SIMD signatures. However, Whole-Function Vectorization is now only one of many possible use cases for RV. The current prototype of RV implements all stages of a full vectorization pipeline. However, users can compose these stages as they see fit, inserting and extracting IR and analysis information at any point.
Robustness Enhancement of Baggy Bounds Accurate Checking in SAFECode - Zhengyang Liu
Baggy Bounds Accurate Checking(BBAC) is a compile-time transform and runtime hardening solution that detects out-of-bounds pointer arithmetic errors. The original version of BBAC implemented on SAFECode is not robust and efficient enough for real world use. Our work has improved the robustness and performance of the SAFECode's BBAC implementation, by fixing the bugs in the compile-time transform passes and runtime checking functions, as well as inlining several runtime checking functions. The latest implementation of BBAC achieves reasonable robustness and performance on various real world applications.
Extending Clang C++ Modules System Stability - Bianca-Cristina Cristescu
The current state of the Module System, although fairly stable, has a few bugs for C++ support. Currently, the method for ensuring no regressions is a buildbot for libc++, which builds llvm in modules self-hosted mode. Its main purpose is to find bugs in clang’s implementation and ensure no regression for the ongoing development. We propose a flow for finding bugs, submitting them alongside with a minimal reproducer to the Clang community, and subsequently proposing a fix for the issue which can be reviewed by the community. The poster will emphasise, besides the common complexity of minimising an issue, a comparison between the labour required with and without the methodology proposed.
