1. The Matrix Type Reloaded: Matrices in HLSL and beyond — Farzon Lotfi
This talk explores how the HLSL team "reloaded" the Clang matrix type, building upon the groundwork laid in 2020 to bring HLSL's matrix semantics to Clang. This effort provides a blueprint for how C/C++ could adopt similar features in the future. 

2. Intangible Types: Implementing HLSL Resources in Clang — Helena Kotas
In this talk, we'll discuss the challenges we faced while implementing HLSL resources in Clang. Resource types are what we call intangible types: they have no defined object or value representation, and their size is unknown at compile time. We'll explain the attributed type we introduced to represent resource handles, how we implement the HLSL Standard Library resource classes, and the challenges we encountered in Clang CodeGen when these types are used in user-defined structs alongside fields that follow the HLSL constant buffer layout.

3. Object Linking and ThinLTO for GPU Programs — Shilei Tian
GPU kernels are dispatched as resource allocation requests: before execution begins, the runtime and hardware must know each kernel's register usage, shared memory requirement, and other compiler-managed resource counts. These values depend on the kernel's transitive device call graph, which may span multiple translation units under separate compilation. The standard workaround today is full LTO, which merges all device IR into a single module to restore whole-program visibility, but this scales poorly for large GPU programs. This talk describes how a lightweight finalization step at static device link time can resolve per-kernel resource metadata over ordinary object files, using compact per-function summaries emitted by the backend. It explains why some of this work, particularly resolving shared memory layouts and other resource symbols referenced by the generated code, is inherently part of linking. The talk uses the LLVM AMDGPU implementation as a concrete reference and also describes how ThinLTO can complement object linking by propagating optimization-relevant information before parallel backend compilation.

4. Symbol Metadata Relocations: Facilitating Compiler to Linker Communication — Todd Snider
Embedded application developers often need to convey symbol metadata information from the compiler to the linker. There are kinds of symbol metadata that the compiler can use for things such as: indicating specific placement for a function or variable, dictating how and/or whether a variable is initialized at boot time, enabling link-time specialization of runtime library functions, and guiding the placement of functions and variables based on knowledge of a memory system to improve performance to name just a few. This presentation follows up a discussion ([RFC] .symtab_meta - a .symtab extension to communicate symbol metadata from the compiler to the linker - LLVM Project - LLVM Discussion Forums) on this topic arriving at the conclusion that relocation entries are an appropriate and effective means of communicating symbol metadata from the compiler to the linker.

5. So you want to contribute to LLVM? — Justin Fargnoli
Two or three weeks can pass between LLVM review rounds, turning a small change into two or three months of work. Some iteration is unavoidable, especially when new contributors are learning undocumented invariants and architectural constraints. This talk offers practical advice for contributors preparing their first few LLVM changes: deciding when a change is ready for review, finding an appropriate reviewer, and responding to feedback so each asynchronous exchange accomplishes as much as possible. It will also encourage new contributors to review other people’s patches—even when they are not the final subject-matter expert—so we can create more review capacity for one another.