Dear Rustaceans,
I did a small experiment in Compiler Explorer to test whether non-aliasing guarantees of mutable references let rustc do additional optimizations in some situations.
I wrote a very short function in C and Rust to compare how they are compiled down to assembly. My expectation was that rustc would take advantage of the fact that a and b are non-aliasing pointers, and generate assembly that would simply return 10 (without even dereferencing the pointers). However, it turns out the generated assembly from gcc and rustc are identical, indicating that Rustc didn't work as I expected. Optimization levels were O3 in both gcc and rustc.
It seems to me that rustc is missing an optimization opportunity, but I'd like to know what other Rustaceans would think about this. Thanks!
I'm not able to give references and what was stated may well be out of date but...
I have been tenaciously watching every Rust related video I can find on YouTube, a couple of times presenters have mentioned that there were opportunities for optimization offered by the non-aliasing guarantees that were not yet passed on to LLVM. The expectation being that they would be in the future.
I guess that includes whatever is covered by the github issue mentioned above.
Long story short, C has been so bad at providing good non-aliasing guarantees that LLVM related code generation was never truly tested in "real production". It's only with Rust that it has been the case, and this has revealed LLVM bugs. So until these are fixed (it's something that is being worked on), this kind of optimizations cannot be exploited yet.
That is interesting.. would you mind sharing the link to your godbolt experiment? Link to mine is in the post.
I wonder if it could be a bug from Godbolt's side..
Wow, been using C since forever, never heard of "restrict", never seen it used. From wikipedia:
if the declaration of intent is not followed and the object is accessed by an independent pointer, this will result in undefined behavior. The use of the restrict keyword in C, in principle, allows non-obtuse C to achieve the same performance as the same program written in Fortran.
BTW, Is this post more relevant to the "Rust Internals Forum"??
If so, from now on I'll try to post such questions to that forum instead of the Rust language forum..
I concur with @RustyYato – Rust Internals is focused on language and tooling enhancements / changes, whereas Rust Users (this forum) is more appropriate for answering questions about the existing language and tooling, as well as for providing help in how to express programming intent in Rust, Cargo, etc.