Our existing instruction selection framework, SelectionDAGISel (SDISel), has some fundamental limitations, including, but not limited to, slow compile time, basic block only scope, and monolithic approach. Over the years, we spent a lot of effort to workaround these limitations with more target hooks and more optimizations passes (e.g., CodeGenPrepare, ConstantHoisting) with their own problems (inaccurate heuristic, have to predict what the instruction selector will do, etc.) and limitations.
We believe that it is time to come up with a new instruction selection framework, global-isel, that will solve these problems while offering new opportunities to improve our code generation. In this talk, we will present our plan to bring global-isel to LLVM.
OpenCL programs are prone to memory and control flow divergence. When implementing OpenCL for machines with explicit SIMD instructions, compilers can usually generate more efficient code if they can prove non-divergence of memory and branch instructions. To this end, they leverage a so-called divergence analysis. However, in practice divergence is often input-dependent and exhibited for some, but not all inputs. Hence, static analyses fail to prove non-divergence. To obtain good performance, developers can manually split the input space, however this is a tedious and error prone task.
In this talk we present a new OpenCL to CPU compiler pipeline that addresses this problem by automatically ensuring divergence free control flow through program specialization. To this end we represent the full kernel as well as the implicit work item dimensions in the polyhedral model. For data dependent control flow and non-affine expression overapproximation is used. From the polyhedral iteration domains and memory access functions we can then derive conditions for the absence of memory as well as control divergence. Based one these conditions the input space is split in order to generate specialized kernel versions with beneficial divergence characteristics. Commonly large parts of the input exhibit regular access and control patterns and only a fixed size boundary of the input space does not. In such cases we can achieve speedups almost as high as the used vectorization with. However, also for non-diverging kernels our technique can improve the performance due to simplifications in the polyhedral model.
The Sanitizers (AddressSanitizer & friends) allow you to find many stability and security bugs in C++ code, but they are only as good as your tests are. In this talk we will show how to improve your test coverage with guided fuzzing (libFuzzer) and how to protect your applications in production even if some bugs are still there (Control Flow Integrity and SafeStack).
Indirect call promotion (ICP) is the second most profitable profile-based optimization according to a recent study. This talk will present LLVM ICP pass that iterates over all indirect call sites in the module and selectively transforms them. We will discuss how subsequent optimizations in the compiler pipeline may benefit from ICP.
Hexe, which stands for Heterogeneous Execution Engine, is an new compiler component that integrates with the LLVM infrastructure. It targets efficient computation on heterogeneous platforms by allowing the automatic offloading of workloads on computational accelerators, such as Graphics Processing Units (GPUs) or Digital Signal Processors(DSPs).
The workloads we consider for offloading are either explicitly annotated by the programmer or automatically detected by static compiler analysis and runtime checks. Our infrastructure operates at the level of LLVM intermediate representation and effectively supports multiple source languages.
Hexe consists of a set of compiler passes and a runtime environment. The compiler passes perform the required code analysis and transformations to enable workload offloading. The runtime environment manages data transfers and synchronization operations, and performs dynamic workload scheduling.
We consider a diverse set of heterogeneous systems ranging from mobile devices equipped with arm based multi-core CPUs, embedded GPUs and DSPs to data center nodes consisting of x86 multi-cores and high-end GPUs. Hexe has a modular design where new accelerator types and programming environments can be supported via a plugin interface. We also consider interoperability between Hexe and modern JIT technologies, such as LLVM MCJIT.
Ensuring that top-of-trunk consistently generates high-quality code remains harder than it should be. Continuous integration (CI) setups that track correctness of top-of-trunk work pretty well today since they automatically report correctness regressions with low false positive rate to committers. In comparison, the output generated by CI setups that track performance require far more human effort to interpret.
In this talk, I’ll describe why I think effective performance tracking is hard and what problems need solving, with a focus on our real world experiences and observations.
As part of the bring-up of one of the public performance tracking bots, I’ve done an in-depth analysis of its performance and noise characteristics. The insights gained from this analysis drove a number of improvements to LNT and the test-suite in the past year. I hope that sharing these insights will help others in setting up low-noise performance-tracking bots.
I’ll conclude by summarizing what seem to be the most important missing pieces of CI functionality to make the performance-tracking infrastructure as effective as the correctness-tracking infrastructure.
While LLVM is known for very fast compile-time, many developers in the community also push for improving run-time performance of generated code. This talk highlights this year’s performance gains on AArch64 in key benchmarks like SPEC2006, Kernels and also the llvm test suite. While progress has been impressive more work needs to be done. Therefore we will discuss future performance headroom which involves both expanding existing and architecting new optimizations.
In an effort to simplify and canonicalize LLVM IR surrounding pointer expressions, the type information from pointers is being removed. Hear about the current changes, utilities for updating your test cases, as well as current open questions and future work.
This talk covers the design and implementation of MSVC-compatible exception handling in Clang and LLVM. Unlike the Itanium C++ exception handling model, the Windows exception handling model is not designed around successive unwinding. As a result, the existing LLVM landingpad instruction is insufficient for expressing how Windows exceptions should be handled. To support Windows exceptions, we added the new token type and a family of new EH pad instructions to LLVM. This talk describes the final design of the new representation and the tradeoffs we made along the way.
This talk presents Google’s effort of optimizing LLVM for CUDA. When we started this effort, LLVM was well-tuned for CPUs but there had been little public work on improving its GPU performance. We developed, tuned, and augmented several general and CUDA-specific optimization passes. As a result, our LLVM-based compiler generates better code than nvcc on key end-to-end internal benchmarks and is on par with nvcc on a variety of open-source benchmarks.
This talk is going to give an update of the C++ tooling we are building on top of clang. Among others, it will focus on clang-tidy, a tool to statically analyze source code to diagnose and fix typical programming errors like style violations, interface misuse, or bugs. We'll give an update on the direction this project is taking, new checks that are being integrated and challenges we are facing.
In a live demo, we'll show how we can fix specific problems throughout LLVM's own codebase. We'll also show how a new check can be added in a matter of minutes and how other Clang-based tools can help with its development.
GPU/Accelerator computing will be the basis for the future of Exacale computing through the DOE's CORAL project. It is also the basis for future features for C++ Std's SG14's Games Development/Low Latency/Real Time/Graphics Study Group. However, llvm currently lacks a unified platform-neutral infrastructure for offloading to GPUs/Accelerators, which severely limits clang/llvm usage in these hugely important application domains.
For the past several years, a number of contributors from AMD, Argonne National Lab., IBM, Intel, Texas Instruments, University of Houston and many others have come together to deliver OpenMP support to clang. OpenMP 3.1 is now officially in clang 3.7 and work continues to completion of OpenMP 4 aiming for clang 3.8. One of the most important features of OpenMP 4 standard is a vendor- and platform-neutral support for Accelerators.
The main presenters will be the OpenMP CEO and Chair of ISO C++'s SG5/SG14 along with the main developer who has been delivering OpenMP implementation in clang (with the help of many others). This talk will describe how GPU and Accelerators will be supported in clang. It offers an overview of the OpenMP 4 syntax, and a description of the upstreaming progress in both clang and llvm through this continued collaboration, as well as the offloading interface design that will describe target independent support across many hardware targets including Nvidia, Xeon Phi, ARM, and AMD devices.
For a little over a year we have been working towards a production quality, state of the art LLVM based JIT compiler for Java. This talk focuses on what we've learned about LLVM's strengths and weaknesses as an optimization framework for Java-like languages. We will discuss interesting challenges in efficiently implementing Java's semantics within LLVM IR, and how we've been growing LLVM towards being a more effective compiler for managed languages.
SIMD vectors are widely adopted in modern general purpose processors as they can boost performance and energy efficiency for certain applications.
Compiler-based automatic vectorization is one approach for generating code that makes efficient use of the SIMD units, and has the benefit of avoiding hand development and platform-specific optimizations.
The Superword-Level Parallelism (SLP) vectorization algorithm is the most well-known implementation of automatic vectorization when starting from straight-line scalar code, and is implemented in several major compilers.
The existing SLP algorithm greedily packs scalar instructions into vectors starting from stores and traversing the data dependence graph upwards until it reaches loads or non-vectorizable instructions.
Choosing whether to vectorize is a one-off decision for the whole graph that has been generated.
This, however, is suboptimal because the graph may contain code that is harmful to vectorization due to the need to move data from scalar registers into vectors.
The decision does not consider the potential benefits of throttling the graph by removing this harmful code.
In this work we propose a solution to overcome this limitation by introducing Throttled SLP (TSLP), a novel vectorization algorithm that finds the optimal graph to vectorize, forcing vectorization to stop earlier whenever this is beneficial.
Our experiments show that TSLP improves performance across a number of kernels extracted from widely-used benchmark suites, decreasing execution time compared to SLP by 9% on average and up to 14% in the best case.
The Hip-Hop Virtual Machine (HHVM) is a JIT compiler for executing PHP programs. It is used by some of the world’s largest websites such as facebook.com and wikipedia.org, among many others. At Facebook we have frequently been asked why we don't use LLVM as a back end for HHVM. Inspired by the success of Apple’s FTL we implemented an alternative back end using LLVM.
In this talk we will share what it took to hook LLVM in to HHVM from conception to running limited production traffic. We will cover changes to our internal IR and modifications we had to make to LLVM. We will discuss performance challenges we faced, peculiar bugs, and finally will discuss why we are not yet at the point of enabling the LLVM back end for production Facebook traffic.
Loop invariant code motion is an important compiler optimization and it moves invariant instructions out of a loop without affecting the semantics of a program.
For safety it ensures the alias dependencies before moving invariant out of loop.
In some cases memory aliasing may make this optimization ineffective. This results in possible missed opportunities in speeding up applications.
LoopVersioning LICM is a step to exploit those missed opportunities where memory aliasing may make LICM optimization ineffective.
llvm 3.7 is the first release that can build large projects such as Chromium on Windows without having to fall back to Visual Studio's compiler for a single translation unit. This talk gives an overview of the work done to get to this state: It covers language extensions clang needed to learn to parse Microsoft's headers and dark corners of the Microsoft ABI, with a focus on work done in the last year. Much of the Windows support was developed in tight collaboration between the Chromium and LLVM projects. The talk also touches on how this collaboration works and why it’s successful. Finally, the talk also gives an overview of how to get projects building with clang that build with Visual Studio.
The efficiency of debug info in LLVM and Clang improved dramatically this year. This talk is about what it took to get here and what work remains.
We'll talk about how Metadata was redesigned to make the debug info IR memory-efficient (with a human-readable assembly syntax). We'll go into the implications for other Metadata graphs, and what a more expressive Metadata future could look like. We'll also include an overview of what's left to scale debug info for LTO.
We'll also talk about Clang's new module debugging feature, which reduces the size of debug info on disk, improves compile time, and makes full type information available to debuggers. We'll highlight how Clang-based debuggers like LLDB can use module debug information to enhance expression evaluation.
The talk will survey recent advances in loop analysis frameworks to support optimizations like unrolling, distribution, loop-aware load-elimination and multi-versioning. A significant part of our contribution was to rethink and re-design existing analysis frameworks to make them both more powerful and more widely accessible. The major part of this talk will focus on introducing these analysis frameworks and how they are used by optimizations. We will also discuss how they integrate with other analysis passes and outline ideas for their future evolution.
