Talk:Restrict

Why restrict on all pointers?

I have tried compiling and disassembling the example on my own, and it is true that you have to use restrict on at least ptrA and val to gain the optimization. But I can not figure out why. Why is using restrict on the val pointer only not enough?

Is it possible that the compiler (may be compiler dependent?) assumes that the restriction only implies on other pointers that are also restricted? If so, this might be a good add to the article.

Using GCC 4.4.5 I can confirm this behavior: the restrict optimization is only applied when reading a restrict pointer which is already in a register, and no non-restrict pointer made a modification to the object the non-restrict pointer refers to.

"restrict" optional in C++ [but not in C] an important difference?

I understand the C restrict keyword (not available in C++) is to indicate that accesses through pointers "do not alias", to gain speed.

I also understand in C++, there are e.g. __restrict or __restrict__, that is, no way is standardized, so does that mean [portable] C++ can't be as fast?

I also understand that any "restrict-way" in C++ is optional; could have no effect (in other compilers (only?), with different syntax), but couldn't you say the same for C? It's a keyword, and the compiler may not give a syntax error, but I guess it could just parse it and then ignore.

Is there anything in C++ that mitigates missing or non-standard restrict? That is, since you have more type information, the compiler could in theory realize (as with Fortran) that no aliasing can happen? comp.arch (talk) 13:24, 2 June 2016 (UTC)

does "restrict" imply "const"?

I wonder whether any foo *restrict ptr is equivalent to foo *const restrict ptr: Obviously if you modify ptr, it may access another data item than ptr initially pointed to. So does restrict imply const, or should it be common practice to combine both? If not, any example where a valid use of restrict also modifies the pointer? Uhw (talk) 11:49, 15 December 2016 (UTC)

introduction

The lead is not really correct, though it describes the most common use. The C standard (I'm looking at C23, section 6.7.4.2) doesn't say that no other pointers may refer to the same object as pointed to by a restrict pointer p, but only that any such pointers have to be "based on p". This is not so easy to understand, (gripe: due to the standard being written by people who are inept at formal writing), but for example this is allowed because p2 is based on p1.

 int h(int *restrict p1) { int *restrict p2;  p2 = p1;  return *p1 + *p2; }

These are also allowed:

 int s(int *restrict p1,int n) {int *p2,sum=0; for (p2=p1; p2<p1+n; ++p2) sum += *p2; return sum;}
 void t(int *restrict p1,int n) {int *p2; for (p2=p1; p2<p1+n; ++p2) ++*p2;}

Zero^talk 09:13, 10 May 2025 (UTC)

In fact it's even more complex because it depends on whether pointers are used to modify the object they point to. This example appears in the standard and is valid because the array b is not modified in the procedure.

 void hh(int n, int * restrict p, int * restrict q, int * restrict r)
 {
   for (int i = 0; i < n; i++)
       p[i] = q[i] + r[i];
 }
 
 int main()
 {
   int a[20],b[20];
   hh(20,a,b,b);
 }

Currently I'm at a loss to write a complete description which is more comprehensible than the standard, which is hardly comprehensible at all. The basic idea is that, if a pointer A is restricted, you can't modify an object using pointer B and then access it using pointer A, unless B is based on A. But that's not the whole story either. Zero^talk 13:52, 30 July 2025 (UTC)