Mastodawn

@mattpd @neilhenning Yeah, improving extension points so that there is less need for forking is definitely a good way to improve the situation.

@dzaima It would have been more accurate to say that the *default* ABI should be per-module. If a call wants to use a different one, it should use an explicit calling convention (which does not mean it has to be user-specified, it can be compiler-inferred.) So basically there's just a bunch of different CCs, and a per-module choice of what the default CC is.

@camelcdr SPIRV is GlobalISel-only and AArch64 uses GlobalISel for unoptimized builds.

New blog post: "LLVM: The bad parts"
https://www.npopov.com/2026/01/11/LLVM-The-bad-parts.html

I had some fun writing this :)

LLVM: The bad parts

@uecker For the first point, a provenance-dropping ptr2int is in the plans, but I'd be curious to hear why you're interested in it.

@fay59 I see, you have a different notion of overflow in mind. I would expect that a generic ptradd.with.overflow intrinsic would end up being defined in terms of overflow of the pointer index space -- and LLVM doesn't actually model pointers on ARM as having 56-bit index size.

What's the general use case you have in mind here? Something like sanitizers?

@fay59 No -- is there a use case for it? (ptradd p, x) ult p would be the canonical way to write an (unsigned) overflow check, same as for additions.

https://www.npopov.com/2025/01/05/This-year-in-LLVM-2024.html

New blog post: This year in LLVM (2024)

This year in LLVM (2024)