Re: [Qemu-devel] [PATCH 1/3] tcg: add ext{8,16,32}u_i{32,64} TCG ops

[Aurelien Jarno]

On Tue, Nov 10, 2009 at 02:51:21PM +0000, Paul Brook wrote:
> On Wednesday 30 September 2009, Aurelien Jarno wrote:
> > Currently zero extensions ops are implemented by a and op with a
> > constant. This is then catched in some backend, and replaced by
> > a zero extension instruction. While this works well on RISC
> > machines, this adds a useless register move on non-RISC machines.
> > 
> > Example on x86:
> >   ext16u_i32 r1, r2
> > is translated into
> >   mov    %eax,%ebx
> >   movzwl %bx, %ebx
> > while the optimized version should be:
> >   movzwl %ax, %ebx
> 
> I don't like your solution. Having two operations that do the same thing is 
> bad, especially when we have no way of converting one into the other, and no 
> clear indication which is best.

We don't have to operations, we have a few optional operations (ext*u) 
that are implemented with andi on TCG targets that don't support it. This
is the same as ext*s which is not always implemented natively.

> I think we need to understand why does the original code introduces an extra 
> copy. At first glance there's no good reason for it to be there.

That's easy to understand. ext16u_i32 r1, r2 is translated into 
andi r1, r2, 0xffff, that is:

  movi_i32 tmp0, 0xffff
  and r1, r2, tmp0

On x86*, and is defined as:

  { INDEX_op_and_i32, { "r", "0", "ri" } },

That is the first the argument is an alias to the output. This is
therefore converted into (even if this is never represented this way
inside TCG):

  movi_i32 tmp0, 0xffff
  mov r1, r2
  and r1, r1, tmp0

The x86 TCG target has some special cases for the and implementation
and converts it to the movzwl instruction instead of and + immediate.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net