# LLVM LLVM is a collection of modular and reusable compiler and toolchain technologies, including optimizer, code-generation, compiler, debugger, linker, and compiler-infrastructure projects. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Intel Compute Stack Enables LEO For Nova Lake, Introduces Intel Portable ISA "PISA" DevFeed: [Intel Compute Stack Enables LEO For Nova Lake, Introduces Intel Portable ISA "PISA"]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-17T13:05:07Z Content type: release Language: en Sources: [Phoronix]() Topics: [intel](), [Nova](), [OpenCL](), [GPU](), [Linux](), [LLVM](), [Compiler](), [parallel]() Tags: [desktop-linux](), [gpu](), [intel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [llvm](), [nova](), [open-source-graphics](), [opencl](), [phoronix](), [phoronix-test-suite](), [release](), [runtime](), [ubuntu-benchmarks](), [ubuntu-hardware](), [update]() ### AI overview Intel Compute Runtime 26.35.39758.10 adds several GPU compute features and enables the OpenCL LEO driver by default for upcoming Nova Lake S processors on Linux. The release also introduces initial support for Intel's Portable ISA (PISA) format. ### Source excerpt Released today was the Intel Compute Runtime 26.35.39758.10 update for Windows and Linux systems. With this updated OpenCL and Level Zero GPU compute driver stack comes some exciting updates for this monthly feature update... ## Bringing Correctly Rounded Math to Production with LLVM-libc DevFeed: [Bringing Correctly Rounded Math to Production with LLVM-libc]() Original publisher: [Read original article]() Author: Cody Miller, Tue Ly, Michael Jones Published: 2026-09-16T22:09:50Z Content type: article Language: en Sources: [C++ Team Blog]() Topics: [LLVM](), [Support](), [C++]() Tags: [c-plus-plus](), [compiler](), [llvm](), [msvc]() ### AI overview This guest post explains LLVM-libc's design philosophy of portability and modularity, and discusses its math functions, including their use by MSVC for compile-time evaluation and runtime execution when /Zc:cmath is enabled. ### Source excerpt As we mentioned in the last cmath blog post, MSVC is using LLVM-libc for compile-time evaluation and runtime execution of math functions when /Zc:cmath is enabled. I invited LLVM-libc contributors Michael Jones and Tue Ly to write a guest blog post about how they've achieved what they've achieved. This is that blog post! I hope [...] The post Bringing Correctly Rounded Math to Production with LLVM-libc appeared first on C++ Team Blog. ## How fast is C++23's std::flat\_map? DevFeed: [How fast is C++23's std::flat\_map?]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-16T20:26:36Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Data structures](), [Library](), [gcc](), [LLVM](), [clang]() Tags: [array](), [arrays](), [clang](), [gcc](), [llvm](), [overhead](), [speed](), [standard-library]() ### AI overview This article benchmarks C++23's std::flat_map, a sorted container backed by parallel arrays of keys and values. It explains serialization and loading considerations, then compares insertion and lookup performance with std::map. Random-order insertion becomes quadratic as the container grows, while increasing-order or bulk insertion is much faster; random lookups can also be faster for large maps because std::flat_map uses less memory. ### Source excerpt C++23 added a new type to the standard library: std::flat_map. There is also a std::flat_set and other variants, but let me focus on std::flat_map. A flat map is a sorted vector of keys next to a vector of values. A query is a binary search over the sorted keys. You need a recent standard library: ... Continue reading How fast is C++23's std::flat_map? ## lld 23 ELF changes DevFeed: [lld 23 ELF changes]() Original publisher: [Read original article]() Published: 2026-09-12T07:00:00Z Content type: release Language: en Sources: [MaskRay]() Topics: [LLVM](), [Git](), [Claude Code]() Tags: [2026](), [compression](), [linker](), [llvm](), [performance](), [release]() ### AI overview This release article summarizes changes in lld/ELF for LLVM 23.1. It reports 141 commits during the development cycle, with substantial performance work including parallelized input-file loading and mark processing, along with linker behavior and compatibility updates. ### Source excerpt LLVM 23.1 has been released. As usual, I maintain lld/ELF and as volunteer work have added some notes to https://github.com/llvm/llvm-project/blob/release/23.x/lld/docs/ReleaseNotes.rst. Like last time, I used Claude Code to summarize git log llvmorg-23-init..origin/release/23.x -- lld/ELF, excluding changes cherry-picked into 22.x (git rev-list llvmorg-23-init..llvmorg-22.1.8 -- lld), and then edited the draft. This was a busy cycle: 141 commits landed in lld/ELF between the branch point (2026-01-13) and 23.1.0-rc1 (2026-07-16), compared with 72 in the 22 cycle. Much of the increase is performance work, which I described in Recent lld/ELF performance improvements. lld 23 is the first release that ships all of it. ## Block frequency DevFeed: [Block frequency]() Original publisher: [Read original article]() Published: 2026-08-23T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM]() Tags: [algorithm](), [graph](), [llvm]() ### AI overview This article explains how LLVM turns branch probabilities into per-block frequencies through linear-time propagation over loop-structured regions. It also notes that irreducible control flow reduces accuracy. ### Source excerpt Estimating branch probabilities says how one branch splits. BlockFrequencyInfo turns those local numbers into per-block frequencies, which nearly every profitability decision in LLVM ends up reading. The core is a linear-time propagation over loop-packaged regions. Where no such structure exists -- irreducible control flow -- the accuracy goes with it. ## Estimating branch probabilities DevFeed: [Estimating branch probabilities]() Original publisher: [Read original article]() Published: 2026-08-09T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM]() Tags: [algorithm](), [analysis](), [functions](), [graph](), [llvm](), [structure]() ### AI overview This post explains how LLVM estimates branch probabilities when profile data is unavailable. It examines the heuristic that classifies control-flow blocks and successor paths using unreachable, cold, unwinding, and loop information, and presents a standalone reimplementation. ### Source excerpt LLVM's BranchProbabilityInfo assigns every multi-successor terminator a probability distribution over its successors. This post describes the estimation used when no profile is available and reimplements it as a standalone program. ## BSDCan 2026 Trip Report - ShengYi Hung DevFeed: [BSDCan 2026 Trip Report - ShengYi Hung]() Original publisher: [Read original article]() Author: Florine Kamdem Published: 2026-07-22T05:40:54Z Content type: article Language: en Sources: [FreeBSD Foundation]() Topics: [freebsd](), [scheduling](), [cpu](), [LLVM]() Tags: [blog](), [conference](), [developers](), [report]() ### AI overview A personal report on attending BSDCan 2026 in Ottawa, including DevSummit discussions about AI and project maintainability, FreeBSD development work, heterogeneous CPU scheduling, CPU power throttling, and Thread Local Storage. ### Source excerpt I'm really grateful to the FreeBSD Foundation for sponsoring my trip to BSDCan 2026 in Ottawa. The conference ran for four days -- two days of DevSummit, then two days of the main conference, with many interesting talks throughout. For me, it's mainly a chance to talk with developers I don't otherwise get to reach [...] The post BSDCan 2026 Trip Report - ShengYi Hung first appeared on FreeBSD Foundation. ## LLVM Analysis of the Differences Between AMD GFX1250 and GFX1251 DevFeed: [LLVM Analysis of the Differences Between AMD GFX1250 and GFX1251]() Original publisher: [Read original article]() Author: George Cozma Published: 2026-07-20T09:23:59Z Content type: article Language: en Sources: [Chips and Cheese]() Topics: [LLVM](), [Compiler](), [Hardware]() Tags: [compiler](), [hardware](), [llvm](), [math](), [memory](), [vector]() ### AI overview The article examines LLVM target descriptions for AMD GFX1250 and GFX1251, identifying their shared GFX12.5 features and differences. It focuses on GFX1251's improved 64-bit execution, packed FP64 and U64 instructions, and the compiler cost model's support for those operations. ### Source excerpt Hello you fine Internet folks, this article is a sequel to the Scrying the AMD GFX1250 LLVM Tea Leaves article where we are going to look at the differences between GFX1250 and GFX1251. ## Announcing Rust 1.97.1 DevFeed: [Announcing Rust 1.97.1]() Original publisher: [Read original article]() Author: The Rust Release Team Published: 2026-07-16T00:00:00Z Content type: release Language: en Sources: [Rust Blog]() Topics: [Rust](), [releases](), [LLVM](), [Optimization](), [Programming language](), [Beta channel](), [ci]() Tags: [beta-channel](), [bugs](), [ci](), [llvm](), [optimization](), [programming-language](), [release](), [releases](), [rust](), [update]() ### AI overview Rust 1.97.1 is a point release that fixes a miscompilation related to an LLVM optimization. The release backports an LLVM fix and disables the underlying change in Rust 1.97.0 that increased the likelihood of the issue. ### Source excerpt The Rust team has published a new point release of Rust, 1.97.1. Rust is a programming language that is empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via rustup, getting Rust 1.97.1 is as easy as: rustup update stable If you don't have it already, you can get rustup from the appropriate page on our website. What's in 1.97.1 Rust 1.97.1 fixes a miscompilation in an LLVM optimization. We have backported both an LLVM fix and a disable of the underlying change in Rust 1.97.0 of Rust's generated IR that increased the likelihood of this happening. However, note that the underlying miscompilation has been present since at least Rust 1.87. If you'd like to help us out by testing future releases, you might consider running your code's CI or locally using the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across! Contributors to 1.97.1 Many people came together to create Rust 1.97.1. We couldn't have done it without all of you. Thanks! ## Optimizing LLVM's bump allocator DevFeed: [Optimizing LLVM's bump allocator]() Original publisher: [Read original article]() Published: 2026-06-28T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [clang]() Tags: [changes](), [clang](), [codegen](), [debug](), [llvm](), [memory](), [optimizing](), [performance]() ### AI overview This article explains three recent changes that optimize LLVM's BumpPtrAllocator: avoiding unnecessary realignment, using a sentinel to eliminate a null check, and removing per-allocation accounting from the hot path. It also discusses alignment, typed allocation, incomplete types, and ABI considerations. ### Source excerpt BumpPtrAllocator is LLVM's bump allocator (arena allocator): each allocation bumps a pointer within a slab, and everything is freed at once when the allocator dies. It backs Clang's ASTContext, lld's make object pools, TableGen records, and many other arenas. Here is the fast path before three recent changes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 __attribute__((returns_nonnull)) void *Allocate(size_t Size, Align Alignment) { BytesAllocated += Size; // (3) accounting RMW uintptr_t AlignedPtr = alignAddr(CurPtr, Alignment); // (1) always realign size_t SizeToAllocate = Size; #if LLVM_ADDRESS_SANITIZER_BUILD SizeToAllocate += RedZoneSize; #endif uintptr_t AllocEndPtr = AlignedPtr + SizeToAllocate; if (LLVM_LIKELY(AllocEndPtr <= uintptr_t(End) && CurPtr != nullptr)) { // (2) bound + null check CurPtr = reinterpret_cast(AllocEndPtr); ... return reinterpret_cast(AlignedPtr); } return AllocateSlow(Size, SizeToAllocate, Alignment); } ## A deep dive into SmallVector::push\_back DevFeed: [A deep dive into SmallVector::push\_back]() Original publisher: [Read original article]() Published: 2026-06-27T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Optimization](), [Compiler](), [clang](), [Assembly](), [gcc]() Tags: [assembly](), [clang](), [codegen](), [compiler](), [gcc](), [llvm](), [optimization](), [performance]() ### AI overview This article examines an LLVM SmallVector::push_back optimization for approximately trivially copyable element types. It explains how tail-calling the slow growth path reduces the fast path from 14 to 7 instructions and avoids callee-saved registers, while noting tradeoffs for out-of-line calls and overall build size. ### Source excerpt tl;dr This blog post describes a recent SmallVector::push_back optimization for approximately trivially copyable element types. SmallVector is LLVM's most-used container, and push_back its hot operation. For the trivially-copyable specialization the fast path should be fast. 1 2 3 #include void f(llvm::SmallVectorImpl &v, int x) { v.push_back(x); } clang -S --target=x86_64 -O2 -DNDEBUG a.cc generates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 push rbp # callee-saved spills + a stack realignment, push rbx # all on the fast path push rax mov eax, [rdi + 8] # size cmp eax, [rdi + 12] # vs capacity jae .Lgrow .Lstore: # reached from the fast path AND from .Lgrow mov rcx, [rdi] mov [rcx + rax*4], esi inc dword ptr [rdi + 8] add rsp, 8 pop rbx pop rbp ret .Lgrow: mov rbx, rdi # keep `this`/`x` alive across the call mov ebp, esi call SmallVectorBase::grow_pod ... jmp .Lstore ## LLVM and How It Changed the Way We Write and Compile Code DevFeed: [LLVM and How It Changed the Way We Write and Compile Code]() Original publisher: [Read original article]() Published: 2026-06-22T00:00:00Z Content type: article Language: en Sources: [Kt. Academy]() Topics: [LLVM](), [Programming](), [Code]() Tags: [code](), [llvm](), [programming](), [workshop-learning-programming]() ### AI overview The article explains what LLVM is and how it changed the way developers write and compile code. ### Source excerpt What is LLVM and how it revolutionized the way we write and compile code. ## Recent LLVM hash table improvements DevFeed: [Recent LLVM hash table improvements]() Original publisher: [Read original article]() Published: 2026-06-07T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [hash](), [Algorithms](), [benchmarking]() Tags: [algorithm](), [compiler](), [data-structures](), [hash](), [improvements](), [llvm](), [performance]() ### AI overview The article reviews recent improvements to LLVM hash tables, including replacing quadratic probing and tombstone or empty-key sentinels with linear probing, Algorithm R deletion, and bit-array occupancy. It also discusses pointer and iterator invalidation behavior and reports performance improvements in DenseMap. ### Source excerpt LLVM has several hash tables. They used quadratic probing with in-band sentinel keys (empty, tombstone); recent work has been replacing that with linear probing with tombstone key removed. DenseMap (replacement for std::unordered_map): DenseMapInfo::getEmptyKey() / getTombstoneKey(). DenseSet: implemented using DenseMap compiler-rt/lib/sanitizer_common/sanitizer_dense_map.h ports the implementation for sanitizers. SmallPtrSet (replacement for std::unordered_set): hard-coded -1 (empty) and -2 (tombstone). StringMap (replacement for std::unordered_map) StringSet: implemented using StringMap FoldingSet (uniquing/hash-consing container, not a general map) For the open-addressed DenseMap and SmallPtrSet, pointers, references, and iterators are invalidated by insert. StringMap is different: each entry lives in a heap-allocated StringMapEntry node, so entry pointers survive grow. std::unordered_map, being node-based, keeps surviving-element pointers valid across both insert and erase and only invalidates the erased element's own iterator. LLVM code rarely needs that stronger contract -- callers do not hold long-lived references into the container across mutation -- and that gap is what gives pass to relocating erase and bit-array occupancy. Recently, Tombstones have been removed from DenseMap and SmallPtrSet. erase() also invalidates pointers. DenseMap has also retired its empty-key sentinel, leading to significant performance improvements. DenseMap with integer keys (int/unsigned/size_t) had -1/-2 reserved -- a footgun, now fixed. StringMap got Algorithm R deletion too. Its entries are separately heap-allocated, so erase keeps entry pointers valid but invalidates iterators; erase-while-iterating moved to remove_if. FoldingSet dropped chaining for linear probing plus Algorithm R; the intrusive next-in-bucket pointer became a cached 32-bit hash. ## Fighting Hyrum's Law in LLVM DevFeed: [Fighting Hyrum's Law in LLVM]() Original publisher: [Read original article]() Published: 2026-05-10T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Compiler](), [reproducible builds](), [hash]() Tags: [clang](), [compiler](), [hash](), [lld](), [llvm](), [reproducible-builds](), [test]() ### AI overview This article examines how LLVM can develop dependencies on unspecified or incidental behavior under Hyrum's Law, causing output variation that harms reproducible builds, bisection, and bug reports. It describes hash-seed perturbation, reverse container iteration, and iterator invalidation checks as mechanisms for exposing such dependencies. ### Source excerpt With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law In a compiler, the most common form of Hyrum's Law is dependence on unspecified behavior -- hash bucket order, the order of equal elements after std::sort, padding offsets. The same framing covers a few cases that are technically undefined behavior (use of an invalidated iterator) or plain incidental properties (ABI struct layout, ELF section offsets). When the compiler itself harbors such a dependency, the symptom is usually output that varies build-to-build: an unstable sort that lands differently after the standard library changes, a hash map whose iteration order shifts when the hash function does. Occasionally the variation is run-to-run within a single build -- DenseMap keys with an ASLR-derived seed reorder buckets each invocation. Either way, reproducible builds, bisection, and bug reports all assume same input -> same output, and a stealth Hyrum dependency breaks that. This post surveys some mechanisms that perturb the contract's blind spots so dependencies cannot quietly form. ## OpenCL Cooperative Matrix Extensions Are Here DevFeed: [OpenCL Cooperative Matrix Extensions Are Here]() Original publisher: [Read original article]() Author: jphilips (jeff@khronosgroup.org) Published: 2026-04-29T13:00:00Z Content type: release Language: en Sources: [Blogs Khronos Blog]() Topics: [AI Inference](), [GPU](), [C](), [LLVM](), [GitHub]() Tags: [api](), [arm](), [blog-opencl-spirv-machinelearning-llv](), [c](), [gpu](), [intel](), [llvm](), [opencl](), [qualcomm](), [spir](), [vulkan]() ### AI overview The OpenCL Working Group has published a working draft of the cl_khr_cooperative_matrix extension, developed with Arm, Intel, and Qualcomm. The extension brings cooperative matrix operations for ML inference to OpenCL, while a companion OpenCL C extension is also being developed. Community feedback is requested before the standards are finalized. ### Source excerpt The OpenCL Working Group has published a draft extension (cl_khr_cooperative_matrix) that brings cooperative matrix operations--a key technology for accelerating ML inference--to OpenCL, developed in collaboration with Arm, Intel, and Qualcomm. A companion extension to expose these capabilities directly in the OpenCL C language is also in progress, and the community is invited to review both drafts and provide feedback before they are finalized. ## Recent lld/ELF performance improvements DevFeed: [Recent lld/ELF performance improvements]() Original publisher: [Read original article]() Published: 2026-04-12T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Benchmark](), [benchmarking](), [clang](), [Chromium]() Tags: [2026](), [benchmark](), [chromium](), [clang](), [gc](), [gdb](), [improvements](), [linker](), [lld](), [llvm](), [macos](), [overhead](), [patches](), [performance]() ### AI overview This article reports LLVM lld/ELF linker performance improvements from parallelizing link phases and reducing task-runtime overhead. Benchmarks show a 1.34x speedup over lld 22.1 for a Release+Asserts clang link and a 1.09x speedup for a Chromium debug link, while mold and wild remain faster in the comparisons described. ### Source excerpt Updated in 2026-05. Since the LLVM 22 branch was cut, I've landed patches that parallelize more link phases and cut task-runtime overhead. This post compares current main against lld 22.1, mold, and wild. Headline: a Release+Asserts clang --gc-sections link is 1.34x as fast as lld 22.1; Chromium debug with --gdb-index is 1.09x as fast. mold and wild are still ahead -- the last section explains why. ## ClickHouse at FOSDEM 2026 DevFeed: [ClickHouse at FOSDEM 2026]() Original publisher: [Read original article]() Author: Tyler Hannan Published: 2026-04-08T18:00:47Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [data-processing](), [real-time](), [debugging](), [LLVM](), [log management](), [Shell](), [SQL](), [dashboards](), [observability](), [Parser](), [Tooling]() Tags: [bugs](), [clickhouse](), [community](), [conference](), [data](), [debugging](), [llvm](), [logging](), [performance](), [real-time](), [sql](), [visualization]() ### AI overview ClickHouse at FOSDEM 2026 recaps the ClickHouse community dinner and technical talks on real-time visualization, production hotpatching with LLVM XRay, and inverted database indexes. ### Source excerpt FOSDEM 2026 took place on 31 January and 1 February in Brussels, and it was a great weekend for the ClickHouse community, both inside the conference rooms and out. ## Supercharging Redpanda Streaming with profile-guided optimization DevFeed: [Supercharging Redpanda Streaming with profile-guided optimization]() Original publisher: [Read original article]() Author: Stephan Dollberg Published: 2026-04-02T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Optimization](), [Streaming](), [Latency](), [Compiler](), [LLVM](), [Instrumentation](), [build performance](), [Benchmark]() Tags: [benchmark](), [bugs](), [compilation](), [engineering](), [instrumentation](), [latency](), [llvm](), [meta](), [optimization](), [performance](), [profile](), [profiling]() ### AI overview This article describes how Redpanda optimized its binary for Redpanda Streaming 26.1 using compiler-based profile-guided optimization (PGO) and LLVM BOLT. It explains how profiling data guides optimization decisions, compares the two approaches, and reports lower latency and CPU usage for intensive workloads. ### Source excerpt A behind-the-scenes look into how we optimized performance and cut latency in Redpanda 26.1 with profile-guided optimization. ## Bit-field layout DevFeed: [Bit-field layout]() Original publisher: [Read original article]() Published: 2026-02-22T08:00:00Z Content type: tutorial Language: en Sources: [MaskRay]() Topics: [implementation](), [C](), [C++](), [Compiler](), [clang](), [gcc](), [LLVM](), [MSVC]() Tags: [c](), [c-plus-plus](), [clang](), [codegen](), [compiler](), [compiler-optimization](), [gcc](), [implementation](), [llvm](), [msvc]() ### AI overview This article explains how C and C++ bit-field layout is implementation-defined and governed primarily by platform ABIs. It distinguishes ABI-defined storage layout from compiler code generation, focusing on the Itanium ABI and describing differences in the Microsoft ABI. ### Source excerpt The C and C++ standards leave nearly every detail to the implementation. C23 §6.7.3.2: An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified C++ is also terse -- [class.bit]p1: Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. ## lld 22 ELF changes DevFeed: [lld 22 ELF changes]() Original publisher: [Read original article]() Published: 2026-02-01T08:00:00Z Content type: release Language: en Sources: [MaskRay]() Topics: [LLVM](), [releases](), [Release notes](), [Claude Code](), [Large Language Model]() Tags: [claude-code](), [compiler](), [git](), [linker](), [lld](), [llm](), [llvm](), [release](), [release-notes](), [releases]() ### AI overview An LLVM lld/ELF maintainer summarizes changes planned for LLVM 22.1, including linker behavior updates, parsing improvements, relocation support, partitioning changes, and architecture-specific fixes. The author also describes using Claude Code to review commits and draft release notes. ### Source excerpt For those unfamiliar, lld is the LLVM linker, supporting PE/COFF, ELF, Mach-O, and WebAssembly ports. These object file formats differ significantly, and each port must follow the conventions of the platform's system linker. As a result, the ports share limited code (diagnostics, memory allocation, etc) and have largely separate reviewer groups. With LLVM 22.1 releasing soon, I've added some notes to the https://github.com/llvm/llvm-project/blob/release/22.x/lld/docs/ReleaseNotes.rst as an lld/ELF maintainer. As usual, I've reviewed almost all the patches not authored by me. For the first time, I used an LLM agent (Claude Code) to help look through commits (git log release/21.x..release/22.x -- lld/ELF) and draft the release notes. Despite my request to only read lld/ELF changes, Claude Code also crafted notes for other ports, which I retained since their release notes had been quite sparse for several releases. Changes back ported to the 21.x release are removed (git log --oneline llvmorg-22-init..llvmorg-21.1.8 -- lld). I'll delve into some of the key changes. ## Unsigned char std::basic\_string\<\> in C++ DevFeed: [Unsigned char std::basic\_string\<\> in C++]() Original publisher: [Read original article]() Published: 2026-01-03T22:00:02Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C++](), [standard](), [LLVM](), [clang](), [gcc]() Tags: [bits](), [c-plus-plus](), [clang](), [concatenation](), [cryptographic](), [freebsd](), [gcc](), [llvm](), [openbsd](), [standard](), [string]() ### AI overview A C++ post explains why code using std::basic_string can fail on FreeBSD and OpenBSD. The issue involves std::char_traits: LLVM 19 removed its unconstrained base template because the C++ Standard does not require it for unsigned-character types. Code may need string concatenation and related operations replaced or a correct custom specialization provided. ### Source excerpt Brief post on a somewhat vexing and irritating C++ problem I ran into some time ago. I hope that this page will help other people deal with this problem more quickly than I did. I've long used std::basic_string, an unsigned char string, for fiddling with bits. You could use a regular char string, but especially when doing cryptographic or sub-byte operations, it is more convenient to not have to deal with sign bits. ## 2025年总结 DevFeed: [2025年总结]() Original publisher: [Read original article]() Published: 2025-12-31T08:00:00Z Content type: article Language: zh Sources: [MaskRay]() Topics: [toolchain](), [LLVM](), [patches](), [Linux]() Tags: [assembler](), [blogging](), [bugs](), [https-maskray-me-blog-tags-assembler](), [linux](), [llvm](), [patches](), [summary]() ### AI overview A 2025 personal summary covering reduced open-source involvement, 18 blog posts, work on LLVM's integrated assembler and ELF specifications, Linux kernel contributions, ccls, binutils reports, and travel. ### Source excerpt TODO 一如既往，主要在工具链领域耕耘。但由于工作忙碌在open source社区投入的时间减少了。 Blogging 不包括这篇总结，一共写了18篇文章。 ## Java Hello World, LLVM Edition DevFeed: [Java Hello World, LLVM Edition]() Original publisher: [Read original article]() Author: James Hamilton Published: 2025-12-07T02:02:37Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Java](), [LLVM](), [API](), [JIT]() Tags: [2025](), [api](), [assembly](), [bytecode](), [compilers](), [java](), [java-advent](), [jdk](), [jit](), [jvm](), [llvm]() ### AI overview This tutorial shows how to use Java's Foreign Function & Memory API to call the LLVM C API, generate LLVM IR for a Hello World program, and JIT-compile it to native code. It also introduces LLVM, its IR representations, and local installation on Ubuntu or Debian. ### Source excerpt After exploring Java bytecode in previous years (2022, 2023, 2024), this year we'll take an unexpected detour for a Java advent: instead of generating Java bytecode, we'll use Java to build and execute LLVM IR, the intermediate language behind compilers like clang. Using Java's Foreign Function & Memory (FFM) API, we'll call the LLVM C [...] The post Java Hello World, LLVM Edition appeared first on JVM Advent. ## Stack walking: space and time trade-offs DevFeed: [Stack walking: space and time trade-offs]() Original publisher: [Read original article]() Published: 2025-10-26T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Linux](), [C++]() Tags: [article](), [gcc](), [linux](), [llvm](), [performance-analysis](), [platforms](), [required](), [sframe](), [update]() ### AI overview This article examines space and time trade-offs among stack-walking mechanisms on Linux, including DWARF, frame pointers, SFrame, LLVM's Compact Unwinding Format, Last Branch Record, and CET Shadow Stack. It analyzes the size overhead of enabling non-DWARF mechanisms when building LLVM executables; runtime performance analysis is deferred to a future update. ### Source excerpt On most Linux platforms (except AArch32, which uses .ARM.exidx), DWARF .eh_frame is required for C++ exception handling and stack unwinding to restore callee-saved registers. While .eh_frame can be used for call trace recording, it is often criticized for its runtime overhead. As an alternative, developers can enable frame pointers, or adopt SFrame, a newer format designed specifically for profiling. This article examines the size overhead of enabling non-DWARF stack walking mechanisms when building several LLVM executables. Runtime performance analysis will be added in a future update. [Next page]()