public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Gleb Natapov <gleb@redhat.com>, kvm-devel <kvm@vger.kernel.org>,
	Patch Tracking <patches@linaro.org>,
	Andreas Tobler <andreast@freebsd.org>,
	Anthony Liguori <aliguori@amazon.com>
Subject: Re: [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()
Date: Tue, 12 Nov 2013 13:09:06 +0100	[thread overview]
Message-ID: <52821A62.2050001@redhat.com> (raw)
In-Reply-To: <CAFEAcA8UjSRze-Zz1jdE2sS0GM5ihfoN5Dz6Gj8MPF_iXUOewA@mail.gmail.com>

Il 12/11/2013 12:07, Peter Maydell ha scritto:
> On 11 November 2013 23:21, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> We're not talking about something obscure here.  It's eliminating an
>> if(0) block.
> 
> No, we're not talking about a simple "if (0)" expression.
> What we had in this case was
>  if (!(env->features[FEAT_1_ECX] & CPUID_EXT_XSAVE) || !kvm_enabled()) {
>     break;
>  }
>  [stuff using kvm_arch_get_supported_cpuid()]
> 
> [where kvm_enabled() is #defined to constant-0].
> 
> 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.

Indeed, NULL checks (except perhaps very simple checks like &x != NULL)
are not something I'd expect the compiler to optimize out at -O0.

> You and Paolo have both mentioned "doing checks
> at compile time" but why is this particular
> detail of our code worth checking in that way
> at the expense of reliably being able to compile?
> 
> As it happens, having a stub function that returns
> 0 would simplify several bits of code that currently
> do:
> 
>         if (kvm_enabled() && cpu->enable_pmu) {
>             KVMState *s = cs->kvm_state;
> 
>             *eax = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EAX);
>             *ebx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EBX);
>             *ecx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_ECX);
>             *edx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EDX);
>         } else {
>             *eax = 0;
>             *ebx = 0;
>             *ecx = 0;
>             *edx = 0;
>         }
> 
> because you could get rid of the else block.

No, you couldn't because the "else" branch runs for "kvm_enabled() &&
!cpu->enable_pmu" too.  Relying on kvm_arch_get_supported_cpuid to
return 0 would only make code harder to review, and the above example
shows this fact very well.

kvm_arch_get_supported_cpuid abort()-ing would be fine, but it would
also make code harder to review, because you cannot rely anymore on the
compiler-linker combo to filter out the most obvious cases of forgetting
about TCG's existence.

> Or you could #ifdef CONFIG_KVM this code section,
> as we already do for some of the more complicated
> bits of code that call this function. That would
> work too.

Yes, but it wouldn't be _right_.  Most of the code below the "break" is
potentially applicable to TCG, even if it is not used now.

Paolo

  reply	other threads:[~2013-11-12 12:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 21:22 [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() Peter Maydell
2013-11-11 21:28 ` Andreas Tobler
2013-11-11 22:19 ` Paolo Bonzini
2013-11-11 22:38   ` Peter Maydell
2013-11-11 23:11     ` Paolo Bonzini
2013-11-11 23:21       ` Anthony Liguori
2013-11-12  7:09         ` Paolo Bonzini
2013-11-12 11:07         ` Peter Maydell
2013-11-12 12:09           ` Paolo Bonzini [this message]
2013-11-12 12:16             ` Peter Maydell
2013-11-12 13:12               ` Paolo Bonzini
2013-11-12 13:21                 ` Peter Maydell
2013-11-12 13:26                   ` Gleb Natapov
2013-11-12 13:23                 ` Gleb Natapov
2013-11-12 13:57                   ` Paolo Bonzini
2013-11-12 14:09                     ` Gleb Natapov
2013-11-12 14:14                       ` Peter Maydell
2013-11-12 14:57                       ` Paolo Bonzini
2013-11-12 15:13                         ` Peter Maydell
2013-11-12 15:21                           ` Paolo Bonzini
2013-11-12 15:32                             ` Peter Maydell
2013-11-12 15:58                               ` Paolo Bonzini
2013-11-12 16:08                                 ` Peter Maydell
2013-11-12 17:04                                   ` Anthony Liguori
2013-11-12 17:20                                     ` Peter Maydell
2013-11-12 18:54                                     ` [Qemu-devel] " Richard Henderson
2013-11-12 18:57                                       ` Peter Maydell
2013-11-12 19:15                                         ` Stefan Weil
2013-11-12 22:53                                       ` [Qemu-devel] " Paolo Bonzini
2013-11-13  2:27                                         ` Richard Henderson
2013-11-13  7:25                                           ` Paolo Bonzini
2013-11-13 22:23                                             ` Peter Maydell
2013-11-13  7:26                                           ` Gleb Natapov
2013-11-12 14:01                 ` Peter Maydell
2013-11-11 23:23       ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52821A62.2050001@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=andreast@freebsd.org \
    --cc=anthony@codemonkey.ws \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox