qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes
Date: Tue, 25 Jun 2019 18:55:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 25/06/2019 16:56, Richard Henderson wrote:

> On 6/25/19 5:37 PM, Mark Cave-Ayland wrote:
>> The problem is that in tcg/tcg-op.h we define "DEF(dup2_vec, 1, 2, 0, 
>> IMPLVEC |
>> IMPL(TCG_TARGET_REG_BITS == 32))" and in the last patchset dup2_vec isn't 
>> introduced
>> until towards the end. Unfortunately it's not a simple as bringing the patch 
>> forward
>> within the series to maintain bisectability because the current 
>> implementation
>> depends on VMRG which only appears in the patch just before it...
> 
> Ah, that would explain it.  I admit I haven't looked at v5 that closely.

It's actually the same in both patchsets: I'm still playing with v4 at the 
moment
since I have a few hacks in place to help me figure out what's going on.

>> Next to try and figure out what exactly is causing the fault. Just a quick 
>> question
>> out of curiosity: is your Power9 system BE or LE?
> 
> The Power9 is LE.
> 
> I do have access to a Power7 BE system, and that worked last time I checked.
> I'll try that again tomorrow to be sure.

And here's where we are blowing up according to -d in_asm,op_out_asm:

IN:
0x00f22ca0:  101ffc84  vor      v0, v31, v31

OP:
 ld_i32 tmp0,env,$0xfffffff8
 movi_i32 tmp1,$0x0
 brcond_i32 tmp0,tmp1,lt,$L0

 ---- 00f22ca0
 ld_vec v128,e8,tmp2,env,$0xd6b0
 st_vec v128,e8,tmp2,env,$0xd4c0
 movi_i32 nip,$0xf22ca4
 movi_i32 nip,$0xf22ca4
 movi_i32 tmp0,$0x10002
 call raise_exception,$0x2,$0,env,tmp0
 exit_tb $0x0
 set_label $L0
 exit_tb $0xa4e7f0c3

OUT: [size=96]
0xa4e7f120:  81dbfff8  lwz      r14, -8(r27)
0xa4e7f124:  2f8e0000  cmpwi    cr7, r14, 0
0xa4e7f128:  419c004c  blt      cr7, 0xa4e7f174
0xa4e7f12c:  3c400000  lis      r2, 0
0xa4e7f130:  6042d6b0  ori      r2, r2, 0xd6b0
0xa4e7f134:  7c5b10ce  lvx      v2, r27, r2
0xa4e7f138:  3c400000  lis      r2, 0
0xa4e7f13c:  6042d4c0  ori      r2, r2, 0xd4c0
0xa4e7f140:  7c5b11ce  stvx     v2, r27, r2
0xa4e7f144:  3dc000f2  lis      r14, 0xf2
0xa4e7f148:  61ce2ca4  ori      r14, r14, 0x2ca4
0xa4e7f14c:  91db016c  stw      r14, 0x16c(r27)
0xa4e7f150:  7f63db78  mr       r3, r27
0xa4e7f154:  3c800001  lis      r4, 1
0xa4e7f158:  60840002  ori      r4, r4, 2
0xa4e7f15c:  3c000087  lis      r0, 0x87
0xa4e7f160:  6000b618  ori      r0, r0, 0xb618
0xa4e7f164:  7c0903a6  mtctr    r0
0xa4e7f168:  4e800421  bctrl
0xa4e7f16c:  38600000  li       r3, 0
0xa4e7f170:  4bfffef0  b        0xa4e7f060
0xa4e7f174:  3c60a4e7  lis      r3, -0x5b19
0xa4e7f178:  6063f0c3  ori      r3, r3, 0xf0c3
0xa4e7f17c:  4bfffee4  b        0xa4e7f060

Any ideas what might be going on here?


ATB,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]