What I don’t get is why this is not a safe optimization. Obviously, there is some room for discussion here, since the Intel people seem to consider it unsafe and the gcc people do not. David Howard hints in an earlier comment that “A[i][j-1] could be aliased with a pointer somewhere else” - but where should that somewhere else be? After all, this is not a volatile variable and we are not even talking about multiple threads here (and even if we did - most memory models from threaded systems I know would still allow it). So I am afraid I don’t get it. Can anyone enlighten me as to why this optimization is not safe? Thanks a lot.

As I said, it’s not register allocation; it’s whether or not the read from A[i][j-1] has to wait for the previous write to A[i][j] (when j was 1 less) to complete, because the processor *itself* can’t tell that that the read is just recycling a value. In modern CPU architectures, writes can proceed asynchronously - but any subsequent reads from the same address (especially in the presence of multiprocessor systems) must wait for the write to complete first. I’m guessing that gcc spots that the read will actually fetch back the same value that was just written and substitutes in a temp to avoid that - but that’s actually not a safe optimisation, so I’m not too surprised the Intel compiler didn’t go for it.

[

]

franjesus: the comments preview plugin I used turns all my articles into blank pages, not going to turn it on again.

#include

#include \

#include \

Preview of comments would be nice

I would expect the compiler is not allowed to move the expression from the line

A[i][j] = A[i][j - 1] + 3;

into a register because A[i][j-1] could be aliased with a pointer somewhere else. using the 'temp' variable eliminates the aliasing problem. So the slow version with the A[i][j-1] is forced to do an access to memory in the inner loop that is not present in the original or final optimization.