I've mentioned it before but there's a chance for Rust to get better than most C code with the ability to implicitly mark mut& as restrict.
Restrict is one of those very, very sharp tools that's usually only reserved for cases where you've profiled and done the extensive work to guarantee non-aliasing pointers. The fact that it's just implicit as part of the ownership design of Rust is pretty bad-ass.
AIUI it seems that one of the issues that Rust is having right now is that it actually has more precise information than LLVM is really capable of taking advantage of, which makes sense given that LLVM was originally intended to take advantage only of C's coarser restrict semantics. It's sort of a funny situation where the fact that Rust could improve on C's optimization capabilities is the same reason that it can't yet do so: it's using an optimizer designed for C!
That said, I'm hardly an expert here and the situation on the ground may have changed since last I looked (or I may be completely misunderstanding the discussions that I've peeked into). An example of the problem in this GitHub issue: https://github.com/rust-lang/rust/issues/53105
We do the equivalent of telling the compiler that things don't alias at function boundaries (i.e. restrict) and not much more.
Nobody writes C code with restrict all over the place, which means that not only is this the finest grained level we can give this info to LLVM, it doesn't even necessarily support it well! We had to turn it off for &mut for a long time because of a bunch of bugs.
The weird thing is, to be able to do most optimizations LLVM does its own alias analysis anyway! (I don't know the details).
A lot of program analysis research is focused on improving alias analyses which are usually slow, imperfect, and global. Rust's aliasing info is "free" (you don't need to compute anything extra to get it), local, and perfect (ish). We really could get a lot of wins from doing our own aliasing-aware analyses, or by reordering the code in such a way so as to make it easier for LLVM (e.g., hoisting reads and writes to function boundaries so llvm just sees a bunch of locals)
"The intended use of the restrict qualifier (like the register storage class) is to promote optimization, and deleting all instances of the qualifier from all preprocessing translation units composing a conforming program does not change its meaning (i.e., observable behavior).
The compiler is free to ignore any or all aliasing implications of uses of restrict.
To avoid undefined behavior, the programmer must ensure that the aliasing assertions made by the restrict-qualified pointers are not violated. ..."
Restrict is one of those very, very sharp tools that's usually only reserved for cases where you've profiled and done the extensive work to guarantee non-aliasing pointers. The fact that it's just implicit as part of the ownership design of Rust is pretty bad-ass.