Can you explain this more? Surely the compiler can reason about p being able to point to i's address.

p could be

  int *p = rand();

or that code could be in a function

  int f(int *p)

which may be called from completely different compilation units (or even across a dynamic library boundary) meaning there's no way for the compiler to know what p is.

I don't claim that the compiler should avoid any kind of optimizations because pointers are numbers, but that the formal model should be that the compiler can ignore certain loads/stores in certain paths, rather than overloading of semantical value the pointer itself. It's just a different POV that one could use to analyze what happens. Similarly, different statements should be used in order to specify how rigid we want the compiler to be with our loads/stores for a given pointer, so that certain optimizations that are obvious like the one above are the default, and others are performed only if the pointer is specified via keywords and other annotations to have a very special meaning.

How exactly does the model specify which loads/stores are okay to be ignored or reordered (etc.)? I feel like anything that gets close to the essence of the C/C++/Rust model (such as allowing the optimization in my example above), ends up with something pretty similar to the "allocation id" idea.

As a specific example, consider the difference between these two versions of my example above:

  int f() {
    int i = 0;
    *(&i) = 10;
    return i;
  }

and the original:

  int g(int *p) {
    int i = 0;
    *p = 10;
    return i;
  }

If a call like g(rand()) ends up with p == &i, the unoptimized versions of that and of an f() call execute exactly the same sequence of memory accesses, and yet the optimization I mention above only applies to g. In essence, the source of the number "&i" seems to matter.

> others are performed only if the pointer is specified via keywords and other annotations to have a very special meaning.

Some of this already exists, such as 'restrict'.