views:

553

answers:

5

I'm trying to understand when and when not to use the restrict keyword in C and in what situations it provides a tangible benefit.

After reading, "Demystifying The Restrict Keyword", ( which provides some rules of thumb on usage ), I get the impression that when a function is passed pointers, it has to account for the possibility that the data pointed to might overlap (alias) with any other arguments being passed into the function. Given a function:

foo(int *a, int *b, int *c, int n) {
    for (int i = n; i<n; ++i) {
        b[i] = b[i] + c[i];
        a[i] = a[i] + b[i] * c[i];
    } 
}

the compiler has to reload c in the second expression, because maybe b and c point to the same location. It also has to wait for b to be stored before it can load a for the same reason. It then has to wait for a to be stored and must reload b and c at the beginning of the next loop. If you call the function like this:

int a[N];
foo(a, a, a, N);

then you can see why the compiler has to do this. Using restrict effectively tells the compiler that you will never do this, so that it can drop the redundant load of c and load a before b is stored.

In a different SO post, Nils Pipenbrinck, provides a working example of this scenario demonstrating the performance benefit.

So far I've gathered that it's a good idea to use restrict on pointers you pass into functions which won't be inlined. Apparently if the code is inlined the compiler can figure out that the pointers don't overlap.

Now here's where things start getting fuzzy for me.

In Ulrich Drepper's paper, "What every programmer should know about memory" he makes the statement that, "unless restrict is used, all pointer accesses are potential sources of aliasing," and he gives a specific code example of a submatrix matrix multiply where he uses restrict.

However, when I compile his example code either with or without restrict I get identical binaries in both cases. I'm using gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

The thing I can't figure out in the following code is whether it needs to be rewritten to make more extensive use of restrict, or if the alias analysis in GCC is just so good that it's able to figure out that none of the arguments alias each other. For purely educational purposes, how can I make using or not using restrict matter in this code - and why?

For restrict compiled with:

gcc -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) -DUSE_RESTRICT -Wextra -std=c99 -O3 matrixMul.c -o matrixMul

Just remove -DUSE_RESTRICT to not use restrict.

#include <stdlib.h>
#include <stdio.h>
#include <emmintrin.h>

#ifdef USE_RESTRICT
#else
#define restrict
#endif

#define N 1000
double _res[N][N] __attribute__ ((aligned (64)));
double _mul1[N][N] __attribute__ ((aligned (64)))
    = { [0 ... (N-1)] 
    = { [0 ... (N-1)] = 1.1f }};
double _mul2[N][N] __attribute__ ((aligned (64)))
    = { [0 ... (N-1)] 
    = { [0 ... (N-1)] = 2.2f }};

#define SM (CLS / sizeof (double))

void mm(double (* restrict res)[N], double (* restrict mul1)[N], 
        double (* restrict mul2)[N]) __attribute__ ((noinline));

void mm(double (* restrict res)[N], double (* restrict mul1)[N], 
        double (* restrict mul2)[N])
{
 int i, i2, j, j2, k, k2; 
    double *restrict rres; 
    double *restrict rmul1; 
    double *restrict rmul2; 

    for (i = 0; i < N; i += SM)
        for (j = 0; j < N; j += SM)
            for (k = 0; k < N; k += SM)
                for (i2 = 0, rres = &res[i][j],
                    rmul1 = &mul1[i][k]; i2 < SM;
                    ++i2, rres += N, rmul1 += N)
                    for (k2 = 0, rmul2 = &mul2[k][j];
                        k2 < SM; ++k2, rmul2 += N)
                        for (j2 = 0; j2 < SM; ++j2)
                          rres[j2] += rmul1[k2] * rmul2[j2];
}

int main (void)
{

    mm(_res, _mul1, _mul2);

 return 0;
}
+1  A: 

May be the optimisation done here don't rely on pointers not being aliased ? Unless you preload multiple mul2 element before writing result in res2, I don't see any aliasing problem.

In the first piece of code you show, it is quite clear what kind of aliases problem can occur. Here it is not so clear.

Rereading Dreppers article, he does not specifically says restrict might solve anything. There is even this phrase :

