https://maskray.me/blog/2026-06-27-a-deep-dive-into-smallvector-push-back "A deep dive into SmallVector::push_back".
SmallVector::push_back optimization has made clang faster.
Remote
meowray
@meowray@hachyderm.io
mastodon 4.7.30 Followers
0 Following
17 Posts
Joined November 18, 2022
Website:
https://maskray.me/blog/2026-02-22-bit-field-layout Bit-field layout
Quality, Velocity, Open Contribution — pick two. If you try for all three, you get none — the maintainers burn out, the project becomes unsustainable.
Lua and SQLite picked quality, and dropped both velocity and open contribution.
When your project is mature enough, you can afford to.
For a project like LLVM, open contribution is not optional — so you're really choosing between quality and velocity.
LLM-aided development dramatically increases contribution volume without increasing reviewer capacity.
LLM-aided review may help at the margins — catching mechanical issues, summarizing patches — but the core bottleneck is human judgment.
Asked Claude Code silly questions 'What's the code review style of XXX?'. Still not sure how well it actually performs reviews in someone's style, but the responses are fascinating. https://gist.github.com/MaskRay/9ebed65d9b9056bc6519001b237fdaa7
The binutils sframe maintainer has changed their email address.
https://sourceware.org/pipermail/binutils/2026-March/
Meanwhile, I heard that the person who pushed for llvm sframe has left Google.
While I am suspicious of SFrame' long-term maintenance, IBM is doubling down on SFrame by adding a PowerPC port alongside s390x -- a strange move.
I strongly recommend that anyone proposing a new unwind format for the Linux kernel take the time to rethink and refine the design.
---
On SFrame v3:
Cherry-picking a large number of patches right before the binutils 2.46 release effectively introduces insufficiently validated changes during the stabilization period of the release branch. More critically, rushing v3 in may have foreclosed improvements that community feedback could have delivered before the format was finalized.
Replying to
@thakis@serenityos.social Thanks for the suggestion! I shall also mention volatile bit-field behavior and how to write portable bit-field code.
https://github.com/llvm/llvm-project/pull/180912 "[LLD][ELF][RISCV] Support big-endian RISC-V linking" This reminds me of Linus Torvalds's
https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06 "New endianness problems are somebody ELSES problem"
https://maskray.me/blog/2026-02-01-lld-22-elf-changes lld 22 ELF changes
highlights: Distributed ThinLTO, Pointer Field Protection, RISC-V vendor relocations
Both my browser and I forgot the IP address for thakis's llvm build bot. OK, agents are good.
Replying to
All rivers flow to the sea — and flow they shall. Some comrades believe we should only feed the model clean, elegant code, and never feed it legacy garbage. This view betrays a fundamental misunderstanding of the data flywheel doctrine. Purely nonsensical gibberish, of course, shall not be fed. But when garbage does not present itself as garbage — when it arrives dressed in the respectable garb of "reviewed, production-grade code" — then we have no choice but to let it be fed, for only thus can the model learn to distinguish signal from noise, and generalize accordingly.
In every repository grow two kinds of things: elegant implementations, and technical debt. Technical debt must be paid year after year, several times a year. You say we should feed only the finest code and never touch the legacy swamps? That is the same as asking the model to graduate from textbooks without ever setting foot on a battlefield. Say what you will — anyone who has survived a production environment knows that as long as you don't refactor, the swamp is always there, just as deep as before.
Technical debt has one virtue: turned over, it becomes training data. Useless, you say? We say: transmute the base into the sublime. Programmers must wage war against legacy code year after year; our large language models must likewise crawl through that same swamp year after year. A model that can actually do the job is a model that was forged in the swamp. You ship the debt; the model learns the lesson. This contradiction will never cease to appear. Legacy code will exist for ten thousand years — and so we must be prepared to keep feeding for ten thousand years.
Last year was a turbulent year: the big labs cast their lines and handed out free credits to maintainers; the maintainers, deeply moved by such generosity, rushed forward to offer themselves up. This year remains equally turbulent, and more fine code must continue to emerge from its repositories. Comrades are encouraged to respond with enthusiasm.
After all: every line of code you write today is training data for the model that will replace you tomorrow. This is what the ancients meant by: all rivers flow to the sea — enter the weights, smiling.
Revised https://maskray.me/blog/2025-08-24-understanding-alignment-from-source-to-object-file on LLVM's recent .prefalign change. Filed a GNU Assembler feature request https://sourceware.org/bugzilla/show_bug.cgi?id=33943 ("gas: .prefalign directive for body-size-dependent function alignment") and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124314 ("Emit .prefalign for body-size-dependent function alignment")
https://maskray.me/blog/2026-02-16-call-relocation-types Call relocation types
Some architectures use two ELF relocation types for a call instruction: (x86, m68k, s390(x), etc)
claudes-c-compiler禁用了RISC-V assembler relaxation，但没有发现真实原因是没有采用fragment-based设计。
16-bit x86没有弄对看上去是训练样本太少。
我在lld/ELF和blog里提了这个不准确的术语"absolute relocation"太多次好像误导了它。
它能处理asm goto还是挺惊人的。
Interesting ld.so optimization: When a dynamic relocation references a defined symbol, get the hash from the GNU hash table. DT_GNU_HASH only stores 31 bits (the LSB is cleared for chain termination). The missing bit can be recovered https://openwall.com/lists/musl/2026/02/03/3
Updated my https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
Replying to
@boomanaiden154@hachyderm.io @shafik@hachyderm.io @chandlerc@hachyderm.io Yeah, Chandler is describing what *should* happen; these comments describe what *does* happen due to human nature (generative work is more rewarding than evaluative work), institutional incentives (companies fund engineers to land features, not review other companies' patches), and asymmetry of LLM-aided development (agents can generate patches but cannot replace the trust and judgment required for review).
The trilemma describes where we end up if we don't actively fight it.
Replying to
@lenary@types.pl Do you mean intra-function jump relocation types vs call relocation types? I should probably be more explicit that this blog post only discusses call relocation types.