1) Examining and mitigating the performance impact of C++ exceptions on the non-exceptional path in LLVM - C++ exceptions are designed as zero-cost abstractions: no additional code should run if an exception does not occur. However, the presence of additional exception-only code (e.g. landing pads) hampers optimizations in sometimes subtle ways. This talk examines the effects of exception-only code on inlining, memory aliasing and register allocation that leads to measurable performance costs in real programs. Following on, I’ll describe my upstream work at lowering this cost: Clang’s -fnew-infallible flag (https://reviews.llvm.org/D105225) and ThinLink attribute propagation (https://reviews.llvm.org/D36850). I’ll cover the motivation and results behind the previous changes and conclude with some future directions that can be pursued to mitigate the non-exceptional path performance cost of exceptions even further. 2) Rotten Green Unit Tests - A "test" verifies the behavior of some software; if it passes, we call it "green." But an incorrectly constructed test might appear to pass, when in fact it simply doesn't execute; that is, it is "Rotten." Rotten Green Tests are particularly pernicious because they LOOK reasonable to a human reading the test; but they fail to provide the verification they are meant to, and consume testing resources to no benefit. I've prototyped support for detecting Rotten Green Tests in LLVM's copy of googletest, the test framework for unittests in Clang and LLVM. I'll describe how the prototype works, brag about the successes, and admit there's more work to do. 3) Representing Concurrency with Graph Regions in MLIR - CDFG-style IRs, such as LLVM middle-end IR and the Machine Code (MC) layer are great for representing sequential languages (like C/C++) and sequential machines (like RISC processors). However, CDFGs are less appropriate for representing concurrent languages and targets and more general graphs are often used. MLIR allows regions to be either CDFG-based or Graph-based, enabling a wider range of models to be conveniently represented. This talk will outline the differences between CDFG Regions and Graph Regions in MLIR and highlight some examples of how Graph Regions are used in different Dialects, including examples drawn from the CIRCT incubator project. 4) Building a faster expression evaluator for LLDB - The expression evaluator in LLDB uses Clang to compile the expressions and can handle almost any valid C++ code. It is very powerful, however for certain use cases (e.g. IDE integration, implementing NatVis visualizers) it may be not fast enough to provide interactive user experience. In order to improve the performance of the expression evaluation and provide additional features relevant for IDE integrations, we present a new interpreter-based C++ expression evaluator which is meant to replace LLDB's evaluator in the majority of use cases. 5) lldb-eval fuzzer: Finding bugs in an LLDB-based expression evaluator - Lldb-eval is an LLDB-based interpreter for evaluating C++ expressions in the context of the debuggee process. It is used in Stadia integration for Visual Studio. This talk focuses on testing lldb-eval to ensure correctness and reliability. Conventional testing methods, such as manual and unit testing, can be used for testing single language concepts (e.g. address-of, member-access, binary expressions, etc). However, sometimes bugs manifest in combination of different concepts, which are impractical to test using conventional methods. Lldb-eval fuzzer uses a random test-case generation method to approach this problem: it continuously generates random C++ expressions, evaluates them against lldb-eval and LLDB's native expression evaluator and compares results. It is integrated with libFuzzer to leverage coverage-guided and mutation-based fuzzing. To this date the fuzzer was able to find dozens of bugs in lldb-eval. 6) Clang Static Analyzer - A Tryst with Smart Pointers - With the Google Summer of Code (GSoC) project of this year, the Clang Static Analyzer (CSA) has a near-stable checker for detecting null-dereferences of smart pointers. For present and potential CSA devs, this project is interesting because it gives valuable insights into the process of modelling a complex C++ class in CSA, which traditionally has been more tailored to C and Objective-C.