From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55171)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <av1474@comtv.ru>) id 1TEJil-0003Jx-3V
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:49:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <av1474@comtv.ru>) id 1TEJie-0003eF-Te
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:49:39 -0400
Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:62244 helo=akado.ru)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <av1474@comtv.ru>) id 1TEJie-0003cu-La
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:49:32 -0400
Date: Wed, 19 Sep 2012 16:49:20 +0400 (MSK)
From: malc <av1474@comtv.ru>
In-Reply-To: <CAMo8BfL9pU+ZFLWpsrMmcRXKmw=GKYWoppTuizM5GxgzMguqig@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1209191646110.2485@linmac>
References: <alpine.LNX.2.00.1209182345370.1094@linmac>
	<CAMo8BfL9pU+ZFLWpsrMmcRXKmw=GKYWoppTuizM5GxgzMguqig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [Qemu-devel] Shifts, ppc[64], xtensa
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>

On Wed, 19 Sep 2012, Max Filippov wrote:

> On Tue, Sep 18, 2012 at 11:52 PM, malc <av1474@comtv.ru> wrote:
> >
> > Looks like PPC/PPC64 is also hit by shift issues, on top of that xtensa
> 
> malc, could you please expand a little bit what are these shift issues?
> (sounds like a modern trend, I must have missed something)
> 

Just audit op_opt output of extensa on 32bit host for shr_i32, i'm getting
things like:

OP after optimization and liveness analysis:
 movi_i32 tmp0,$0xd00793f4
 movi_i32 tmp1,$0x1
 movi_i32 tmp2,$0x1
 movi_i32 tmp3,$advance_ccount
 call tmp3,$0x0,$0,env,tmp2
 movi_i32 tmp2,$window_check
 call tmp2,$0x0,$0,env,tmp0,tmp1
 movi_i32 tmp0,$0x1
 add_i32 ar4,ar4,tmp0
 movi_i32 tmp1,$0xd00793f6
 movi_i32 tmp2,$0x3
 movi_i32 tmp3,$0x1
 movi_i32 tmp4,$advance_ccount
 call tmp4,$0x0,$0,env,tmp3
 movi_i32 tmp3,$window_check
 call tmp3,$0x0,$0,env,tmp1,tmp2
 mov_i32 tmp0,ar4
 qemu_ld8u ar12,tmp0,$0x0
 movi_i32 tmp0,$0xffffffe0
 add_i32 ar9,ar12,tmp0
<<<
 movi_i32 tmp1,$0x40
 shr_i32 tmp0,ar9,tmp1
<<<

# I don't get the above
 movi_i32 tmp1,$0xff
 and_i32 ar9,tmp0,tmp1
# Nor the continuation

 movi_i32 tmp0,$0x3
 movi_i32 tmp1,$advance_ccount
 call tmp1,$0x0,$0,env,tmp0
 brcond_i32 ar6,ar9,ltu,$0x0
 nopn $0x2,$0x2
 movi_i32 pc,$0xd0079402
 goto_tb $0x0
 exit_tb $0x4a036c68
 set_label $0x0
 nopn $0x2,$0x2
 movi_i32 pc,$0xd0079430
 goto_tb $0x1
 exit_tb $0x4a036c69
 end

Just adding some debugging printfs to constant shift paths in tcg target
can also be useful.

> > exposed another bug in power's tcg - gototb's target was expected to be
> > always filled via tb_set_jmp_target (even though it's clearly not what
> > tcg/README prescribes, sorry about that).
> 
> 

-- 
mailto:av1474@comtv.ru