In 2020, reviewing lld's --optimize-bb-jumps (reviews.llvm.org/D68065), I asked that the pass run inside finalizeAddressDependentContent "to accommodate thunks and linker script symbol changes." The author replied: "Could we do this in a later patch?" There was no later patch.
1
0
12
1,198
and another lld maintainer independently flagged the misplacement and found my 2020 comment.
When I left Google in 2024, --optimize-bb-jumps still had no users. The answer was always "we will use it." Today nothing in llvm-project passes the flag; only three lld tests do.
When I left Google in 2024, --optimize-bb-jumps still had no users. The answer was always "we will use it." Today nothing in llvm-project passes the flag; only three lld tests do.
1
0
3
273
Google's requirements have drifted away from the already very broad range that lld, and llvm-project at large, serves. A feature only one company's internal pipeline might need should prove itself there before it lands upstream, where everyone maintains it.
0
0
2
143
That placement was a wrong-code bug from day one: the pass shrinks .text after .relr.dyn is computed, so RELR entries point at the wrong words.
Since a change this year, .eh_frame_hdr search keys go stale too.
An AI-assisted patch surfaced it recently,
Since a change this year, .eh_frame_hdr search keys go stale too.
An AI-assisted patch surfaced it recently,
2
0
2
316
I was junior; he was far more senior. Landing a feature on a promise of future use, and deferring the reviewer's design concern to "a later patch", is not how open source should work.
0
0
1
71
maskray.me/blog/who-pays-… Who pays for Clang
Another AI slop post. Commits by employer, What each funder works on, Review, Shared and vendor-specific work
Another AI slop post. Commits by employer, What each funder works on, Review, Shared and vendor-specific work
1
1
22
1,970
I spent many hours driving the agent through Discourse threads, slides, source trees, and LinkedIn profiles to generate this AI slop: maskray.me/blog/clangir-a… ClangIR and the cost of MLIR
2
12
68
5,440
Comment on "RFC: Enable ClangIR Build By Default-" discourse.llvm.org/t/rfc-enable-c… Current feeling: it might be a huge opportunity cost
0
0
0
115
The new funders build GPU and accelerator compilers, and their other compilers (Flang, Triton, IREE, their own stacks) are built on MLIR. For them, a Clang that emits an MLIR dialect is the point, not an implementation detail.
1
0
8
642
For C++ programmers who were Clang's main constituency, CIR has to earn its place by being better at what the AST, the CFG, and classic CodeGen do today: diagnostics, safety analyses, and optimizations that need C++ semantics, without making the compiler slower to build or run
0
0
5
561
github.com/MaskRay/ccls/r…
Indexed forwarding functions such as std::make_unique<A>(...) and std::vector<A>::emplace_back(...).
Hover on an auto variable in a function template shows the deduced type when the template has exactly one instantiation.
Adapt to LLVM 22, 23 and 24.
Indexed forwarding functions such as std::make_unique<A>(...) and std::vector<A>::emplace_back(...).
Hover on an auto variable in a function template shows the deduced type when the template has exactly one instantiation.
Adapt to LLVM 22, 23 and 24.
0
1
8
674
edgls is a C/C++ language server built on the EDG C/C++ front end. It is a fork of ccls with the clang-based parts replaced: the indexer, diagnostics, compile command handling, code completion, signature help, and formatting. github.com/MaskRay/edgls
Verdict: Slower than clang
Verdict: Slower than clang
2
5
63
3,584
Settling an old score: --fortran-common (added in 2020) was removed from lld/ELF in September 2026, removing one blocker of fully parallel input file parsing and symbol resolution.
1
0
10
1,268
Credit where it's due - I'm glad I could connect with the original author six years later. For features added today, I doubt maintainers in one year will be as lucky in finding the original authors.
0
0
1
203
I made a typo earlier and wrote 'useful' instead of 'useless' regarding the 'testsuite must pass' requirement. The author agreed without question. Their other replies are almost direct copy pastes.
0
0
3
730
Extractive patches from a new contributor to llvm binary tuilities.
"But it's Codex output the author doesn't really own, so reviewers end up supplying the understanding."
llvm-project really should really adopt a ghostty-style vouch system.
"But it's Codex output the author doesn't really own, so reviewers end up supplying the understanding."
llvm-project really should really adopt a ghostty-style vouch system.
1
2
13
1,923
There is finally a migration path for LLVM's llvm::cl::opt, off dynamic initialization and onto a data-only TableGen representation: one struct per library, constant-initialized, read with a single load. No option spellings change. discourse.llvm.org/t/rfc-declare-…
2
2
34
2,418
`# RUN: llvm-dwarfdump --debug-names %t.bolt FileCheck --check-prefix=POSTCHECK %s`
It passed even if the pipe `|` was missing: llvm::cl:: parsed --check-prefix as grouped -c -h…, hit -h, printed --help, exit 0. FileCheck never ran.
No "Unknown command line argument" error.
It passed even if the pipe `|` was missing: llvm::cl:: parsed --check-prefix as grouped -c -h…, hit -h, printed --help, exit 0. FileCheck never ran.
No "Unknown command line argument" error.
0
0
11
754
An llvm-project contributor whose AI-assisted PRs had all needed heavy pushback just sent a good one: small diff, tests that fail without the fix, no padding. Approved.
2
1
45
6,679