On 12 November 2013 13:12, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > I'm saying it's *reasonable* to expect that "-O0" means "reduce compile > time, make debugging produce expected results, and try (not too hard) to > not break what works at -O2". And that's what we've got. There's no requirement, even at -O2, to eliminate all dead code. It's just a QoI issue for optimization. If your code is busted it's busted and that might show up only at -O0 or only at -O2 (the latter in fact is pretty common because of the tendency to only do dataflow analysis at higher levels). > It's a simple QoI argument based on the > fact that people *will* switch back and forth between -O2 and -O0. Of > course not everything can be kept to work, since the compilers do pretty > surprising optimizations (not counting the ones that break your code of > course...). But I think a limited amount of dead code elimination > *should* be expected because most people are now preferring "if" to > "#ifdef" for compiling out code. If your code isn't wrong then "if (0)" works just fine for compiling out code that isn't used. In an optimized build it gets eliminated; in an non-optimized build you don't care if it gets eliminated or not, it's no big deal. The reason for using "if (0)" rather than #ifdefs is "an optimizing compiler will make this no less efficient for our release builds"; that doesn't mean you can rely on it being optimal when you've specifically asked for a non-optimizing build, and it doesn't mean you can put code in the "if (0)" that's broken. (Similarly, you can put code that's a syntax error inside #if 0, but that won't work inside an "if (0)". The solution is not to do that.) -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
