From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7s4B-0001HD-Ls
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 09:51:31 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7s46-0001CT-Tx
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 09:51:30 -0500
Received: from [199.232.76.173] (port=49228 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7s46-0001CH-Lh
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 09:51:26 -0500
Received: from mx20.gnu.org ([199.232.41.8]:36938)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1N7s45-0002UZ-TS
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 09:51:26 -0500
Received: from mail.codesourcery.com ([38.113.113.100])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1N7s44-0002ND-LW
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 09:51:25 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] tcg: add ext{8,16,32}u_i{32,64} TCG ops
Date: Tue, 10 Nov 2009 14:51:21 +0000
References: <e388f3bbe334e3781ff318ce92d1474be6aaa99a.1254512633.git.aurelien@aurel32.net>
In-Reply-To: <e388f3bbe334e3781ff318ce92d1474be6aaa99a.1254512633.git.aurelien@aurel32.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200911101451.21466.paul@codesourcery.com>
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
Cc: Aurelien Jarno <aurelien@aurel32.net>

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.

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.

Paul