Re: [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()

Peter Maydell
2013-11-12T13:22:12Z

On 12 November 2013 13:12, Paolo Bonzini <pbonzini@redhat.com> 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