4 ms·
It's interesting to note that the hesitant adoption of "restrict" in C has affected rust's use of the LLVM implementation of that feature. In rust, technically
by anyfoo 5y ago
It's interesting to note that the hesitant adoption of "restrict" in C has affected rust's use of the LLVM implementation of that feature.
In rust, technically almost every pointer is non-aliasing, so you could enable "restrict" (or rather its equivalent down in the LLVM layer) by default for almost every pointer. However, this uncovered many unexercised corner cases where LLVM's restrict implementation appeared broken:
https://stackoverflow.com/questions/57259126/why-does-the-rust-compiler-not-optimize-code-assuming-that-two-mutable-reference/57259339 https://stackoverflow.com/questions/57259126/why-does-the-ru...
Scroll down to the answer to see how often noalias was enabled and disabled.
- dataangel 5y agoIt just got reenabled again.
- vlovich123 5y agoAre you aware of any interesting benchmarks? I’m curious what the performance difference is in different kinds of applications.
- 3836293648 5y agoThe cited figure is a ~5% performance drop the first time rustc disabled noalias
- kibwen 5y agoNote that that's an "up to" 5% drop. Some benchmarks were unaffected, some were only lightly affected.
- pjmlp 5y agoUntil the next miscompilation bug is found, how many times it has been reenabled thus far?
- masklinn 5y agoThe SO answer has the entire list (Shep' apparently updates it regularly). In stable it had to be disabled twice, though both times it remained disabled for a long while, and the first re-enable was a mayfly (lasted all of 18 weeks): * initially enabled * disabled in 1.8 * enabled in 1.27 * disabled in 1.30 * enabled 1.54 (because an issue blocked enabling it in 1.53 which pretty much guarantees there's still a bunch lurking)