5 ms·

The model of "pointers are just a number" likely means that even "obvious" optimizations like int i = 0; p = 10; return i; // becomes p = 10; r

by dbaupp 8y ago

The model of "pointers are just a number" likely means that even "obvious" optimizations like int i = 0; *p = 10; return i; // becomes *p = 10; return 0; aren't valid, because p could "just be a number" pointing to i's stack slot.

dingo_bat 8y ago
Can you explain this more? Surely the compiler can reason about p being able to point to i's address.
- dbaupp 8y ago
  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.
antirez 8y ago
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.
- dbaupp 8y ago
  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'.

The model of "pointers are just a number" likely means that even "obvious" optimizations like int i = 0; *p = 10; return i; // becomes *p = 10; r

by dbaupp 8y ago

dingo_bat 8y ago

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

dbaupp 8y ago
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.

antirez 8y ago

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.

dbaupp 8y ago
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'.