You need restrict for a loop involving char* or equivalent because it can alias any type in C. Without it, the compiler has to preserve memory accesses exactly, and then it's hardly able to do any optimizations. If you're writing all the memory accesses out perfectly optimally already, then you don't need the compiler for much.

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

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)

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

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