Tightening GCCs Memory Model

The middle-ends memory model is that of the C language with additional kludges to support the memory model of C++. See PRs 29286 and 38964.

To summarize

The most extreme consequences one can derive from this are

There are several consequences for optimizations in the face of type-based alias analysis for C++ and C.

Proposed Changes

The proposal is to change the middle-ends memory model to match that of the most extreme interpretation of the C++ memory model:

What are the consequences of this?

All these transformations are usually only performed by scheduling, not by CSE, PRE, load invariant motion or store motion. To carry out these transformations their validity has to be proven using offset-based disambiguation or disambiguation based on points-to analysis.

This should re-assure us that the middle-end will not exploit using the malloc attribute on C++ new operators. Basic arguments that this is safe are

3.7.3.1/2

But then the question is raised on how pointer difference or equivalence relates to the non-aliasing guarantee which the malloc attribute makes.

The most convincing counter-examples are

  char pool[N];
  size_t next;

  /* Never mind that the return memory isn't properly aligned here;
     fixing the implementation is left to the reader.  */
  void *operator new(size_t s) {
     void *p = pool + next;
     next += s;
     return p;
  }

  bool f() {
    char *c = new char;
    return (c == pool);
  }

and

  char *pool;
  void set_pool(char *p) { pool = p; }
  void *operator new(size_t s) { // return stuff from pool. }

  bool f() {
     char *p = new char[1024];
     set_pool (p);
     char *i = new char;
     return (p == i);
  }

but they confuse pointer equality arguments with the aliasing guarantees as shown by

  int *q = new int;
  delete q;
  int *p = new int;
  delete p;
  if (q != p)
    cout << "different";

where we of course may not say that q and p are non-equivalent. Object lifetime is the key here. No examples involving possible invalid optimizations on memory accesses were given.

None: MemoryModel (last edited 2010-04-29 15:59:21 by ManuelLópezIbáñez)