2019 EuroLLVM Developers' Meeting

In this talk, we present the current state of the Explicit Vector Length extension for LLVM. EVL is the first step towards proper predication and active vector length support in LLVM IR. There has been a recent surge in vector ISAs, let it be the RISC-V V extension, ARM SVE or NEC SX-Aurora, all of which pose new demands to LLVM IR. Among their novel features are an active vector length, full predication on all vector instructions and a register length that is unknown at compile time. In this talk, we present the Explicit Vector Length extension (EVL) for LLVM IR. EVL provides primitives that are practical for both, backends and IR-level automatic vectorizers. At the same time, EVL is compatible with LLVM-SVE and even existing short SIMD ISAs stand to benefit from its consistent handling of predication.

Interprocedural optimizations (IPOs) have been historically weak in LLVM. The strong reliance on inlining can be seen as a consequence or cause. Since inlining is not always possible (parallel programs) or beneficial (large functions), the effort to improve IPO has recently seen an upswing again [0,1,2]. In order to capitalize this momentum, we would like to talk about the current situation in LLVM, and goals for the immediate, but also distant, future.
This open-ended discussion is not aimed at a particular group of people. We expect to discuss potential problems with IPO, as well as desirable analyses and optimizations, both experts and newcomers are welcome to attend.

[0]   https://lists.llvm.org/pipermail/llvm-dev/2018-August/125537.html
[1] These links do not yet exist but will be added later on.
[2] One link will be an RFC outlining missing IPO capabilities, the other will point to a function attribute deduction rewrite patch (almost finished).

LLVM has a suite of binary utilities that broadly mirror the GNU binutils
suite, with tools such as llvm-readelf, llvm-nm, and llvm-objcopy. These tools
are already widely used in testing the rest of LLVM, and are now starting to be
adopted as full replacements for the GNU tools in production environments.

This discussion will focus on what more needs to be done to make this migration
process easier, how far we need to go to make drop-in replacements for the GNU
tools, and what features people want to prioritize. Finally, we will look at
the broader future goals of these tools.

LLVM is used as a foundation for majority of OpenCL compilers, thanks to excellent support of OpenCL C language in Clang frontend, and modularity of LLVM. Unfortunately, a compiler is not the only component that is required to develop using OpenCL: users need a runtime library that implements the OpenCL API. While there are several implementations of OpenCL runtime exist, both open and proprietary, they do not have a community wide adoption. This leads to fragmentation and effort duplication across OpenCL community, and negatively impacts OpenCL ecosystem in general.

The purpose of this BoF is to bring all parties interested in getting a reference OpenCL Runtime implementation in LLVM, that is designed to be easily extendable to support various accelerator devices (CPU/GPU/FPGA/DSP) and allow users and compiler developers to rapidly prototype OpenCL specific functionality in LLVM and Clang.

The goal of this BoF is to create the basis for a new page of documentation enumerating the stability guarantees of interfaces exposed from LLVM products.

There are some interfaces which are known to make no stability guarantees, such as the Clang C++ API, others which make strict API guarantees, such as the libclang C API, and still others, such as the LLVM IR API which is somewhere in between. Only the latter appears in the LLVM Developer Policy. Mostly the rest of the interface stability guarantees are tribal knowledge.

A centralized location in the documentation for this documentation would present guidelines for developers to follow when changing various parts of LLVM code, and inform consumers what they can expect and rely upon when using interfaces. This includes code interfaces and command line interfaces.

Let’s discuss the present and future of the Clang Static Analyzer! We’ll start with a brief overview of analyzer features the community has added over the last year. We’ll then dive into a discussion of possible focus areas for the next year, including potential deeper integration with clang-tidy.

Interprocedural optimizations (IPOs) have been historically weak in LLVM. The strong reliance on inlining can be seen as a consequence or cause. Since inlining is not always possible (parallel programs) or beneficial (large functions), the effort to improve IPO has recently seen an upswing again [0,1,2]. In order to capitalize this momentum, we would like to talk about the current situation in LLVM, and goals for the immediate, but also distant, future.

This open-ended discussion is not aimed at a particular group of people. We expect to discuss potential problems with IPO, as well as desirable analyses and optimizations, both experts and newcomers are welcome to attend.

[0] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125537.html
[1] These links do not yet exist but will be added later on.
[2] One link will be an RFC outlining missing IPO capabilities, the other will point to a function attribute deduction rewrite patch (almost finished).