Re:Pointers Are Complicated, or What’s in a Byte?
by antirez on Wednesday July 25, 2018 @08:14AM
(#17608637)
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.
Re:Pointers Are Complicated, or What’s in a Byte?
by vardump on Wednesday July 25, 2018 @09:15AM
(#17608977)
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.
Re:Pointers Are Complicated, or What’s in a Byte?
by antirez on Wednesday July 25, 2018 @10:22AM
(#17609437)
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.
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.