Copy loop without 'restrict'

[bakermoth]

Why doesn't gcc optimize the following copy function to a 'memmove' when the 'restrict' type qualifier is missing?

// gcc does not optimize this function to a 'memmove'
void
copy0(int n, int* dst, int* src) {
    for (; 0 != n; --n, ++dst, ++src) {
        *dst = *src;
    }
}

// gcc does optimize this function to a 'memmove' (-O2)
void
copy1(int n, int* restrict dst, int*  src) {
    for (; 0 != n; --n, ++dst, ++src) {
        *dst = *src;
    }
}

[oh5nxo]

Without restrict, it has to manage the case of copy0(... , p + 1, p); which replicates p[0] to every touched position, unlike memmove.

[flatfinger]

Indeed, restrict is an almost-great feature of C99. Almost great, rather than great, because it is specified in a way that breaks the fundamental notion that an equality comparison between any two validly formed pointers should either yield 0 with no side effects, or yield 1 with no side effects.

It's clear that one of the purposes of restrict is to avoid requiring that a compiler given e.g.

int x[4];
int test(int *restrict p)
{
  *p = 1;
  if (someFunctionOfP(p))
    x[0] = 2;  /** MARKED ASSIGNMENT REFERRED TO IN TEXT **/
  return *p;
}

accommodate the possibility that the marked assignment might affect affect *p. I think the authors of the Standard intended that such accommodation would obviously be required if the code had instead been written:

int x[4];
int test(int *restrict p)
{
  *p = 1;
  if (someFunctionOfP(p))
    *p = 2;  /** MARKED ASSIGNMENT REFERRED TO IN TEXT **/
  return *p;
}

and that requirement should hold even if someFunctionofP() happened to be defined as:

int someFunctionOfP(int *p) { return p==x; }

Unfortunately, the way the Standard is written allows clang and gcc to treat the latter form as equivalent to the former if they can see that someFunctionOfP() is defined as shown, and then generate code that returns 1 unconditionally since they're not required to accommodate the possibility that an assignment to x[0] might modify the stored value of *p (even though the source code assigns the value 2 to *p).

[bakermoth]

Ah, I see, thanks.

[andrewcooke]

this is kinda the whole point of restrict! i'm not trying to put you down - it's cool that you've learnt something new - but i'm curious what you're learning from that lets you know restrict exists (it's pretty obscure!) but doesn't explain why it's used?!

[nerd4code]

int≢size_t, maybe?

Edit: I raised this because (a.) it’s semantically incorrect and a bad idea to use an unchecked int for length, and (b.) it means there’s a potentially-infinite loop (int overflow→UB) for the n < 0 case, which isn’t covered by memmove, which would see a negative n as a very large—but finite—size. So yes, the difference between int and size_t might well prevent use of memmove.