Rust isn't using scoped noalias metadata yet due to a mix of LLVM bugs and the need to clearly define the semantics for unsafe code. The LLVM scoped noalias metadata also has limitations in how it's designed. It can only mark the outermost pointer used in a function parameter.
Conversation
Oh yeah I know the semantics of noalias on function parameters are significantly weaker than what Rust would actually support. I guess by design TBAA applies globally so the benefits are easier to realize?
1
1
TBAA in C is incredibly weak especially since char * can alias with everything and a lot of the types are simply defined as typedefs of other types in practice or maybe even as required by the standard. It's incredibly hit or miss and lots of stuff gets in the way of it working.
1
4
It should just be removed. People should use restrict if they want it, and while the definition of restrict in the standard is screwed up it's defined in a reasonable way by Clang at least even though there were massive implementation bugs which are now largely fixed due to Rust.
1
4
TBAA is compiler people doing an optimization that was never intended to be supported and was clearly a standards violation and was then gradually brought into the standard in order to permit what compilers were already doing. It shouldn't have ever been a thing. Super broken.
1
3
It's completely reasonable to want to do those optimizations but real world C code is in violation of the rules and it was not historically permitted or intended in the initial standards. They decided to bend and outright break the rules and then "fixed" standards to allow it.
1
4
They should also really define signed overly as either wrapping or trapping with trapping allowed to be either eager or any degree of lazy that still prevents the results from being used for anything with a side effect. Honestly though, I don't really care. C just needs to go.
1
6
Also, hurting the performance of C code is a good thing. I'm all for disabling optimizations that were never actually standards compliant for C. LLVM is also wrongly applying the modern C++ rules for fudging the halting problem to C and legacy C++ when it's not actually allowed.
1
4
It really shouldn't be a thing that compilers add incorrect optimizations to make C faster when what they're doing is unsafe in practice and non-standards-compliant.
Personally, I think the ever increasing cost of all the weak mitigations gradually adding up will help replace C.
1
6
For example, -fstack-protector-strong which is used anywhere that's at all security conscious as a global default typically has somewhere in the range of 2% to 5% performance cost. Add in ShadowCallStack and CFI, and you could have paid less performance with full bounds checking.
3
3
8
Modern C isn't fast and is getting slower. ARM PAC, BTI and MTE have a performance cost too and none of those is a replacement for SSP, ShadowCallStack and CFI. Keep adding up cost. Eventually C will be slower than Java when full coarse memory safety has been fully bolted on.