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.

Declaration of intent only?

Is this the programmer telling the compiler "I won't point there twice. So assume I don't." or "I don't want to point there twice. Check and make sure that I don't."? --84.62.198.149 23:34, 2 June 2007 (UTC)

The former. This check is impossible to do in general at compile time (if it were possible, the "restrict" keyword wouldn't be necessary in the first place) and C just doesn't have any such thing as a run-time check (environments are free to provide them, but the standard never requires them, leaving all the situations were they would be required as undefined behavior). 82.95.254.249 (talk) 21:50, 20 November 2007 (UTC)

load R3 ← *ptrA

I'm new to restrict, but is load R3 ← *ptrA supposed to be load R3 ← *ptrB in...

load R1 ← *val 
load R2 ← *ptrA
load R3 ← *ptrA
add  R2 += R1
add  R3 += R1
set  R2 → *ptrA
set  R3 → *ptrB

? Also, is <source lang="asm"> appropriate for a piece of pseudo-asm? Bitwiseb (talk) 09:55, 14 May 2008 (UTC)

Fine, I'll just change it... Bitwiseb (talk) 20:32, 15 May 2008 (UTC)

The introductory paragraph is incorrect

Restrict doesn't restrict what may be pointed at at all. It restricts which objects may be accessed during the lifetime of the restricted pointer. You can imagine that a pointer dereference 'paints' an object. The essential point here is that for the lifetime of the restricted pointer the region that it paints is not painted by any other pointer. Pointing at an object cannot violate restrict. Dereferencing may.

Do you have time to correct it on your own or do you know some resource where your correct way of understanding is explained further such that someone else can rephrase the introduction? 220.142.131.4 (talk) 05:04, 18 December 2008 (UTC)

I believe I've corrected this. Superm401 - Talk 09:27, 22 December 2008 (UTC)

Reference to Compromised URL

Is it just me, or has this site been hacked?

http://www.cellperformance.com/

It redirects to a fraudulent (viral) site:

http://anti-virus-secure-scanner.com/

Also, it seems the site's lease is going to expire soon anyways:

http://whois.domaintools.com/cellperformance.com

This will be posted in each of the following discussions at: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C++ http://en.wikipedia.org/wiki/Aliasing_(computing) http://en.wikipedia.org/wiki/Restrict

76.64.33.246 (talk) 06:20, 2 January 2009 (UTC)

Hint: Link to "Some Typical Uses"

As a newcommer I cannot judge if this could be useful: In my opinion there are some nice examples of typical uses on http://developers.sun.com/solaris/articles/cc_restrict.html.

(Lachkauz (talk) 11:59, 27 July 2009 (UTC))

memcpy example

the memcpy example says that restrict can be used to tell the compiler that the arguments to memcpy dont overlap. but according to the memcpy man page the memory areas are not allowed to overlap, and that if they do to use memmove. it would seem like the restrict is implied already, and therefore not needed. could a C guru give an opinion? --194.36.2.60 (talk) 13:21, 18 May 2010 (UTC)

• The example is bull, I'm removing it. The prototype isn't even correct, it misses a const. Qwertyus (talk) 22:39, 16 February 2011 (UTC)

• • No, it is a good example. Because of the documented behavior of memcpy, it is acceptable to mark the arguments with restrict. This is not redundant at all, except for the fact that standard functions like memcpy are specially recognized by compilers. (so the compiler already knows that memcpy should have restrict) If you wrote your own my_mem_copy function, it wouldn't be special and the compiler wouldn't know unless you used restrict. 208.118.25.22 (talk) 01:30, 20 January 2013 (UTC)

Vectorization

Shouldn't be mentioned that the main usefulness of restrict today is that autovectorizing compilers use it to decide if a loop can be vectorized? O.mangold (talk) 16:53, 3 December 2010 (UTC)

add R2 += R1

Sentence "add R2 += R1" looks like contains some redundancy. "add" and "+=" mean the same — Preceding unsigned comment added by Conan666 (talk • contribs) 08:37, 16 January 2013 (UTC)

Alternative working example

typedef void Cb();
int foo(const int * a, Cb cb) {
  int x = *a;
  cb();
  return x - *a;
}

Give it a workout using clang (GCC optimization seems broken). — Preceding unsigned comment added by 94.220.161.15 (talk) 17:39, 4 December 2014 (UTC)

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

I understand restrict 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 not standardized, so does that mean [portable] C++ can't be as fast?

I also understand that the ways you do this in C++ are optional, could have no effect, 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)