4 ms·

> Here the author is constructing a theory based all on true statements, but the mental model he builds, which is philosophically valid, is IMHO not the best ch

> Here the author is constructing a theory based all on true statements, but the mental model he builds, which is philosophically valid, is IMHO not the best choice in order to really address and simplify those concepts On the contrary, I feel those concepts are great for reasoning about code on a symbolic level. Which is what a compiler is all about. > In this declination a pointer is just a number, the problem is that certain programming statements in C/C++ that... Wouldn't this mean the compiler will need to generate a more memory loads and stores that could otherwise be proven redundant? It'll need to assume a store through a pointer 'a' at index unknown at compilation time can modify data at pointer 'b', even though it could otherwise deduce there's no aliasing.

antirez 8y ago
I meant to only change the reasoning the author is used in terms of optimizations being the ability to ignore loads/stores versus giving more semantical value to a pointer.
- vardump 8y ago
  You need that semantic information for a pointer to reason about loads and stores to memory blocks. (This semantic information exists only during compiling process.) The compiler needs semantic data to answer questions like "can an access through pointer A access data visible through pointers B and C?" If it doesn't know that, it'll need to generate those redundant memory accesses. Before storing (or loading) through A, it'll need to store temporary values previously written to B and C. After a store through pointer A, it might need to load B and C values again for more computation, because a store to A might have modified them.
  - antirez 8y ago
    Yes, but giving each pointer metadata for the goal of saying, at compile time, I can ignore or not certain access patterns in this pointer, is conceptually different (but practically the same, it's just a POV) of saying that a pointer is not just a number. Both ways are ok to represent things, but I've the feeling that saying "a pointer is not just a number" in some way allows the ANSI-C culture of UBs to be culturally validated. Moreover, the definition given in the blog post, is also far from the actual nature of machines, where actually a load/store operation for this number will result in the same operation.

antirez 8y ago

I meant to only change the reasoning the author is used in terms of optimizations being the ability to ignore loads/stores versus giving more semantical value to a pointer.

vardump 8y ago
You need that semantic information for a pointer to reason about loads and stores to memory blocks. (This semantic information exists only during compiling process.) The compiler needs semantic data to answer questions like "can an access through pointer A access data visible through pointers B and C?" If it doesn't know that, it'll need to generate those redundant memory accesses. Before storing (or loading) through A, it'll need to store temporary values previously written to B and C. After a store through pointer A, it might need to load B and C values again for more computation, because a store to A might have modified them.
- antirez 8y ago
  Yes, but giving each pointer metadata for the goal of saying, at compile time, I can ignore or not certain access patterns in this pointer, is conceptually different (but practically the same, it's just a POV) of saying that a pointer is not just a number. Both ways are ok to represent things, but I've the feeling that saying "a pointer is not just a number" in some way allows the ANSI-C culture of UBs to be culturally validated. Moreover, the definition given in the blog post, is also far from the actual nature of machines, where actually a load/store operation for this number will result in the same operation.