From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HSI9E-0003E9-3H
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 15:31:32 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HSI9C-0003Dw-LH
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 15:31:31 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HSI9C-0003Dt-GX
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 14:31:30 -0500
Received: from nf-out-0910.google.com ([64.233.182.186])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <igor.v.kovalenko@gmail.com>) id 1HSI83-000632-4S
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 15:30:19 -0400
Received: by nf-out-0910.google.com with SMTP id c31so698943nfb
	for <qemu-devel@nongnu.org>; Fri, 16 Mar 2007 12:30:17 -0700 (PDT)
Message-ID: <b2fa41d60703161230p631a886fp94906fcd51f71747@mail.gmail.com>
Date: Fri, 16 Mar 2007 22:30:17 +0300
From: "Igor Kovalenko" <igor.v.kovalenko@gmail.com>
Subject: Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code
In-Reply-To: <200703161415.21283.jseward@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200703161415.21283.jseward@acm.org>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 3/16/07, Julian Seward <jseward@acm.org> wrote:
>
> I'm seeing redundant repz (0xF3) prefixes in generated code, typically
> just before jumps:
>
> <code_gen_buffer+415>:  repz mov $0xe07f,%eax
> <code_gen_buffer+421>:  mov    %eax,0x20(%rbp)
> <code_gen_buffer+424>:  lea    -25168302(%rip),%ebx  # 0xaf0420 <tbs+96>
> <code_gen_buffer+430>:  retq
> <code_gen_buffer+431>:  mov    -25168245(%rip),%eax  # 0xaf0460 <tbs+160>
> <code_gen_buffer+437>:  jmpq   *%rax
> <code_gen_buffer+439>:  repz mov $0xe092,%eax
> <code_gen_buffer+445>:  mov    %eax,0x20(%rbp)
> <code_gen_buffer+448>:  lea    -25168325(%rip),%ebx   # 0xaf0421 <tbs+97>
> <code_gen_buffer+454>:  retq
>
> I assume these are something to do with translation chaining/unchaining but
> have been unable to figure out where they come from.  I know they get executed
> are so are not data - valgrind barfs on them.
>
> This is on a 64-bit host (Core 2) with qemu-0.9.0 compiled from source by
> gcc-3.4.6, running an x86 (32-bit) guest.
>
> At a guess I'd say the mov $imm,%eax is (created by? to do with?)
> gen_jmp_im in target-i386/translate.c, but I don't see how the F3
> got in on the act.  Grepping the source for 0xF3 turns up nothing
> plausible.  Any ideas where it comes from and how to get rid of it?
>

Try -mtune=nocona something like the following

Index: Makefile.target
===================================================================
RCS file: /cvsroot/qemu/qemu/Makefile.target,v
retrieving revision 1.147
diff -u -r1.147 Makefile.target
--- Makefile.target     28 Feb 2007 21:36:41 -0000      1.147
+++ Makefile.target     16 Mar 2007 19:29:04 -0000
@@ -99,6 +99,7 @@
 endif

 ifeq ($(ARCH),x86_64)
+OP_CFLAGS+= -mtune=nocona -W -Wall -O4
 BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
 endif


-- 
Kind regards,
Igor V. Kovalenko