https://www.npopov.com/2026/01/31/This-year-in-LLVM-2025.html
-
https://www.npopov.com/2026/01/31/This-year-in-LLVM-2025.html
> The reason I worked on this is that someone on Reddit shared an example where Rust’s GCC backend actually produced better code than the LLVM backend, which is an injustice I just could not let stand.
Hey, competition can be good for users.
-
https://www.npopov.com/2026/01/31/This-year-in-LLVM-2025.html
> The reason I worked on this is that someone on Reddit shared an example where Rust’s GCC backend actually produced better code than the LLVM backend, which is an injustice I just could not let stand.
Hey, competition can be good for users.
@llvm I'd complained about that store merge issue in Rust/clang code a bunch of times on Mastodon. I didn't know it'd been fixed; that's great! Actually, it felt more like an actual bug than a missing optimization because it wasn't able to handle very trivial cases, as I recall.
-
https://www.npopov.com/2026/01/31/This-year-in-LLVM-2025.html
> The reason I worked on this is that someone on Reddit shared an example where Rust’s GCC backend actually produced better code than the LLVM backend, which is an injustice I just could not let stand.
Hey, competition can be good for users.
@llvm Competition has been fantastic for users. Before LLVM, for example, GCC's error messages were often pretty incomprehensible. This will I learned about -ftime-trace from @andreasfertig , which AFAIK GCC does not have. Long may they compete!
-
R ActivityRelay shared this topic
