Hacker News Reader

Comment by atq2119 | Hacker News Reader

In the input to the final optimization, there is only one store between the place where q is allocated and the place where q is used.

That one store is clearly identified as going into p, not into q.

Therefore, it's quite reasonable to conclude that q has not been changed.

If we weren't allowed to conclude that, we would almost never be able to put stack variables into registers, and that would make even simple programs run a lot slower.

(The other point, which is another argument that it's the second optimization that should be considered incorrect, is that the program before the final optimization has a store to p[1], which is an out-of-bounds access into an array, which should be considered an error in all reasonable programming languages.)

View on HN

>In the input to the final optimization, there is only one store between the place where q is allocated and the place where q is used. That one store is clearly identified as going into p, not into q.

> Therefore, it's quite reasonable to conclude that q has not been changed.

No, that is in fact unreasonable and does not follow at all.

You are completely ignoring any relationships the program might have established between the two at the point at which *(p+1) is written to. [1]

Namely, you are ignoring that the program has already established iq == ip at that point. Which means the program already established (uintptr_t)q == (uintptr_t)(p+1). Which means the program already established q == p + 1. (NOTE: I am not writing C code here. See [1].) Which means *q == *(p + 1). Thus in the last optimization you must assume *q may have been modified. Of course you (the compiler) are welcome to give up on analyzing that chain of logic at any point at which it seems too difficult, but if you break that chain of logic, you cannot make violating assumptions in a subsequent step.

[1] https://news.ycombinator.com/item?id=42907292

You are making the assumption that all optimizations see everything, but that's not the case. The third optimization never got a chance to observe that relationship. This means that either:

- the third optimization should assume that _any_ relationship between two expressions could have been established before it runs (even if that relationship was never established!)

- one of the first two optimizations is also wrong because it did not give subsequent optimizations the chance to observe that relationship.

> one of the first two optimizations is also wrong because it did not give subsequent optimizations the chance to observe that relationship.

If you view them as actual equivalent C code, sure. In which case, be my guest at saying those are wrong. But I think you're conflating actual C with the imitation-C used to represent the LLVM IR in the article. I responded to this here: https://news.ycombinator.com/item?id=42907292

You mention that the compiler should track the aliasing informations, as to enrich this C imitation language, but this seems exactly what the article means with "provenance".

Reply on news.ycombinator.com