it was a fun idea to get easy perf wins. it's clear it's a failed experiment
Conversation
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.
2
5
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
They’re usually prevented anyway because more often than not you have multiple pointers of the same type. Restrict is the appropriate remedy!
3
5
(pssst... Steve... do we know what restrict means yet?)
2
5
Yeah, I’m referring to some platonic ideal of restrict here.
3
8
The way NoAlias is defined by LLVM works extremely well for Rust and would work well for other languages with unique ownership (Box<T>), unique borrows (&mut T) and true immutability (&mut T). LLVM scoped noalias metadata has issues but the definition of NoAlias itself is solid.