2. Do we even need this test? What to Do with a Retiring Backend's Decade of Tests — Zmicier Prybysh
3. Lightweight Fault Isolation in LLVM, One Year Later — Zachary Yedidia, Sharjeel Khan
4. Bringing TypeSanitizer to PlayStation — Matthew Nagy
5. Storing Arrays in MLIR: A Field Guide to Elements Attributes and Custom Element Types — Matthias Springer
1. A Latency-(In)Sensitive Tale Of Hardware Verification — Luisa Cicolini
Hardware compilers like CIRCT can transform a high-level representation of hardware, such as a C++ program, into a low-level hardware description through numerous lowerings and abstractions. Given their critical role in hardware design, verifying these compilers is essential to ensure the functional correctness of hardware. At the higher level of abstraction, components exchange messages through a communication protocol without a fixed notion of time. At the lower level, we find a cycle-aware representation, where every operation is mapped to a specific clock cycle. The transformation from latency-insensitive to latency-sensitive is very hard to reason about.
We aim to close this abstraction gap by using coinduction, a mathematical framework to describe the behaviour of infinite streams. By representing both levels as streams, we can use the magic (and beauty!) of weak bisimilarity to reason about the transformation’s correctness, showing exactly how an elastic, latency-insensitive behavior evolves into a concrete RTL design.
2. Do we even need this test? What to Do with a Retiring Backend's Decade of Tests — Zmicier Prybysh
Retiring a compiler's backend means deciding, for every one of its tests, whether it checks something that makes it worth keeping. In this talk I show how I triaged ~200 CHERI-MIPS CodeGen/MC tests by collecting evidence for each one: what the test actually checks, its git history, whether the regression it guards can still happen, whether an equivalent test already exists on another backend, and more. A person made every decision based on that evidence, with an AI agent automating evidence collection. I'll share what any compiler retiring a target can learn from our experience.
3. Lightweight Fault Isolation in LLVM, One Year Later — Zachary Yedidia, Sharjeel Khan
Lightweight Fault Isolation (LFI) is a low-overhead, in-process sandboxing solution built into LLVM to protect native C, C++, and assembly code. It uses MCInst-level instruction rewriting to restrict libraries within a 4GiB virtual address space, ensuring strong compatibility with existing tools and codebases while minimizing performance impact. Due to these characteristics, LFI offers a 3x-7x reduction in sandboxing overheads vs. Wasm, today incurring roughly 7% overhead vs. native code. This technology can be utilized to transition vulnerable libraries like audio codecs from out-of-process directly into the host process to reduce interprocess communication (IPC) overheads. Following last year's introductory talk on Lightweight Fault Isolation (LFI), this presentation offers a comprehensive update on its LLVM integration and practical applications. First, we will cover the AArch64 and X86_64 backend components that were upstreamed over the past year, alongside practical guidance for using LFI to sandbox custom libraries. Next, we will discuss key deployments, specifically Android's libopus audio codec, highlighting the performance improvement they received. Finally, we outline future development directions, including support for dynamic sandbox sizing, SafeStack integration, and kernel modules.
4. Bringing TypeSanitizer to PlayStation — Matthew Nagy
TypeSanitizer is a tool for detecting strict-alias violations in codebases. This is very attractive to game developers that want to make use of all possible optimizations. This talk will discuss how we ported TypeSanitizer to PlayStation, upstream improvements that were made with this goal in mind, and different design trade-offs and lessons learned from deploying on real-world code.
5. Storing Arrays in MLIR: A Field Guide to Elements Attributes and Custom Element Types — Matthias Springer
MLIR offers a whole family of array-like attributes such as ArrayAttr, DenseArrayAttr and DenseTypedElementsAttr, and it is not always obvious which one to use or why they all exist. This quick talk is a practical field guide to these attributes, followed by a look at a recent generalization that lets DenseElementsAttr store arbitrary custom element types via the new DenseElementType interface.