# lld

Published articles for lld.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Fighting Hyrum's Law in LLVM

DevFeed: [Fighting Hyrum's Law in LLVM](<https://devfeed.tech/articles/fighting-hyrum-s-law-in-llvm-31128.md>)

Original publisher: [Read original article](<https://maskray.me/blog/fighting-hyrums-law-in-llvm>)

Published: 2026-05-10T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [reproducible builds](<https://devfeed.tech/topics/reproducible-builds.md>), [hash](<https://devfeed.tech/topics/hash.md>)

Tags: [clang](<https://devfeed.tech/tags/clang.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [hash](<https://devfeed.tech/tags/hash.md>), [lld](<https://devfeed.tech/tags/lld.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [reproducible-builds](<https://devfeed.tech/tags/reproducible-builds.md>), [test](<https://devfeed.tech/tags/test.md>)

### 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<void *, X> 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.

## Recent lld/ELF performance improvements

DevFeed: [Recent lld/ELF performance improvements](<https://devfeed.tech/articles/recent-lld-elf-performance-improvements-31121.md>)

Original publisher: [Read original article](<https://maskray.me/blog/2026-04-12-recent-lld-elf-performance-improvements>)

Published: 2026-04-12T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [clang](<https://devfeed.tech/tags/clang.md>), [gc](<https://devfeed.tech/tags/gc.md>), [gdb](<https://devfeed.tech/tags/gdb.md>), [improvements](<https://devfeed.tech/tags/improvements.md>), [linker](<https://devfeed.tech/tags/linker.md>), [lld](<https://devfeed.tech/tags/lld.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [macos](<https://devfeed.tech/tags/macos.md>), [overhead](<https://devfeed.tech/tags/overhead.md>), [patches](<https://devfeed.tech/tags/patches.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### 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.

## lld 22 ELF changes

DevFeed: [lld 22 ELF changes](<https://devfeed.tech/articles/lld-22-elf-changes-31131.md>)

Original publisher: [Read original article](<https://maskray.me/blog/lld-22-elf-changes>)

Published: 2026-02-01T08:00:00Z

Content type: release

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [releases](<https://devfeed.tech/topics/releases.md>), [Release notes](<https://devfeed.tech/topics/release-notes.md>), [Claude Code](<https://devfeed.tech/topics/claude-code.md>), [Large Language Model](<https://devfeed.tech/topics/llm.md>)

Tags: [claude-code](<https://devfeed.tech/tags/claude-code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [git](<https://devfeed.tech/tags/git.md>), [linker](<https://devfeed.tech/tags/linker.md>), [lld](<https://devfeed.tech/tags/lld.md>), [llm](<https://devfeed.tech/tags/llm.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [release](<https://devfeed.tech/tags/release.md>), [release-notes](<https://devfeed.tech/tags/release-notes.md>), [releases](<https://devfeed.tech/tags/releases.md>)

### 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.