Re: What does 'restrict' mean?

Me schrieb:
Michael Mair wrote:
Me schrieb:
Michael Mair wrote:

void *MemFoo (void * restrict pDest,
void * restrict pSrc, size_t size)
{
/* Never true: Can be thrown away */
if (pDest == pSrc) {
return pDest;
}

I don't think that's true.

I forgot to make sure that neither pDest nor pSrc is a null
pointer -- this part should have been excluded beforehand;
if we assume that we know that neither is a null pointer,
then -- if I have understood restrict right -- this means
that pDest cannot be equal to pSrc.
Is this what you are getting at?

No, I'm saying that just because a pointer is marked as restrict
doesn't give the compiler any information at all to say if it overlaps
with another object or not. It has to examine the use of the pointer
expressions inside a block to determine this information, hence the
comparison of the pointers in MemFoo cannot be eliminated as is.

I think you are wrong there -- restrict does not say straight
out "does not overlap" but it says the compiler may assume that
the pointers are used like this. I expect a compiler to utilise
this information as if a full alias analysis said "these pointers
never point to overlapping objects". These are the steps I performed
but for the omission of making sure that no null pointers are
involved.
I understand that there are no guarantees for restrict but that
there is a permission to act as if there were such guarantees --
which is quite enough for a compiler.

Christian Bau's post about restrict is a pretty good approximation to
what the standard says:

http://groups.google.com/group/comp.std.c/msg/7f4409dea7e43736

Thanks for the link.

just be careful when reading it because he uses "const restrict
pointer" to mean "const T * restrict".

http://www.lysator.liu.se/c/restrict.html

Is also a good (outdated) reference. The most important piece of
information to glean from it is 3.9 which describes how return values
and typecasts with restrict are meaningless.

Which is consistent.


To summarize what's ok and what isn't with just the minimum amount of
information:

void f(int *restrict, int *restrict){}

/* ok */
int a;
f(&a, &a);

I'd expect at least a warning from a good compiler in this case.


/* also ok */
int a;
int *restrict pa = &a;
int *restrict pb = &a;
f(pa, pb);

The same. The only reason why I see this and the above as safe is
that f()'s body is empty.

/* undefined */
int a;
int *restrict pa = &a;
f(pa, pa);

Here we agree.

I do not know if there are compilers who actually use the
information gleaned from restrict or who even use it aggressively;
I really would welcome a compiler writer's point of view for this
case as it may clarify potential and actual uses as well as less
obvious defects in the specification of restrict.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
.

Relevant Pages

  • Restrict qualified pointers in C
    ... I am having trouble understanding certain aspects of restrict ... Can a compiler figure this out, and thus still generate fast code? ... giving it the following "restricted" pointers: ...
    (comp.lang.c)
  • Re: Restrict qualified pointers in C
    ... I am having trouble understanding certain aspects of restrict ... Can a compiler figure this out, and thus still generate fast code? ... giving it the following "restricted" pointers: ...
    (comp.lang.c)
  • Re: restrict keyword from ISO C99?
    ... Without restrict, it would ... >> OK for the compiler to use parallel instructions, ... > pointers, allowing the compiler to generate faster machine code. ... modifying the target of a pointer, and forgot that it overlapped the target ...
    (comp.lang.c)
  • Re: restrict
    ... >> the two data areas may not overlap. ... > but my compiler doesn't complain. ... you, the programmer, cannot pass pointers to overlapping data areas to ... detected that "restrict" is needed: ...
    (comp.lang.c)
  • Re: What does restrict mean?
    ... but what does the keyword 'restrict' mean? ... The reason that memcpy has the restrict keyword and memmove doesn't ... will be made from s2 or pointers derived from s2. ...
    (comp.lang.c)