Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

["Igor Kovalenko" <igor.v.kovalenko@gmail.com>]

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