🥹🥲😢😭😭😭
Conversation
strict aliasing has got to go, it's just not compatible with the rest of the language
6
3
19
it was a fun idea to get easy perf wins. it's clear it's a failed experiment
2
10
I like the performance gains but I also like the concept that pointers point to the type of objects they say they point to. I almost always see -fno-strict-overflow as an indication of a failing codebase.
4
3
I hear you but the language as she is used in practice encourages type punning in sorta critical stuff like the famous socket example
3
8
What are the performance consequences in practice of disabling strict aliasing in C, anyway? Rust doesn't have it and it didn't actually tell LLVM about noalias until relatively recently, and I think enabling noalias only got ~ 5% avg so far (though that'll probably improve).
2
Rust can provide much better aliasing information than C based on the properties of & and &mut which is equivalent to putting restrict on nearly all pointers in C code. It hasn't been able to leverage that as much as it should be able to on top of LLVM due to optimization bugs.
yep, watching this play out has been super fascinating
1
1
Performance implications are that any value can be changed through any pointer which prohibits caching, code motion, and parallel instructions.
2
1
Show replies
&T for any type T without interior mutability (which is tracked by the type system) and any &mut U type can be marked with the same noalias markers used by Clang for restrict since noalias means no memory dependencies between them and is valid even if the address is the same.
2
4
Rust doesn't need to come up with type-based alias analysis rules beyond what & and &mut already provide themselves. The vast majority of types don't have interior mutability (Cell, RefCell, Mutex) so nearly all references could be marked noalias... if it worked properly in LLVM.