3 ms·

"restrict" is getting around language issues where it's easy to "accidently" block things like vectorization, or having to reload values multiple times just in

by kimixa 2y ago

"restrict" is getting around language issues where it's easy to "accidently" block things like vectorization, or having to reload values multiple times just in case pointers aliased. There's no compiler in the world that can work around this without more guarantees on the expected behavior from the programmer, as it would be incorrect according to the spec. I've seen "obvious" big wins missed without it.

dzaima 2y ago
Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization (granted, that can fail if you have reverse/strided/gather addresses, but those are less common; and yeah it does lead to some constant overhead, though likely not significant often). Of minor note is that you can add "#pragma clang loop vectorize(assume_safety)" or "#pragma GCC ivdep" on the respective compilers to a loop to allow them to vectorize anything, which in my experience is much more functional than restrict. And even the vast majority of benefit I've gotten from it was just removing the alias check overhead (though it did catch a case of a reversing loop failing to vectorize due to a 32-bit index variable or something)
- astrange 2y ago
  > Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization This is often enough to make it unworkable, because it means you're inserting checks into hot loops. Also, if you partially vectorize something yourself you have to write similar setup code, which might involve scalar versions of the loop, but then autovectorization can come by and vectorize those, so now you have duplicate setup code making it worse than nothing.
  - dzaima 2y ago
    The checks are done outside of the loop though (unless you mean ≥two nested loops, with a small-ish inner one, at which point things indeed get less nice, but also this is less common). Yeah, autovectorization of a manual tail loop can be annoying, but there is "#pragma clang loop unroll(disable)" and "#pragma clang loop vectorize(disable)" for clang, and for gcc "#pragma GCC unroll 1" and, from gcc 14, "#pragma GCC novector".

by kimixa 2y ago

dzaima 2y ago

Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization (granted, that can fail if you have reverse/strided/gather addresses, but those are less common; and yeah it does lead to some constant overhead, though likely not significant often). Of minor note is that you can add "#pragma clang loop vectorize(assume_safety)" or "#pragma GCC ivdep" on the respective compilers to a loop to allow them to vectorize anything, which in my experience is much more functional than restrict. And even the vast majority of benefit I've gotten from it was just removing the alias check overhead (though it did catch a case of a reversing loop failing to vectorize due to a 32-bit index variable or something)

astrange 2y ago
> Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization This is often enough to make it unworkable, because it means you're inserting checks into hot loops. Also, if you partially vectorize something yourself you have to write similar setup code, which might involve scalar versions of the loop, but then autovectorization can come by and vectorize those, so now you have duplicate setup code making it worse than nothing.
- dzaima 2y ago
  The checks are done outside of the loop though (unless you mean ≥two nested loops, with a small-ish inner one, at which point things indeed get less nice, but also this is less common). Yeah, autovectorization of a manual tail loop can be annoying, but there is "#pragma clang loop unroll(disable)" and "#pragma clang loop vectorize(disable)" for clang, and for gcc "#pragma GCC unroll 1" and, from gcc 14, "#pragma GCC novector".