{In theory the restrict keyword introduced into the C language in the 1999 revision should solve the problem. Compilers have not caught up yet, though. The reason is mainly that too much incorrect code exists which would mislead the compiler and cause it to generate incorrect object code.}

In this code, optimisations of memory access has already been done within the algorithm. The residual optimisation seems to be done in the vectorized code presented in appendice. So for the code presented here, I guess there is no difference, because no optimisation relying on restrict is done. Every pointer access is a source of aliasing, but not every optimisation relies on aliassing.

Premature optimization being the root of all evil, the use of the restrict keyword should be limited to the case your are actively studying and optimizing, not used wherever it could be used.

shodanex
@shodanex: This is exactly what I'm wondering. Drepper seems to indicate in his paper that specifically this code benefits from `restrict`. You can see a vectorized version of the same code using SSE2 instruction here: http://lwn.net/Articles/258188/ . Is it possible he just always uses `restrict` as his personal best practice and just didn't bother to check if it makes any difference with this code?
Robert S. Barnes
in the code you mention, there still is the presence of for (j2 = 0; j2 < SM; j2 += 2) which is where I could see aliasing occur. but this is not easy to see
shodanex
@shodanex: So why doesn't `rres[j2] += rmul1[k2] * rmul2[j2];` present an aliasing problem? Let's say I call `mm(_res, _res, _res)`. `rres[j2]` and `rmul2[j2]` have to be reloaded every time through the loop anyways. So even if ` potential aliasing doesn't matter.
Robert S. Barnes
@shodanex: So basically, Drepper always sticks in `restrict` as a best practice ( considering he put it in the vectorized version of the code ), and just didn't bother to check whether or not it made any difference with this particular code. That's what it looks like to me anyways.
Robert S. Barnes
+3  A: 

It is a hint to the code optimizer. Using restrict ensures it that it can store a pointer variable in a CPU register and not have to flush an update of the pointer value to memory so that an alias is updated as well.

Whether or not it takes advantage of it depends heavily on implementation details of the optimizer and the CPU. Code optimizers already are heavily invested in detecting non-aliasing since it is such an important optimization. It should have no trouble detecting that in your code.

Hans Passant
So basically you're saying that the alias analysis in gcc is so good that it's already able to detect that there are no aliasing problems on it's own even without the hint from using the `restrict` keyword?
Robert S. Barnes
Right. You'd need to pass double** as arguments and update them to introduce a blatant alias that the optimizer can't rule out.
Hans Passant
But without any knowledge of the potentiall caller, the result is the same, so I doubt this is what happens here
shodanex
A: 

Are you running on 32 or 64-bit Ubuntu? If 32-bit, then you need to add -march=core2 -mfpmath=sse (or whatever your processor architecture is), otherwise it doesn't use SSE. Secondly, in order to enable vectorization with GCC 4.2, you need to add the -ftree-vectorize option (as of 4.3 or 4.4 this is included as default in -O3). It might also be necessary to add -ffast-math (or another option providing relaxed floating point semantics) in order to allow the compiler to reorder floating point operations.

Also, add the -ftree-vectorizer-verbose=1 option to see whether it manages to vectorize the loop or not; that's an easy way to check the effect of adding the restrict keyword.

janneb
I'm using 32 bit Ubuntu on a Pentium M with -march=native. I added fast-math. The code I posted doesn't use SSE. Using the suggested options doesn't seem to help. I still get identical binaries in both cases.
Robert S. Barnes
Ah indeed, so it seems. I'm sure you also saw the reason for the failure to vectorize with the help of the -ftree-vectorizer-verbose= option. Which explains why Drepper had to resort to intrinsics for the vectorized version of his code. So you need to come up with another example.
janneb
A: 

Also, GCC 4.0.0-4.4 has a regression bug that causes the restrict keyword to be ignored. This bug was reported as fixed in 4.5 (I lost the bug number though).

Fredrik Berg Kjolstad
A: 

If there is a difference at all, moving mm to a seperate DSO (such that gcc can no longer know everything about the calling code) will be the way to demonstrate it.

Logan Capaldo