Oh, joy, clang-format 22 has compounded an existing bug where AllowShortBlocksOnASingleLine: Empty didn't work by applying the AllowShortBlocksOnASingleLine setting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn.
Was made aware that we have some long-standing miscompiles in #LLVM due to fundamental design issues. Fixing them is very very hard, and it doesn't look like anyone is tackling them at the moment :(
Bad codegen for comparing struct of two 16bit ints, https://github.com/rust-lang/rust/issues/140167.
Excellent discussions about a simple problem in appearance: Comparing a struct with two `u16` could be achieved by comparing one `u32` (bits concatenation of both `u16`, both should be loaded in the same register). Turns out, despite being a nice optimisation, it’s rather complex!
Edit: it also works with `i16` and `i32` of course.
Well after quite some months a new release has landed on main branch with git commit: https://codeberg.org/stagex/stagex/commit/f33076ccbcf484eee52cc6994a96dfa89a607b8c
With this release #StageX brings more freedom to everybody by using `natively` #llvm to build the complete tree (full source #bootstrapped and #reproducible as always), initializing the era of cross-compiling "easily" for any other CPU architecture.If that doesn't excites you, then get prepared for other even better things coming into the next release!
See you at #FOSSDEM26 for stickers!
I fixed x86 tail calls in LLVM
https://github.com/llvm/llvm-project/pull/168956
Tail calls passing structs had been broken since forever, and it made me mad enough to write C++.
It's a little tricky because sometimes it requires shuffling values around on the stack and you have to make sure to not overwrite values you'll need later. This was fixed in the arm backend a while ago, and I was able to port that approach to the x86 backend. The plan is to include this in LLVM 22.
Together with some other changes it seems like guaranteed tail calls in rust might actually, finally happen.
I fixed x86 tail calls in LLVM
https://github.com/llvm/llvm-project/pull/168956
Tail calls passing structs had been broken since forever, and it made me mad enough to write C++.
It's a little tricky because sometimes it requires shuffling values around on the stack and you have to make sure to not overwrite values you'll need later. This was fixed in the arm backend a while ago, and I was able to port that approach to the x86 backend. The plan is to include this in LLVM 22.
Together with some other changes it seems like guaranteed tail calls in rust might actually, finally happen.
The adler32 checksum algorithm introduces a (seemingly useless) multiplication by 1 so that it can use a VPMADDWD widening multiply + add instruction.
After a recent change to stdarch, the multiplication got optimized out before that instruction could be selected, leading to much worse performance.
So I added some logic that adds the multiplication if that is the only thing stopping the more optimal instruction from being selected.
https://github.com/llvm/llvm-project/pull/174149/changes
(the stdarch change was reverted for now, but with LLVM 22 we can re-land it without regressing performance)
@david_chisnall excoriates ACM’s extortionate conference pricing https://lobste.rs/s/3bccy3/acm_is_now_fully_open_access#c_guc3wp
@dpk To be fair, the ACM isn't the only org doing this.
The first LLVM developer meeting I went to in London was free. I think the one in Paris was about $50. Most of the event costs were covered by sponsorship, they were hosted in universities (free) and have volunteer AV.
The upcoming one is £1050. Until last year, speakers got free admission, now they're getting 50% off.
We'll probably send one or two people, but it's hard to justify. I can't justify going myself at that price, I hope we can justify the budget to send one or two people from our compiler team.
The prices have spiralled completely out of control.
The adler32 checksum algorithm introduces a (seemingly useless) multiplication by 1 so that it can use a VPMADDWD widening multiply + add instruction.
After a recent change to stdarch, the multiplication got optimized out before that instruction could be selected, leading to much worse performance.
So I added some logic that adds the multiplication if that is the only thing stopping the more optimal instruction from being selected.
https://github.com/llvm/llvm-project/pull/174149/changes
(the stdarch change was reverted for now, but with LLVM 22 we can re-land it without regressing performance)
Bad codegen for comparing struct of two 16bit ints, https://github.com/rust-lang/rust/issues/140167.
Excellent discussions about a simple problem in appearance: Comparing a struct with two `u16` could be achieved by comparing one `u32` (bits concatenation of both `u16`, both should be loaded in the same register). Turns out, despite being a nice optimisation, it’s rather complex!
Edit: it also works with `i16` and `i32` of course.
We don't need more contributors who aren't programmers to contribute code
https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-human-in-the-loop/89159
#HackerNews #programming #community #contributor #debate #AI #tools #LLVM
⏱️ Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level
#llvm #compilers #security #computing #software #sidechannels #cyber
⏱️ Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level
#llvm #compilers #security #computing #software #sidechannels #cyber
Illuminating the processor core with LLVM-mca
#HackerNews #LLVM-mca #ProcessorCore #Illumination #Technology #HackerNews #Abseil
Java Hello World, LLVM Edition
https://www.javaadvent.com/2025/12/java-hello-world-llvm-edition.html
#HackerNews #Java #Hello #World #LLVM #Edition #Java #LLVM #Programming #Languages #Tech #News
I made another fun LLVM fix
https://github.com/llvm/llvm-project/pull/169591
Making these changes is hard but the reviewers have been extremely helpful in polishing the implementation.
Fixing small missed optimizations like this is useful for rust because it allows e.g. miri to handle more SIMD code automatically.