4 ms·

> That is illogical. It's illogical because of poor wording on my part that didn't really match what I wanted to say, yes. Sorry about that. As you noted, a be

> That is illogical. It's illogical because of poor wording on my part that didn't really match what I wanted to say, yes. Sorry about that. As you noted, a better phrasing might be "Optimizations based on ignoring executions that result in undefined behavior is also a form of ignoring the situation". Hopefully that better captures my intent. > Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning. I didn't intend to explain that change in wording because in my opinion it doesn't make a difference as long as the "ignoring the situation" clause remains. > that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. That's one interpretation. The other is to ignore the code that invokes undefined behavior and optimize as if it was not there. > Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". I'm not sure I would necessarily agree that "completely" would preclude evaluating the situation at all, but my command of English is lacking. I think it actually wouldn't matter; given some code that may or may not exhibit UB, there are arguably two ways to end up with only one case to consider: 1. Ignore the code that exhibits UB 2. Ignore the UB and treat the code as conforming Evaluation of the options will have to take place either way, whether it is at compiler run time, compiler design/write time, both, or something else.

kazinator 7y ago
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, ...)
- aw1621107 7y ago
  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.

kazinator 7y ago

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, ...)

aw1621107 7y ago
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.