From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
Yang Weijiang <weijiang.yang@intel.com>
Cc: kvm@vger.kernel.org, shuah@kernel.org, peterx@redhat.com,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] selftests: kvm: Fix an unexpected failure with newer gcc compiler
Date: Mon, 17 Aug 2020 19:19:17 +0200 [thread overview]
Message-ID: <7ad0f9fa-bb57-4c19-475b-3439d7a61bcd@redhat.com> (raw)
In-Reply-To: <20200817164238.GD22407@linux.intel.com>
On 17/08/20 18:42, Sean Christopherson wrote:
> On Fri, Aug 14, 2020 at 09:21:05PM +0800, Yang Weijiang wrote:
>> If debug_regs.c is built with newer gcc, e.g., 8.3.1 on my side, then the generated
>> binary looks like over-optimized by gcc:
>>
>> asm volatile("ss_start: "
>> "xor %%rax,%%rax\n\t"
>> "cpuid\n\t"
>> "movl $0x1a0,%%ecx\n\t"
>> "rdmsr\n\t"
>> : : : "rax", "ecx");
>>
>> is translated to :
>>
>> 000000000040194e <ss_start>:
>> 40194e: 31 c0 xor %eax,%eax <----- rax->eax?
>> 401950: 0f a2 cpuid
>> 401952: b9 a0 01 00 00 mov $0x1a0,%ecx
>> 401957: 0f 32 rdmsr
>>
>> As you can see rax is replaced with eax in taret binary code.
>
> It's an optimization. `xor rax, rax` and `xor eax, eax` yield the exact
> same result, as writing the lower 32 bits of a GPR in 64-bit mode clears
> the upper 32 bits. Using the eax variant avoids the REX prefix and saves
> a byte of code.
I would have expected that from binutils though, not GCC.
> Use `xor %%eax, %%eax`. That should always generate a 2 byte instruction.
> Encoding a 64-bit operation would technically be legal, but I doubt any
> compiler would do that in practice.
Indeed, and in addition the clobbers are incorrect since they miss rbx
and rdx. I've sent a patch.
Paolo
next prev parent reply other threads:[~2020-08-17 17:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 13:21 [PATCH] selftests: kvm: Fix an unexpected failure with newer gcc compiler Yang Weijiang
2020-08-17 16:42 ` Sean Christopherson
2020-08-17 17:19 ` Paolo Bonzini [this message]
2020-08-18 13:25 ` Yang Weijiang
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=7ad0f9fa-bb57-4c19-475b-3439d7a61bcd@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=shuah@kernel.org \
--cc=weijiang.yang@intel.com \
/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