From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44229 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PcOMP-0008MY-Fb
	for qemu-devel@nongnu.org; Mon, 10 Jan 2011 15:29:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth@twiddle.net>) id 1PcOMO-0006Ag-HY
	for qemu-devel@nongnu.org; Mon, 10 Jan 2011 15:29:01 -0500
Received: from b.mail.sonic.net ([64.142.19.5]:40813)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth@twiddle.net>) id 1PcOMO-0006AZ-1k
	for qemu-devel@nongnu.org; Mon, 10 Jan 2011 15:29:00 -0500
Message-ID: <4D2B5BC7.8020509@twiddle.net>
Date: Mon, 10 Jan 2011 11:19:35 -0800
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 5/7] tcg-i386: Implement
	deposit	operation.
References: <1294440183-885-1-git-send-email-rth@twiddle.net>
	<1294440183-885-6-git-send-email-rth@twiddle.net>
	<20110109215335.GA21189@volta.aurel32.net>
	<4D2A3CD1.2050003@twiddle.net>
	<20110110183722.GM17026@hall.aurel32.net>
In-Reply-To: <20110110183722.GM17026@hall.aurel32.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
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.nongnu.org/archive/html/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: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>

On 01/10/2011 10:37 AM, Aurelien Jarno wrote:
>> 	mov	y,x
>> 	deposit y,y,x,8,8
>>
>> So I could simply put a tcg_abort there.  It would be up to whoever
>> improves the register allocator to provide some mechanism for a
>> backend to allocate a scratch.  What do you think?
>>
> 
> Do you have a way to trigger this problem? or a dump of the ops and asm
> output?

IN: 
0x408120c4:  rlwimi  r4,r4,8,16,23

OP:
 ---- 0x408120c4
 deposit_i32 r4,r4,r4,8,8
 goto_tb $0x0
 movi_i32 nip,$0x408120c8
 exit_tb $0x7fbb00ca5758

OUT: [size=52]
0x60294380:  mov    0x10(%r14),%ebp
0x60294384:  mov    %ebp,%ebx
0x60294386:  ror    $0x8,%ebp
0x60294389:  shrd   $0x8,%ebx,%ebp
0x6029438d:  rol    $0x10,%ebp
0x60294390:  mov    %ebp,0x10(%r14)
0x60294394:  jmpq   0x60294399
0x60294399:  mov    $0x408120c8,%ebp
0x6029439e:  mov    %ebp,0x25c(%r14)
0x602943a5:  mov    $0x7fbb00ca5758,%rax
0x602943af:  jmpq   0x622b772e

That should do it.  This is present in linux-user-test ppc/ls.
This output still contains that allocate-a-scratch path.


r~