>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.
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".