Re: [Qemu-devel] [PATCH 03/22] tcg-i386: Tidy ext8u and ext16u operations.

[Richard Henderson <rth@twiddle.net>]

On 05/18/2010 11:47 PM, Aurelien Jarno wrote:
> The reg allocator is able to issue move if needed, so the only
> improvement this patch is for doing a ext8u on both "q" registers.
> 
> OTOH the reg allocator knows this situation and will try to avoid this
> situation during the allocation. Cheating on the reg allocator might
> have some wrong effects, especially after your patch "Allocate
> call-saved registers first". I am thinking of the scenario where the
> value is in memory (which is likely to be the case given the limited 
> number of registers), it will be likely loaded in a "r" register (they
> are now at the top priority), and then ext8u will be called, which will 
> issue "mov" + "and" instructions instead of a "movzbl" instruction.

The case I was concerned with is the fact that if we have a value
allocated to, say, %esi, and we need to to an ext8u, then the 
register allocator has been told that it must move the value to a
"q" register in order to perform the movzbl.  In this case, the
new code will simply emit the andl.

I.e. the real problem is that we've told the register allocator
one way that the extend can be implemented, but not every way.

> All of that is purely theoretical. Do you know how does it behave in 
> practice?

Picking the i386 target since it seems to use more extensions than
any other target, from linux-user-test -d op_opt,out_asm i386/ls:

There are 176 instances of ext8u.
Of those, 83 instances are in-place, i.e. "ext8u_i32 tmp0,tmp0"

I examined the first 2 dozen appearances in the output assembly:

There are several instances of the value being in an "r" register:

 shr_i32 tmp1,edx,tmp13
 ext8u_i32 tmp1,tmp1
 =>
0x601c5468:  shr    $0x8,%edi
0x601c546b:  and    $0xff,%edi

All of the instances that I looked at that were not in-place happened
to already be using a "q" register -- usually %ebx.  I assume that's
because we place %ebx as the first allocation register and that's just
how things happen to work out once we've flushed the registers before
the qemu_ld.

 qemu_ld8u tmp0,tmp2,$0xffffffff
 ext8u_i32 tmp13,tmp0
 =>
0x601c82f9:  movzbl (%esi),%ebx
0x601c82fc:  movzbl %bl,%ebx


r~