6 ms·
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
by newpavlov 9mo 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 9mo agoFor 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! }
- newpavlov 9mo agoLOL, 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. 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.
- aw1621107 9mo agoDoes make me wonder what restrict-related bugs will be (have been?) uncovered in GCC, if any. Or whether the GCC devs saw what LLVM went through and decided to try to address any issues preemptively.
- gpderetta 9mo agogcc has had restrict for 25 years I think. I would hope most bugs have been squashed by now.
- aw1621107 9mo agoPossibly? LLVM had been around for a while as well but Rust still ended up running into aliasing-related optimizer bugs. Now that I think about it some more, perhaps gfortran might be a differentiating factor? Not familiar enough with Fortran to guess as to how much it would exercise aliasing-related optimizations, though.
- newpavlov 9mo agoIIRC at least one of the `restrict` bugs found by Rust was reproduced on both LLVM and GCC.