4 ms·

> aliasing can’t happen unless both references are read only Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword thoug

> aliasing can’t happen unless both references are read only Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.

orangeboats 2y ago
The restrict keyword is very seldomly used in C programs. You could probably remove it and still be able to compile the majority of C programs. (Otherwise, the Rust project wouldn't have encountered all the bugs related to aliasing analysis in LLVM.)
- kazinator 2y ago
  The ISO C standard uses the restrict qualifier on some standard library function declarations in such a way that it does nothing.
- physicsguy 2y ago
  It's not used much in a sense that it's applied to very few functions, but it is well known and widely used in limited circumstances. The bugs in LLVM (and GCC) are basically because Rust is using aliasing much more widely than it ever has been in most C programs. Take for e.g. this: void add(double *A, double *B, double *C, int N) { for(int i = 0; i < N; i++) { C[i] = A[i] + B[i]; } } You generally wouldn't find many C developers sprinkling restrict in on functions like this, since that function could be useful to someone using add on two overlapping arrays. On the other hand, someone writing a ODE solver in a scientific code might write a function like this, where it would never make sense for the memory locations to overlap: void RHS(double* restrict x, double* restrict xdot, int N, double dt) { for(int i = 0; i < N; i++) { xdot[i] = -x[i]/dt; } } In those sorts of circumstances, it's one of the first performance optimisations you might reach for in your C/C++ toolkit, before starting to look at for e.g. parallelism. It's been in every simulation or mathematical code base I've worked on in 10+ years at various different academic institutions and industry companies.
  - vlovich123 2y ago
    I think you're being overly optimistic in assuming that is actually the case. Bugs like https://bugs.llvm.org/show_bug.cgi?id=39282 https://bugs.llvm.org/show_bug.cgi?id=39282 make me think that even simple examples like you wrote could have had problems. Here's a similar bug but for GCC: https://github.com/rust-lang/rust/issues/54878#issuecomment-429578187 https://github.com/rust-lang/rust/issues/54878#issuecomment-.... I fully expect MSVC to be full of such bugs. I'm sure there were probably others. It's generally true that C/C++ code rarely if ever uses restrict & that Rust was the first to actually put any real pressure on those code paths and once it was found it took over a year to fix and it's incorrect to state that the miscompilation was only in code patterns that would only exist in Rust.
    - physicsguy 2y ago
      In the areas I've worked these sorts of cases would have been picked up by tests, and especially checking for correctness of output between different optimisation levels. But I can concede that that's perhaps not the standard sort of workflow for many C/C++ developers.
- int_19h 2y ago
  You should be able to remove `restrict` in any valid C program and still compile it and run it with the same result, no? Adding `restrict` can make otherwise valid code UB if there's aliasing, but the reverse shouldn't ever appply.
  - School-Cotton 2y ago
    I think OP meant you could remove the “restrict” keyword from the language and most programs would still compile fine.
vlovich123 2y ago
> C and C++ have the restrict keyword I'd say in name only given that there were numerous aliasing bugs in llvm that only became visible when Rust tried to leverage it. I suspect similar pitfalls exist in every single C/C++ compiler because the rules for restrict are not only difficult to understand for use but also difficult to implement correctly.
- physicsguy 2y ago
  Left a comment on another reply, but as I said there, there's a big difference in approach because restrict usually only gets sprinkled in on very few functions, but it doesn't mean it's not used.

orangeboats 2y ago

The restrict keyword is very seldomly used in C programs. You could probably remove it and still be able to compile the majority of C programs. (Otherwise, the Rust project wouldn't have encountered all the bugs related to aliasing analysis in LLVM.)

kazinator 2y ago
The ISO C standard uses the restrict qualifier on some standard library function declarations in such a way that it does nothing.
physicsguy 2y ago
It's not used much in a sense that it's applied to very few functions, but it is well known and widely used in limited circumstances. The bugs in LLVM (and GCC) are basically because Rust is using aliasing much more widely than it ever has been in most C programs. Take for e.g. this: void add(double *A, double *B, double *C, int N) { for(int i = 0; i < N; i++) { C[i] = A[i] + B[i]; } } You generally wouldn't find many C developers sprinkling restrict in on functions like this, since that function could be useful to someone using add on two overlapping arrays. On the other hand, someone writing a ODE solver in a scientific code might write a function like this, where it would never make sense for the memory locations to overlap: void RHS(double* restrict x, double* restrict xdot, int N, double dt) { for(int i = 0; i < N; i++) { xdot[i] = -x[i]/dt; } } In those sorts of circumstances, it's one of the first performance optimisations you might reach for in your C/C++ toolkit, before starting to look at for e.g. parallelism. It's been in every simulation or mathematical code base I've worked on in 10+ years at various different academic institutions and industry companies.
- vlovich123 2y ago
  I think you're being overly optimistic in assuming that is actually the case. Bugs like https://bugs.llvm.org/show_bug.cgi?id=39282 https://bugs.llvm.org/show_bug.cgi?id=39282 make me think that even simple examples like you wrote could have had problems. Here's a similar bug but for GCC: https://github.com/rust-lang/rust/issues/54878#issuecomment-429578187 https://github.com/rust-lang/rust/issues/54878#issuecomment-.... I fully expect MSVC to be full of such bugs. I'm sure there were probably others. It's generally true that C/C++ code rarely if ever uses restrict & that Rust was the first to actually put any real pressure on those code paths and once it was found it took over a year to fix and it's incorrect to state that the miscompilation was only in code patterns that would only exist in Rust.
  - physicsguy 2y ago
    In the areas I've worked these sorts of cases would have been picked up by tests, and especially checking for correctness of output between different optimisation levels. But I can concede that that's perhaps not the standard sort of workflow for many C/C++ developers.
int_19h 2y ago
You should be able to remove `restrict` in any valid C program and still compile it and run it with the same result, no? Adding `restrict` can make otherwise valid code UB if there's aliasing, but the reverse shouldn't ever appply.
- School-Cotton 2y ago
  I think OP meant you could remove the “restrict” keyword from the language and most programs would still compile fine.

vlovich123 2y ago

> C and C++ have the restrict keyword I'd say in name only given that there were numerous aliasing bugs in llvm that only became visible when Rust tried to leverage it. I suspect similar pitfalls exist in every single C/C++ compiler because the rules for restrict are not only difficult to understand for use but also difficult to implement correctly.

physicsguy 2y ago
Left a comment on another reply, but as I said there, there's a big difference in approach because restrict usually only gets sprinkled in on very few functions, but it doesn't mean it's not used.