For a real world example of how this can affect code check out this commit I made in mesa: <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20877/diffs?commit_id=4b8dfaae89eedd54f7f9881adc8712d99ff30a60" rel="nofollow">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20...</a>
When you have done enough C++ you don't need to fire up compiler explorer, you just use local variables to avoid aliasing pessimisations.<p>I also wrote about this a while ago: <a href="https://forwardscattering.org/post/51" rel="nofollow">https://forwardscattering.org/post/51</a>
I think this might not be a shortcoming of MSVC but rather a deliberate design decision. It seems likely that MSVC is failing to apply strict aliasing, but that it's deliberately avoiding it, probably for compatibility reasons with code that wasn't/isn't written to spec. And frankly it can be very onerous to write code that is 100% correct per the standard when dealing with e.g. memory-mapped files; I'm struggling to recall seeing a single case of this.
Thank you Rust for having aliasing guarantees on references!
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays.<p>While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is <i>a pain</i> to do it properly.
Aliasing can be a problem in Fortran too.<p>Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect was that the value of zero because 4 for the rest of the program execution because Fortran aliases all parameters since it passes by descriptor (or at least DEC FORTRAN IV did so on RSX/11). As you can imagine, hilarity ensued.
Is it? You just add "restrict" where needed?<p><a href="https://godbolt.org/z/jva4shbjs" rel="nofollow">https://godbolt.org/z/jva4shbjs</a>
Support for arrays without having to mess with pointers is pretty attractive for number crunchers too.
The whole series is excellent and as a non regular user of assembly I learned a ton.
I wonder how much potential optimisation there is if we entirely drop pointer nonsense.
Are you talking about dropping pointers as a programmer-facing programming language concept (in which case you might find Hylo and similar languages interesting), or dropping pointers from <i>everything</i> - programming languages, their implementations, compilers, etc. (in which case I'm not sure that's even possible)?
For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.<p>Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...
For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:<p><pre><code> void foo(void *a, void *b, int n) {
assume_aligned(a, 16);
assume_stride(a, 16);
assume_distinct(a, b);
... go and vectorize!
}</code></pre>
LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess.<p>Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.