qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dan Hoffman <dhoff749@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Eduardo Habkost <eduardo@habkost.net>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	 "Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,  qemu-trivial@nongnu.org
Subject: Re: [PATCH v3] hw/i386: fix short-circuit logic with non-optimizing builds
Date: Sun, 19 Nov 2023 19:34:58 -0600	[thread overview]
Message-ID: <CAFXChKJrXAop188pTFcU0YNPocn_KyiAXiqWoES2F0_==VyO+Q@mail.gmail.com> (raw)
In-Reply-To: <3c44d5a5-818b-46b6-a07f-af655a060032@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]

As far as I can tell, yes. Any optimization level above O0 does not have
this issue (on this version of Clang, at least)

On Sun, Nov 19, 2023 at 4:54 PM Philippe Mathieu-Daudé <philmd@linaro.org>
wrote:

> Hi,
>
> On 19/11/23 21:31, Daniel Hoffman wrote:
> > `kvm_enabled()` is compiled down to `0` and short-circuit logic is
> > used to remove references to undefined symbols at the compile stage.
> > Some build configurations with some compilers don't attempt to
> > simplify this logic down in some cases (the pattern appears to be
> > that the literal false must be the first term) and this was causing
> > some builds to emit references to undefined symbols.
> >
> > An example of such a configuration is clang 16.0.6 with the following
> > configure: ./configure --enable-debug --without-default-features
> > --target-list=x86_64-softmmu --enable-tcg-interpreter
>
> Is the '--enable-debug' option triggering this?
>
> I'm surprised the order of conditions matters for code elision...
>
> > Signed-off-by: Daniel Hoffman <dhoff749@gmail.com>
> > ---
> >   hw/i386/x86.c | 15 ++++++++++++---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> > index b3d054889bb..2b6291ad8d5 100644
> > --- a/hw/i386/x86.c
> > +++ b/hw/i386/x86.c
> > @@ -131,8 +131,12 @@ void x86_cpus_init(X86MachineState *x86ms, int
> default_cpu_version)
> >       /*
> >        * Can we support APIC ID 255 or higher?  With KVM, that requires
> >        * both in-kernel lapic and X2APIC userspace API.
> > +     *
> > +     * kvm_enabled() must go first to ensure that kvm_* references are
> > +     * not emitted for the linker to consume (kvm_enabled() is
> > +     * a literal `0` in configurations where kvm_* aren't defined)
> >        */
> > -    if (x86ms->apic_id_limit > 255 && kvm_enabled() &&
> > +    if (kvm_enabled() && x86ms->apic_id_limit > 255 &&
> >           (!kvm_irqchip_in_kernel() || !kvm_enable_x2apic())) {
> >           error_report("current -smp configuration requires kernel "
> >                        "irqchip and X2APIC API support.");
> > @@ -418,8 +422,13 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
> >       }
> >       cpu->thread_id = topo_ids.smt_id;
> >
> > -    if (hyperv_feat_enabled(cpu, HYPERV_FEAT_VPINDEX) &&
> > -        kvm_enabled() && !kvm_hv_vpindex_settable()) {
> > +    /*
> > +    * kvm_enabled() must go first to ensure that kvm_* references are
> > +    * not emitted for the linker to consume (kvm_enabled() is
> > +    * a literal `0` in configurations where kvm_* aren't defined)
> > +    */
> > +    if (kvm_enabled() && hyperv_feat_enabled(cpu, HYPERV_FEAT_VPINDEX)
> &&
> > +        !kvm_hv_vpindex_settable()) {
> >           error_setg(errp, "kernel doesn't allow setting HyperV
> VP_INDEX");
> >           return;
> >       }
>
>

[-- Attachment #2: Type: text/html, Size: 3809 bytes --]

  reply	other threads:[~2023-11-20  1:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19 20:31 [PATCH v3] hw/i386: fix short-circuit logic with non-optimizing builds Daniel Hoffman
2023-11-19 22:54 ` Philippe Mathieu-Daudé
2023-11-20  1:34   ` Dan Hoffman [this message]
2023-11-20  9:28     ` Michael S. Tsirkin
2023-11-20 10:20       ` Philippe Mathieu-Daudé
2023-11-20 15:30         ` Richard Henderson
2023-11-21 16:15         ` Eric Blake
2023-11-21 18:28           ` Dan Hoffman
2023-11-22  1:24             ` Dan Hoffman
2023-11-23 18:03               ` Dan Hoffman

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='CAFXChKJrXAop188pTFcU0YNPocn_KyiAXiqWoES2F0_==VyO+Q@mail.gmail.com' \
    --to=dhoff749@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=richard.henderson@linaro.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;
as well as URLs for NNTP newsgroup(s).