Readit News logoReadit News
turol · 3 months ago
For a real world example of how this can affect code check out this commit I made in mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20...
Ono-Sendai · 3 months ago
When you have done enough C++ you don't need to fire up compiler explorer, you just use local variables to avoid aliasing pessimisations.

I also wrote about this a while ago: https://forwardscattering.org/post/51

dataflow · 3 months ago
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.
gpderetta · 3 months ago
AFIK MSVC has never implemented TBAA by design.
andrepd · 3 months ago
Thank you Rust for having aliasing guarantees on references!
adev_ · 3 months ago
Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays.

While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.

bregma · 3 months ago
Aliasing can be a problem in Fortran too.

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.

pklausler · 3 months ago
How does this bug concern aliasing?
uecker · 3 months ago
Is it? You just add "restrict" where needed?

https://godbolt.org/z/jva4shbjs

adev_ · 3 months ago
> Is it? You just add "restrict" where needed?

Yes. That is the main solution and it is not a good one.

1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood.

1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.

kryptiskt · 3 months ago
Support for arrays without having to mess with pointers is pretty attractive for number crunchers too.
Bootvis · 3 months ago
The whole series is excellent and as a non regular user of assembly I learned a ton.
artemonster · 3 months ago
I wonder how much potential optimisation there is if we entirely drop pointer nonsense.
aw1621107 · 3 months ago
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 everything - programming languages, their implementations, compilers, etc. (in which case I'm not sure that's even possible)?
artemonster · 3 months ago
Only the first one. Ofc under the hood they will stay, but I think its time to ditch random access model and pull fetching and concept of time closer to programmer
newpavlov · 3 months ago
For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.

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...

cv5005 · 3 months ago
For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }