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

[Julian Seward <jseward@acm.org>]

On Friday 16 March 2007 14:28, Paul Brook wrote:
> On Friday 16 March 2007 14:15, Julian Seward 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.
>
> 0000000000008b50 <op_goto_tb1>:
>     8b50:       8b 05 00 00 00 00       mov    0(%rip),%eax
>                         8b52: R_X86_64_PC32     __op_param1+0x3c
>     8b56:       ff e0                   jmpq   *%rax
>     8b58:       f3 c3                   repz retq
>
> qemu only strips the final ret off.
> The prefixed ret is to avoid prefetch stalls on amd cpus.

So the implication of this is that the generated code just happens to
work only because the dangling F3 never ends up in front of some other
instruction which it would change the meaning of?

J