qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stu


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()
Date: Tue, 12 Nov 2013 12:16:11 +0000

On 12 November 2013 12:09, Paolo Bonzini <address@hidden> wrote:
> Il 12/11/2013 12:07, Peter Maydell ha scritto:
>> For the compiler to eliminate this we are relying on:
>>  * dead-code elimination of code following a 'break'
>>    statement in a case block
>>  * constant-folding of "something || 1" to 1
>>  * the compiler having done enough reasoning to be
>>    sure that env is not NULL
>
> Yes, it's not trivial, but there are simpler ways to do it.
>
> For example there is no need to make sure that env is non-NULL, only to
> see that "something || 1" is never zero and thus "if (x) y;" is just
> "(void)x; y;".  This seems easier to me than DCE after "break" which
> clang is able to do.

You seem to be trying to reason about what the compiler
might choose to do or how it might be implemented internally.
I think this is fundamentally misguided. "-O0" means "reduce
compile time and make debugging produce expected results",
not "reduce compile time, make debugging produce expected
results and also run these two optimization passes which
my codebase implicitly relies on happening". gcc currently
happens to do DCE and constant-folding even at -O0 because
it turns out to be faster to do that than not to; if in
future the compilation-speed tradeoff swings the other
way they're free to decide to not do those passes, or to
do cut-down versions that fold less or eliminate less.

I find this argument confusing because to me it's a
completely simple choice with one "obviously right"
and one "obviously wrong" approach :-(

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]