Behaviour of restrict keyword inside structs

Question

The scenario:

Suppose I have a struct type holding a bunch of pointers, all of which declared restrict, and a function which takes a couple of these struct as argument as follows:

struct bunch_of_ptr 
{
    double *restrict ptr00;
    double *restrict ptr01;
    ...
    double *restrict ptr19;
}

void evaluate(struct bunch_of_ptr input, struct bunch_of_ptr output) 
{
    // do some calculation on input and return results into output
}

According to http://www.oracle.com/technetwork/server-storage/solaris10/cc-restrict-139391.html, input.ptrXX and input.ptrYY will be treated as non-aliasing.

The question:

Will the compiler treat input.ptrXX and output.ptrYY as non-aliasing as well?

score 2 · Accepted Answer · answered Feb 12 '15 at 13:15

2

It should. For every pointer that you declare as restrict somewhere, the compiler can assume that it is the only access to the corresponding data. By declaring these, you actually give the compiler the guarantee.

If all compilers will take advantage of that information is another question. Passing restrict pointers through struct is not very common, so you'd have to see what your compiler does.

answered Feb 12 '15 at 13:15

Jens Gustedt

76,821
6
102
177

are you sure? please mind that input and output are passed by value, not as pointers – Pandrei Feb 12 '15 at 16:10
@Pandrei: The members of the parameter objects are `restrict `-qualified pointers. I'm not sure of the exact semantics, but I don't think that the qualifiers are simply ignored (except that a comforming compiler can ignore *all* `restrict` qualifiers). – Keith Thompson Feb 12 '15 at 17:20
@Pandrei, `restrict` qualification is a weird thing. In a sense it doesn't qualify the parameter itself but the object to which the parameter points. And regardless if the `struct` is copied or not, the function sees `restrict` qualified pointers. – Jens Gustedt Feb 12 '15 at 21:24
Restrict qualifier behavior depends highly on the compiler, but in this case, I expect that the input and output are not considered as non-aliasing only the members of each structure. – Pandrei Feb 13 '15 at 09:35
If a `restrict` pointer is stored in an automatic object, the lifetime of that object will generally make clear the duration of the object's ownership of any storage occupied thereby. If e.g. a struct containing a `restrict` pointer is created on the heap and used for awhile before the storage gets reused for some other purpose, how long would the pointer in the struct retain ownership over the objects? – supercat Jul 13 '18 at 21:57

score -2 · Answer 2 · answered Feb 12 '15 at 16:08

-2

I think you have a bigger problem in your code: you pass two struct variables by value as inputs to a function

void evaluate(struct bunch_of_ptr input, struct bunch_of_ptr output)

The effect of that is that every member of the structure will be copied on the stack; this is a lot of wasted stack space and a lot of overhead for this function. Furthermore the compiler will ignore the restrict qualifiers here because the struct does not expand like a macro, as far as the compiler is concerned, there are two arguments being passed in of type struct and there is no indication about aliasing.

This is probably what you wanted:

void evaluate(struct bunch_of_ptr *restrict input, struct bunch_of_ptr *restrict output)

answered Feb 12 '15 at 16:08

Pandrei

4,843
3
27
44

1

I'm working with code which currently takes some 40 pointers as arguments. Packaging them up into structs is not intended to save on the stack space (for the time being), only to ease the call signature. In other words, yes, the code as given in my question above is as intended. – Saran Tunyasuvunakool Feb 12 '15 at 22:16
My answer is still valid; As far as the compiler is concerned, the members of each structure will not overlap but the input and output members might. And you can check the generated asm code to confirm that – Pandrei Feb 13 '15 at 09:33

Behaviour of restrict keyword inside structs

2 Answers2