C++ Blogs, the last 7 days

Thursday, September 24, 2026

Remembering Johannes DoerfertIt is with great sadness that we share the news of the passing of Johannes Doerfert, on September 17, 2026, at the age of 36, after a battle with cancer. Johannes was one of the most prolific and respected contributors to the LLVM compiler project, and his loss will be deeply felt. Johannes was born on November 5, 1989. He earned his Ph.D. in computer science from Saarland University in Saarbrücken, Germany, in 2018, where his research focused on applying polyhedral compiler technologies to low-level code. He had been an active LLVM contributor since 2014, working in the compiler design lab of Prof. Sebastian Hack, and became a core developer on the Polly polyhedral-optimization project as early as 2012. Over the following decade, Johannes built a career at the intersection of compiler research and high-performance computing, most recently as a researcher focused on OpenMP, LLVM, and parallel program optimization. Contributions to LLVM Johannes’s worked on many parts of the LLVM Project, and these are just a few of his contributions: The Attributor framework. Johannes designed and championed the Attributor, LLVM’s versatile inter-procedural fixpoint iteration framework for deducing and propagating function and argument attributes across a program. He introduced it to the community at the 2019 LLVM Developers’ Meeting, and it has since become an important piece of LLVM’s interprocedural optimization infrastructure. OpenMP and GPU offloading. Johannes became LLVM’s code owner for OpenMP target offloading in 2021, leading the compiler and runtime support that lets OpenMP programs run efficiently on GPUs across NVIDIA, AMD, and Intel hardware. His work spanned the OpenMP runtime, just-in-time compilation and link-time optimization for target offloading, and techniques for near-zero-overhead GPU execution. Polly and polyhedral optimization. Early in his career, Johannes was a core developer of Polly, LLVM’s polyhedral loop optimization infrastructure, and published research on polyhedral scheduling in the presence of reductions and on optimistic loop optimization. He authored or co-authored dozens of papers on compiler optimization, automatic differentiation of GPU kernels, performance portability, and OpenMP. Community Building Johannes helped organize EuroLLVM 2017 in Saarbrücken, Germany, the LLVM-HPC workshop at CGO from 2017 onward, and the LLVM events at ISC starting in 2019, helping join together the LLVM and HPC communities. He was frequently in attendance at the LLVM Developers’ Meeting Newcomer and Community.o sessions. He welcomed newcomers to the LLVM Developers’ Meetings and shared his advice and wisdom on how to get more involved in the project. Johannes also held LLVM office hours on a weekly basis, where he answered questions on OpenMP, LLVM-IR, interprocedural optimizations, Attributor, workshops, research, and more. Mentoring the Next Generation Johannes was a Google Summer of Code mentor for LLVM for several years and helped student contributors on various projects. Here are just a few: 2016 Polly as an Analysis Pass in LLVM 2019 Improve (function) attribute inference (with Brian Homerding) Improve (function) attribute inference - 2 (with Brian Homerding) Generation of Annotated Sources (with Brian Homerding) 2020 Improve Parallelism-Aware Analyses and Optimizations (with Jon Chesterfield) Advanced Heuristics for Ordering Compiler Optimization Passes (with EJ Park and Giorgis Georgakoudis) Improve inter-procedural analyses and optimizations (with Brian Homerding) Advanced Heuristics for Ordering Compiler Optimization Passes - 2 (with EJ Park and Giorgis Georgakoudis) Latency Hiding for Host to Device Memory Transfers (with Jon Chesterfield) Improve inter-procedural analyses and optimizations - 2 (with Brian Homerding) Deduce attributes for non-exact functions (with Brian Homerding) 2021 Learning Loop Transformation Heuristics (with Mircea Trofin) Integrate custom derivatives of Numerical Computing routines like BLAS and Eigen into Enzyme (with William Moses and Vassil Vassilev) Improving OpenMP code generation with prediction of runtime parameters (with Jon Chesterfield) Integrate Enzyme into Rust to Provide High-performance Differentiation in Rust (with William Moses) Improve inter-procedural analyses and optimizations (with Jon Chesterfield) Use official isl C++ bindings for polly (with Michael Kruse) Integrating Enzyme into Rust (with William Moses) 2022 Non-Determinacy based optimizations in Parallel Programs (with William Moses) Learning loop transformation policy and its effect on RISC-V (with Mircea Trofin) 2023 Machine Learning Guided Ordering of Compiler Optimization Passes (with Tarindu Jayatilaka and Mircea Trofin) 2024 The 1001 Thresholds in LLVM (with Jan Hückelheim and William Moses) GPU Libc Benchmarking (with Joseph Huber) Statistical Analysis of LLVM-IR Compilation (with Aiden Grossman) 2025 Improve Rust-Enzyme Reliability and Compile Times (with Manuel Drehwald and Kevin Sala) LLVM Compiler Remarks Visualization Tool for Offloading (with Jose M Monsalve Diaz and Kevin Sala) A Decade at the Podium Besides the countless code contributions, mentorship, and community building, Johannes was a constant presence at US LLVM Developers’ Meetings and EuroLLVM. He spoke at 11 meetings across 11 years (2015–2024) , for at least 26 speaking sessions and even more that he helped author. 2015 — US DevMtg (San Jose) Input Space Splitting for OpenCL Tutorial: Polly - Optimistic Loop Nest Optimizations with Schedule Trees (with Tobias Grosser) 2016 — EuroLLVM (Barcelona) Analyzing and Optimizing your Loops with Polly (with Tobias Grosser) BoF: Polly - Loop Optimization Infrastructure (with Tobias Grosser and Zino Benaissa) 2017 — US DevMtg (San Jose) BoF: Thoughts and State for Representing Parallelism with Minimal IR Extensions in LLVM (with Xinmin Tian, Hal Finkel, Tb Schardl and Vikram Adve) Polyhedral Value & Memory Analysis 2017 — EuroLLVM (Saarbrücken) Co-organizer 2018 — US DevMtg (San Jose) Optimizing Indirections, using abstractions without remorse BoF: Ideal versus Reality: Optimal Parallelism and Offloading Support in LLVM (with Xinmin Tian, Hal Finkel, TB Schardl, and Vikram Adve) 2019 — EuroLLVM (Brussels) Compiler Optimizations for (OpenMP) Target Offloading to GPUs BoF: IPO — Where are we, where do we want to go? (with Kit Barton) 2019 — US DevMtg (San Jose) The Attributor: A Versatile Inter-procedural Fixpoint Iteration Framework Tutorial: The Attributor: A Versatile Inter-procedural Fixpoint Iteration Framework Tutorial: An overview of LLVM Poster: Attributor, a Framework for Interprocedural Information Deduction (with Hideto Ueno and Stefan Stipanovic) 2020 — US DevMtg (virtual) The Present and Future of Interprocedural Optimization in LLVM (with Brian Homerding, Stefanos Baziotis, Stefan Stipanovic, Hideto Ueno, Kuter Dinel, Shinji Okumura, Luofan Chen) (OpenMP) Parallelism-Aware Optimizations (with S. Stipanovic; H. Mosquera; J. Chesterfield; G. Georgakoudis; J. Huber) Tutorial: A Deep Dive into the Interprocedural Optimization Infrastructure (with B. Homerding; S. Baziotis; S. Stipanovic; H. Ueno; K. Dinel; S. Okumura; L. Chen) 2021 — US DevMtg (virtual) Panel: Machine Learning Guided Optimizations in LLVM Optimizing OpenMP GPU Execution in LLVM (with Giorgis Georgakoudis and Joseph Huber) 2022 — US DevMtg (San Jose) Panel: Machine Learning Guided Optimizations (MLGO) in LLVM Panel: High-level IRs for a C/C++ Optimizing Compiler CUDA-OMP — Or, Breaking the Vendor Lock (with Joseph Huber) Thoughts on GPUs as First-Class Citizens 2023 — EuroLLVM (Glasgow) How to run the LLVM-Test Suite on GPUs and what you’ll find OpenMP as GPU Kernel Language 2024 — US DevMtg (Santa Clara) (Offload) ASAN via Software Managed Virtual Memory Johannes Will Be Missed Beyond the commits, the talks, and the papers, those who worked with Johannes remember him as a person full of life and a good sense of humor. He is someone who signed his social media bio simply as “LLVM Developer, OpenMP contributor, Beer drinker, not in this order.” A memorial service will be held on Saturday, October 3, 2026, from 1:00 to 5:00 PM at San Jose Funeral Service in San Jose, California, with a separate service planned in Germany. He is survived by his wife, Xuejin Zhang, his father, Jürgen Doerfert, and other family and friends around the world. In lieu of flowers, his family has asked that those who wish to honor his memory consider a donation to the LLVM Foundation (either through Everloved or directly), the organization whose mission he spent his career supporting and advancing. A very generous donor has agreed to match 50K in donations in honor of Johannes. If you donate directly to the LLVM Foundation via a DAF, please indicate in memory of Johannes Doerfert. More details, and a place to share memories and condolences, can be found on Johannes’s memorial page .The LLVM Project Blog
Why Tests Became the Product: A Conversation with Titus Winters | EngFlowWhy Tests Became the Product: A Conversation with Titus Winters A conversation with Titus Winters · Notes From The Fleet series Watch the full interview I sat down with Titus Winters to talk about developer experience and infrastructure at scale. Titus co-wrote Software Engineering at Google ; he is now a Senior Principal Scientist at Adobe. I expected a conversation about build systems. What I got was a line I've been thinking about ever since: "The question is not what can you build with an incredibly fast, 80% accurate tool. It's what can't you build with an infinite army of incredibly fast, 80% accurate tools." An infinite army of 80% accurate tools. That army doesn't have a code generation problem. It has a verification problem. Whether it helps you or buries you depends on the systems that check, integrate, and maintain everything it produces. [![Titus Winters interview](/images/2026-titus-winters/titus-interview.png)](https://youtu.be/YyqgNpNQJwQ?si=FQdLSQxUJXHmn5qz){ class="img-fluid w-100"} Titus Winters on the shift from code generation to verification in the AI eraEngFlow Blog

If this page is useful, please consider donating a coffee

Wednesday, September 23, 2026

Canvas2D: WatchUI DemoIn the previous blog post I introduced Canvas2D , the new QML item in Qt 6.12 that lets you paint with JavaScript using the GPU through Qt Canvas Painter. That post was about the API: what it is, how it compares to Qt Quick Canvas and to the QCanvasPainter C++ API , and how fast it is. But that post might have left someone wondering what a real UI built with it could actually look like. So, while testing Canvas2D (and QQEM) in preparation for the Qt 6.12.0 release, I spent a few days building a demo application to give some ideas. WatchUI is a smartwatch demo with six swipeable views, running on a 3D watch model. This is based on the smartwatch demo that was built a while back for the Qt 6.5 release . But the content of the watch screen has been reimplemented using not just QQEM effects but also Canvas2D. The demo looks like this:Qt Blog
Hot Reload in Qt 6.12QML Preview We've had a thing called "QML Preview" for a number of years now. You can be forgiven for not having noticed. It's well hidden deep in the guts of Qt Design Studio where it's quietly doing what it does: it runs your design through the qml tool and gets notified when you change some file. Then it re-loads the currently visible scene, without re-starting the process, making your changes visible. This way you get faster turnaround when prototyping different designs.Qt Blog
⬢ Distrobox: An In-depth Guide for Developers - Part 1Distrobox gives developers a fast, practical way to work across Linux distributions without the setup time and resource overhead of full virtual machines. This in-depth guide explains how Distrobox builds on OCI containers and tools such as Podman or Docker to create tightly integrated development environments—with access to your home directory, graphical sessions, devices, and host tooling. Learn why it is useful for reproducing distro-specific bugs, testing software on multiple platforms, accessing alternative package repositories, and combining a stable host OS with flexible, disposable userlands.KDAB

Tuesday, September 22, 2026

Faster C++ code intelligence for Copilot CLI with Whole Codebase IndexingC++ repositories can contain millions of lines of code spread across deeply connected source files and headers. Without a reusable index, navigating to definitions, finding references, or searching for symbols may require portions of that information to be analyzed again as you move through the repository. C++ code intelligence in GitHub Copilot CLI is now […] The post Faster C++ code intelligence for Copilot CLI with Whole Codebase Indexing appeared first on C++ Team Blog .C++ Team Blog

Monday, September 21, 2026

No imageGSoC 2026: Improving HLSL Support in clangdGSoC 2026: Improving HLSL Support in clangd HLSL (High-Level Shading Language) is a C++-like language used for GPU shader programming. Clang already parses HLSL and represents many of its constructs in the AST. clangd , however, reuses its C/C++ infrastructure to provide IDE features such as hover, code completion, diagnostics, and navigation. Clang may fully understand an HLSL construct, while clangd does not necessarily know how to expose that information to the user. For example, HLSL has language-specific constructs such as semantic annotations, resource bindings, out / inout parameters, shader attributes, and vector and matrix swizzles. These constructs do not always have direct equivalents in standard C++, so the existing clangd infrastructure does not automatically provide the expected editor experience. The goal of my Google Summer of Code 2026 project was to identify these gaps and improve HLSL support in clangd . I first wanted to understand the current state of HLSL support, identify where the problems were coming from, and determine which solutions would fit best into the existing Clang and clangd architecture. The project followed this process: Gap Analysis | v Investigation | v Implementation Ideas | v RFC | v Community Feedback | v GitHub Issues | v Pull Requests Finding the Gaps The first phase of the project was a to do a gap analysis. I created isolated HLSL test cases covering different categories of language constructs and tested them using several clangd features: hover, code completion, go-to-definition, and diagnostics. When the behavior was unclear, I also inspected Clang’s AST to determine whether the required information was already available to clangd. The goal was to distinguish between different kinds of problems. Some constructs were already represented correctly in the AST but were not exposed by clangd. Others involved configuration, while some problems originated earlier in the compiler pipeline. This distinction was important because the solution depends heavily on where the gap actually exists. For example, if Clang already has all the information needed in the AST, adding another HLSL-specific parser or compiler feature would be unnecessary. Instead, the appropriate solution may be to extend existing clangd infrastructure. Full writeup: Gap Analysis From Gaps to Solutions After identifying the gaps, I investigated possible implementation approaches for each one. For every issue, I looked at: where the relevant information was represented in Clang; how clangd currently handled similar C/C++ constructs; why the existing infrastructure did not work for HLSL; whether the problem should be fixed in Clang or clangd; and what possible implementation approaches were available. I documented these ideas before starting the implementation so the design could be discussed with my mentors and the LLVM community. Full writeup: Implementation Ideas RFC and Community Feedback After discussing the implementation ideas with my mentors, I consolidated the proposed solutions into an RFC and submitted it to the LLVM Discourse community. RFC: Improving HLSL Support in clangd The RFC described the expected behavior, the observed gap, the root cause, and the proposed solution for each issue. The discussion with the LLVM and DirectX communities was an important part of the project. Some of my initial ideas were refined based on the feedback I received. For example, semantic completion after : initially considered suggesting HLSL semantics unconditionally. The discussion highlighted that not every identifier in that context is necessarily a semantic, so the implementation was refined to make semantic suggestions dependent on the typed prefix. Another example was vector and matrix swizzle completion. The discussion raised concerns about automatically triggering completion after every . , which could become distracting during normal editing. The final implementation therefore made HLSL swizzle completion configurable. From RFC to Issues and Pull Requests After the RFC discussion, I created a separate GitHub issue for each implementation item. Each issue documented the expected behavior, the current behavior, the root cause, and the proposed solution. The 11 issues were divided into two main areas. Hover Semantic annotations such as SV_Target and SV_Position - issue #214808 / PR #217725 Loop and branch control attributes such as [unroll] and [loop] - issue #214067 / PR #214318 out and inout parameter qualifiers - issue #214071 / PR #214883 Vector swizzle and matrix element access - issue #212612 / PR #212741 RootSignature hover - issue #214790 / PR #214955 register(...) hover ranges - issue #212749 / PR #212881 Code Completion Attribute completion inside [...] - issue #214792 / PR #215353 register(...) completion - issue #214798 / Draft PR (Depend on PR not merged yet) HLSL annotations after : - issue #214801 / Draft PR (Depend on PR not merged yet) Vector swizzle completion - issue #214804 / PR #217381 Matrix swizzle completion - issue #214805 / Draft PR (Depend on PR not merged yet) Each issue was then implemented as an independent pull request, making the changes easier to review and upstream. All PRs: link Some Examples One of the most interesting parts of the project was discovering that HLSL constructs are sometimes represented internally in ways that are different from how users wrote them. For example, HLSL out and inout parameters are lowered internally to C++ reference types. Given: void ApplyFog( out float4 color, inout float depth); hovering over color previously exposed an internal representation such as float &__restrict instead of the HLSL type out float4 . The solution was to add a getHLSLParamTypeAsWritten() helper that allows clangd to recover the original HLSL type for display, independently of how the parameter is represented internally. Another example was HLSL semantic annotations. Constructs such as: float4 main() : SV_Target were already represented by Clang, but hover did not display the semantic spelling correctly. Investigating the AST showed that the necessary information existed, but the relevant HLSL attribute did not provide the spelling expected by the generic hover infrastructure. This allowed the problem to be fixed at the appropriate layer rather than by adding an HLSL-specific workaround to the hover implementation. Multiple Entry Points In addition to the original gaps, I investigated a larger architectural problem involving HLSL files containing multiple shader entry points. A single HLSL file can contain multiple entry points, for example: [shader( "vertex" )] void VSMain(...) { ... } [shader( "pixel" )] void PSMain(...) { ... } This creates a challenge for clangd, which traditionally works with a single active compilation context for a file. Different HLSL entry points can require different compilation contexts, especially in legacy HLSL, where the shader stage and entry point are specified through compiler flags rather than source annotations. Modern HLSL For modern HLSL, entry points can be annotated directly in the source, using [shader("vertex")] , [shader("pixel")] , and so on. In this case, I found that using an HLSL library target allows Clang to build a single AST containing the different entry points. I implemented a fallback for HLSL files without an available compilation command that uses the library target automatically. This provides a generic compilation context that works well for modern HLSL files containing multiple entry points. Legacy HLSL The legacy case is more difficult. When the entry point is selected through compiler flags, different entry points may require different compilation commands, and clangd cannot simply use one compilation command and expect all entry points to be represented correctly. I investigated possible approaches and built a prototype for explicitly switching the active compilation context. The prototype allows clangd to discover the entry points available in a file and switch between their compilation contexts without requiring the user to close and reopen the file. The server-side mechanism was validated end to end using LSP communication. Full writeup: Multiple Entry Point Investigation This work is not yet a complete upstream solution, but it provides a foundation for continuing the work after GSoC. Future Work The main remaining area of work is the legacy multiple-entry-point problem. The prototype still needs to be developed into an upstreamable solution and paired with client-side UX for selecting the active entry point. The investigation already provides pieces that can be reused in future work: entry-point discovery; compilation-context switching; the HLSL library-mode fallback; the investigation of clangd’s compilation database behavior; and the LSP prototype used to validate the approach. There are also smaller follow-up opportunities, such as richer RootSignature hover information, a default files.associations entry for .hlsl in vscode-clangd , and additional HLSL-specific configuration improvements. What I’ve Learned Before Google Summer of Code, I had some experience working with LLVM, but I had never worked on clangd or HLSL support. One of the most valuable things I learned was how to investigate a compiler tooling problem from the user’s perspective and trace it back to its root cause. During the project, I often had to move between different layers of the compiler, from the LSP behavior in clangd, through its AST handling, down to parsing and semantic analysis in Clang. I also learned how important it is to understand the existing architecture before implementing a fix. In several cases, the information required to support an HLSL feature was already available in Clang, and the right solution was to make existing infrastructure aware of it rather than introducing a separate HLSL-specific implementation. The upstreaming process was another major part of the learning experience. Writing an RFC, discussing design alternatives with the LLVM community, incorporating feedback, creating focused issues, and eventually submitting reviewable pull requests taught me a lot about how large open-source projects are developed. Finally, investigating multiple entry points showed me that not every problem can be solved by fixing a single missing feature. Some problems require understanding the interaction between the compiler, clangd, the compilation database, and the LSP itself. Overall, GSoC gave me much more confidence navigating a large compiler codebase, debugging problems across different layers of the compiler, and contributing changes to a project as large as LLVM. Acknowledgments I would like to thank my mentors, Finn Plummer and Ashley Coleman, for their guidance and support throughout this project. They always made time to talk to me, discuss my progress, answer my questions, and help me work through the challenges I encountered. I am grateful for all the feedback they gave on my ideas, and for taking the time to explain things, listen to my proposals, and help me find a way forward whenever I was unsure about something. Working with them was one of the most valuable parts of this experience, and I learned a great deal from the way they approached problems. I would also like to thank the LLVM and DirectX communities for the discussions and feedback on the RFC and implementation ideas. Their input was an important part of refining the proposed solutions and understanding how these features should fit into clangd’s existing architecture.The LLVM Project Blog

Sunday, September 20, 2026

Linker I/O tricks and their downsidesmold and wild enable several tricks by default that other linkers don't do. This post looks at three of them: overwrite an existing output file in place instead of creating a new file fork a child to do the link, so that the parent can exit before the child releases its memory ask the kernel for transparent huge pages Each saves a few percent of wall time in an edit-relink loop. Each also breaks an assumption that build systems, debuggers, and profilers make about a process. I measured what they save and what they break. Setup: Linux 6.18, i7-14700K (28 threads), ext4 on a SATA SSD, transparent huge pages enabled=always . GNU ld 2.47, gold 2.47, LLD 23, mold 2.42.1 (TODO: I used the Rust port under development; check against the C++ release), wild at commit 47cc8e8e.MaskRay

Saturday, September 19, 2026

Friday, September 18, 2026