All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Consult] tilegx: Is it a qemu's system bug?
@ 2015-04-25 15:12 Chen Gang
  2015-04-25 19:30 ` Richard Henderson
  0 siblings, 1 reply; 3+ messages in thread
From: Chen Gang @ 2015-04-25 15:12 UTC (permalink / raw)
  To: Peter Maydell, rth, Chris Metcalf, Andreas Färber,
	Riku Voipio, walt
  Cc: qemu-devel

Hello All:

I want to consult an issue I met below for the latest master branch, is
it a qemu's bug? (it is about ctz/cnttz instruction for tilegx)

  OP: 
   ld_i32 tmp0,env,$0xfffffffffffffffc
   movi_i32 tmp1,$0x0
   brcond_i32 tmp0,tmp1,ne,$L0
   movi_i64 tmp3,$0x0                    /* Initialize tmp3 */
   set_label $L1 
   shr_i64 tmp2,r2,tmp3
   movi_i64 tmp4,$0x1
   and_i64 tmp2,tmp2,tmp4
   movi_i64 tmp4,$0x1
   brcond_i64 tmp2,tmp4,eq,$L2
   movi_i64 tmp4,$0x1
   add_i64 tmp3,tmp3,tmp4
   movi_i64 tmp4,$0x40
   brcond_i64 tmp3,tmp4,ne,$L1
   set_label $L2 
   mov_i64 tmp4,tmp3
   set_label $L0 
   exit_tb $0x7ffff2690013
  
  OP after optimization and liveness analysis:
   ld_i32 tmp0,env,$0xfffffffffffffffc
   movi_i32 tmp1,$0x0
   brcond_i32 tmp0,tmp1,ne,$L0
   set_label $L1                         /* Skip tmp3 initialization */
   shr_i64 tmp2,r2,tmp3                  /* So I guess, qemu can not find tmp3 in shr_i64, so report assertion */
   movi_i64 tmp4,$0x1
   and_i64 tmp2,tmp2,tmp4
   movi_i64 tmp4,$0x1
   brcond_i64 tmp2,tmp4,eq,$L2
   movi_i64 tmp4,$0x1
   add_i64 tmp3,tmp3,tmp4
   movi_i64 tmp4,$0x40
   brcond_i64 tmp3,tmp4,ne,$L1
   set_label $L2 
   set_label $L0 
   exit_tb $0x7ffff2690013
  
  /* begin: I add related printing log in tcg_reg_alloc_op() before assertion */
  opc == 12 /* ld_i32 */
  ===============ts->val_type: 1========================.
  opc == 5  /* movi_i32 */
  opc == 34 /* brcond_i32 */
  ===============ts->val_type: 1========================.
  ===============ts->val_type: 3========================.
  opc == 1  /* set_label */
  opc == 84 /* shr_i64 */
  ============opc = INDEX_op_shr_i64 ====================
  ===============ts->val_type: 2========================.
  ===============ts->val_type: 0========================.
  /* end:   I add related printing log in tcg_reg_alloc_op() before assertion */

  qemu-tilegx: /upstream/qemu/tcg/tcg.c:1982: tcg_reg_alloc_op: Assertion `ts->val_type == 1' failed.


Welcome any ideas, suggestions and completions.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] [Consult] tilegx: Is it a qemu's system bug?
  2015-04-25 15:12 [Qemu-devel] [Consult] tilegx: Is it a qemu's system bug? Chen Gang
@ 2015-04-25 19:30 ` Richard Henderson
  2015-04-25 23:30   ` Chen Gang
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Henderson @ 2015-04-25 19:30 UTC (permalink / raw)
  To: Chen Gang, Peter Maydell, Chris Metcalf, Andreas Färber,
	Riku Voipio, walt
  Cc: qemu-devel

On 04/25/2015 05:12 AM, Chen Gang wrote:
> Hello All:
> 
> I want to consult an issue I met below for the latest master branch, is
> it a qemu's bug? (it is about ctz/cnttz instruction for tilegx)
> 
>   OP: 
>    ld_i32 tmp0,env,$0xfffffffffffffffc
>    movi_i32 tmp1,$0x0
>    brcond_i32 tmp0,tmp1,ne,$L0
>    movi_i64 tmp3,$0x0                    /* Initialize tmp3 */
>    set_label $L1 
>    shr_i64 tmp2,r2,tmp3

You can't keep temporaries live across basic blocks.
That is, across set_label, br, or brcond.  In that case
you'd have to use tcg_new_local_temp() instead.

That said, you shouldn't open-code ctz but instead use
a helper function and use ctz64().


r~

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] [Consult] tilegx: Is it a qemu's system bug?
  2015-04-25 19:30 ` Richard Henderson
@ 2015-04-25 23:30   ` Chen Gang
  0 siblings, 0 replies; 3+ messages in thread
From: Chen Gang @ 2015-04-25 23:30 UTC (permalink / raw)
  To: Richard Henderson, Peter Maydell, Chris Metcalf,
	Andreas Färber, Riku Voipio, walt
  Cc: qemu-devel

On 4/26/15 03:30, Richard Henderson wrote:
> On 04/25/2015 05:12 AM, Chen Gang wrote:
>> Hello All:
>>
>> I want to consult an issue I met below for the latest master branch, is
>> it a qemu's bug? (it is about ctz/cnttz instruction for tilegx)
>>
>>   OP: 
>>    ld_i32 tmp0,env,$0xfffffffffffffffc
>>    movi_i32 tmp1,$0x0
>>    brcond_i32 tmp0,tmp1,ne,$L0
>>    movi_i64 tmp3,$0x0                    /* Initialize tmp3 */
>>    set_label $L1 
>>    shr_i64 tmp2,r2,tmp3
> 
> You can't keep temporaries live across basic blocks.
> That is, across set_label, br, or brcond.  In that case
> you'd have to use tcg_new_local_temp() instead.
> 
> That said, you shouldn't open-code ctz but instead use
> a helper function and use ctz64().
>

Thank you very much for your valuable reply! It will save my much time
resources for analyzing.

And I shall try to let tilegx print "hello world" within this month
(although it seems really difficult to me, at present).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-04-25 23:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-25 15:12 [Qemu-devel] [Consult] tilegx: Is it a qemu's system bug? Chen Gang
2015-04-25 19:30 ` Richard Henderson
2015-04-25 23:30   ` Chen Gang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.