1. New & Improved LLVM Premerge Testing: Status Update - Caroline Tice, Aiden Grossman
2. Timing-Resistant Coding Support in LLVM - Kelly Kaoudis
3. Impossible Perspectives in Data Layout - Justin Bogner
4. Towards Automatic Reduction of Module Bugs - Maksim Ivanov
5. Save Our Source-Locations - Stephen Livermore-Tozer

New & Improved LLVM Premerge Testing: Status Update - Caroline Tice, Aiden Grossman
In this talk we will give an update on the new premerge testing system, including all the improvements that we have made (and are continuing to make): We have eliminated a major pain point for libc++ developers, by migrating libc++ premerge testing to a set of more powerful, dedicated (non-preemptible) machines; we have made testing both faster and more reliable, by improving start up and build performance and reducing the flakiness of test results; we have made it easier to see and track the performance improvements over time, by overhauling our new dashboard(s) that show the performance and build latencies for the premerge tests. If there is time we will also present our plans for future improvements to the premerge testing system.

Timing-Resistant Coding Support in LLVM - Kelly Kaoudis
There is a fundamental tension between cryptographic coding and compiler optimizations. When cryptographers write C and C++ code that needs to be constant-time, they tend to follow bitwise arithmetic recipes that unfortunately do not always stand up to the optimization pipeline, or they write raw inline assembly. WYSIWYG compiler-level support for constant-time coding will prevent attackers from learning useful information from timing conditional branches, jumps, and memory accesses, and will make it simpler for cryptographers to build the functionality that we all rely on in TLS libraries, hash functions, and more. This talk will cover the technical challenges of constant-time coding support in Clang and LLVM, and how optimization passes can inadvertently introduce timing vulnerabilities.

Impossible Perspectives in Data Layout - Justin Bogner
In this talk, we'll discuss the challenges we faced representing constructs in HLSL that are somewhat odd compared to the usual rules of C and C++, and consider the tradeoffs of various approaches along the way. There are several contexts where HLSL doesn't match C++ in terms of layout. "CBuffers" have rules that grew out of the history of shading languages, DirectX APIs, and weird GPU hardware that result in odd alignment and padding requirements, especially for arrays. The packoffset feature of CBuffers and the vk::offset attribute which can inject arbitrary amounts of padding into a structure. Small vector types are aligned based on their element type instead of their total size. All of these need some care in how they're handled throughout the compiler. This talk will discuss the implementation, present lessons learned, and consider where these techniques are useful in other contexts.

Towards Automatic Reduction of Module Bugs - Maksim Ivanov
Tools that automatically reduce compiler bugs have been known for a long time (C-Reduce, C-Vise, etc.) and have been used effectively to get small reproducers from tens or even hundreds of megabytes of code. However, reducing C++ module bugs specifically presents unique challenges that rendered the tools virtually unusable for that use-case. In this talk, we discuss how we automated module bug reduction at Google by adding necessary support to C-Vise, as well as other improvements we made in the process.

Save Our Source-Locations - Stephen Livermore-Tozer
Keeping an accurate record of source locations for instructions is necessary for both debugging and sample-based PGO, but LLVM can often fail to do so, in part due to the unnecessary dropping of source location information during optimizations, which has led to degradation of source location quality over the course of LLVM's development. To counteract this, we at Sony have added a new feature to LLVM to better track and describe missing source locations, in order to permanently fix this class of problem: this talk will explain how this feature works and what it means for LLVM developers going forwards.