Am So., 17. Dez. 2023 um 09:50 Uhr schrieb Paul Eggert <egg...@cs.ucla.edu>:
> On 2023-12-16 04:42, Marc Nieper-Wißkirchen wrote: > > the problem is if further down in the compiler pipeline, the > > P <= P expression produces some intermediate code that becomes equal to > > code the optimizer should rightfully optimize away > > I'm skeptical that such optimizations would be worth the trouble in > practice, because any optimization where P==P does not imply P<=P would > run contrary to common sense and programmer intuition. The C standard is full of such examples "contrary to common sense", and in related areas (e.g. comparison/overflow of (un)signed integers) optimizers are already using these. > In practice, > compiler writers who'd employ such optimizations would likely cause more > trouble than they'd cure, and I wouldn't want to encourage them. > > If I'm wrong, and in the future these optimizations become valuable and > break programs like Coreutils, we can revisit the issue then. In the > meantime let's leave these sleeping dogs lie. I have little doubt that > Bruno has missed many of the issues and it'd be a waste of our time to > try to find the rest of them. > We don't have to hunt all these issues, but we should correct those we find. The C standard has always favoured the freedom of compiler writers for efficiency, so it is definitely not wrong by its own measures. It may not be the best decision for every application area, but there are other programming languages besides C.
