[Bug rtl-optimization/89479] New: __restrict

[eyalroz at technion dot ac.il]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479

            Bug ID: 89479
           Summary: __restrict
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

(This is all illustrated at: https://godbolt.org/z/nz2YXE )

Let us make our language C++17. Consider the following function:

  int foo(const int* x, void g())
  {
      int result = *x;
      g();
      result += *x;
      return result;
  }

since we have no aliasing guarantees, we must assume the invocation of g() may
change the value at address x, so we must perform two reads from x to compute
the result - one before the call and one after.

If, however, we add __restrict__ specifier to x:

  int bar(const int* __restrict__ x, void g())
  {
      int result = *x;
      g();
      result += *x;
      return result;
  }

we may assume x "points to an unaliased integer" (as per
https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html ). That means we
can read from address x just once, and double the value to get our result. I
realize there's a subtle point here, which is whether being "unaliased" also
applies to g()'s behavior. It is my understanding that it does.

Well, clang 7.0 understands things they way I do, and indeed optimizes one of
the reads away in `bar()`. But - g++ 8.3 (and g++ "trunk", whatever that means
on GodBolt) doesn't do so, and reads _twice_ from x both in `foo()` and in
`bar()`.