I think the only fact that rescues this situation is that in the same paragraph, there is wording which assures the implementor that UB "imposes no requirements" (famous fact everyone basically knows). The later "permissible" is an unfortunate word that appears to give requirements. Without the "imposes no requirements" to contradict that word, it would be a lot more troublesome.
I wrote a detailed reponse to the blogger, which is "awaiting moderation". I not only point out that the C89 wording is contradictory, which justifies the replacement of the word, but that all sorts of common, useful optimizations are predicated on the absence of the program's reliance on undefined behavior.
If we cannot optimize based on the absence of undefined behavior, we cannot cache variables in registers or do CSE, or only in a lot fewer possible cases.
At best we can do back-end things that just improve the compiler's output without regard for the original program (optimal allocation of real registers to pseudo-registers, peephole optimization, jump threading, ...)
If your comment never makes it out of moderation limbo (or maybe even if it does), would you mind posting it here?
How does not being able to assume the absence of UB prevent optimizations like those you listed? Not that I'm doubting you; this is an area I'm not very familiar with.
I wrote a detailed reponse to the blogger, which is "awaiting moderation". I not only point out that the C89 wording is contradictory, which justifies the replacement of the word, but that all sorts of common, useful optimizations are predicated on the absence of the program's reliance on undefined behavior.
If we cannot optimize based on the absence of undefined behavior, we cannot cache variables in registers or do CSE, or only in a lot fewer possible cases.
At best we can do back-end things that just improve the compiler's output without regard for the original program (optimal allocation of real registers to pseudo-registers, peephole optimization, jump threading, ...)