On 27/06/2019 18:54, Richard Henderson wrote:
> On 6/27/19 7:51 PM, Richard Henderson wrote:
>> Please try the following patch on top and if it works I'll split it back into
>> the patch set properly.
>
> Dangit. I generated the patch on the wrong machine.
> Let's try that again.
Yes it works!
On 6/27/19 7:51 PM, Richard Henderson wrote:
> Please try the following patch on top and if it works I'll split it back into
> the patch set properly.
Dangit. I generated the patch on the wrong machine.
Let's try that again.
r~
diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
in
On 6/27/19 7:24 PM, Mark Cave-Ayland wrote:
> For the TCG_TYPE_V128 case we have ret = TCG_REG_V2 but (ret & 31) masks
> off the top bit which converts this to TCG_REG_R2 and that's why
> tcg_out_mem_long() starts using r2 to calculate offsets.
Oh geez. Ok, I see it now.
> case TCG_TYPE_V12
On 26/06/2019 20:38, Mark Cave-Ayland wrote:
>> But I thought that _CALL_AIX was only defined for ppc64 elf version 1. I
>> thought that ppc32 used _CALL_SYSV instead. Certainly that's what is used
>> elsewhere...
>
> No, that didn't work either. I've confirmed using #ifdef _CALL_AIX #error
>
On Wed, 26 Jun 2019, Mark Cave-Ayland wrote:
On 26/06/2019 19:42, Richard Henderson wrote:
On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:
Interestingly if I set a trap and then switch the opcode to "lis r4,0"
(0x3c80)
then we carry on as normal until the next "lis r2,0" instruction. Looking
On 26/06/2019 19:42, Richard Henderson wrote:
> On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:
>> Interestingly if I set a trap and then switch the opcode to "lis r4,0"
>> (0x3c80)
>> then we carry on as normal until the next "lis r2,0" instruction. Looking
>> through the
>> whole output of -d
On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:
> Interestingly if I set a trap and then switch the opcode to "lis r4,0"
> (0x3c80)
> then we carry on as normal until the next "lis r2,0" instruction. Looking
> through the
> whole output of -d out_asm this is the first mention of r2 which makes me
On 6/26/19 10:33 AM, David Gibson wrote:
>>> out of curiosity: is your Power9 system BE or LE?
>>
>> The Power9 is LE.
>
> It's the kernel determines endianness, not the system.
Yes. Lazy verbiage on my part -- I did mean "The Power9 that I have access to
is configured as LE".
r~
On Wed, 26 Jun 2019, Mark Cave-Ayland wrote:
On 26/06/2019 08:45, Richard Henderson wrote:
On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:
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,$0xfff8
movi_
On 26/06/2019 08:45, Richard Henderson wrote:
> On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:
>> 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,$0xfff8
>> movi_i32 tmp1,$0x0
>> brcond
g
On Tue, Jun 25, 2019 at 05:56:42PM +0200, 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
On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:
> 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,$0xfff8
> movi_i32 tmp1,$0x0
> brcond_i32 tmp0,tmp1,lt,$L0
>
> 00f22ca0
> ld_vec v128
On Jun 25, 2019 5:42 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
pa
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. U
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
On 25/06/2019 07:56, Richard Henderson wrote:
>>> One more hint: if I try a build of d8dcbb57e9 along with my
>>> tcg_can_emit_vec_op()
>>> hack and pass --enable-debug-tcg to configure then I get an assert on
>>> startup:
>>>
>>> qemu-system-ppc: /home/mca/src/qemu/tcg/tcg.c:2207: process_op_de
On 6/23/19 7:10 PM, Aleksandar Markovic wrote:
> On Sat, Jun 22, 2019 at 5:02 PM Mark Cave-Ayland
> wrote:
>>
>> On 22/06/2019 15:20, Mark Cave-Ayland wrote:
>>
>>> I've just given your tcg-ppc-vsx branch a spin here, and like Howard I'm
>>> getting
>>> segfaults trying to launch my MacOS images
On Sat, Jun 22, 2019 at 5:02 PM Mark Cave-Ayland
wrote:
>
> On 22/06/2019 15:20, Mark Cave-Ayland wrote:
>
> > I've just given your tcg-ppc-vsx branch a spin here, and like Howard I'm
> > getting
> > segfaults trying to launch my MacOS images :( The segfault is weird: it
> > doesn't get
> > cau
On 22/06/2019 15:20, Mark Cave-Ayland wrote:
> I've just given your tcg-ppc-vsx branch a spin here, and like Howard I'm
> getting
> segfaults trying to launch my MacOS images :( The segfault is weird: it
> doesn't get
> caught by an attached gdb and the qemu-system-ppc process seems to hang
>
On 19/06/2019 06:07, Mark Cave-Ayland wrote:
> On 18/06/2019 06:00, Richard Henderson wrote:
>
>> Ping. Otherwise I'll include it in my next tcg pull.
>>
>> r~
>
> I can give this another spin on my test images on a G4 over the next few
> days. I've
> also added Howard on CC as he reported som
Hi,
As reported before, qemu-system-ppc still crashes with a segmentation fault
on Lubuntu 16 on a G5. Built from current tcg-ppc-vsx branch.
Linux hsp-G5-Lubuntu 4.4.0-143-powerpc64-smp #169-Ubuntu SMP Thu Feb 7
08:25:49 UTC 2019 ppc64 ppc64 ppc64 GNU/Linux
hsp@hsp-G5-Lubuntu:~$ gcc -v
Using bu
On Mon, Jun 17, 2019 at 10:00:10PM -0700, Richard Henderson wrote:
> Ping. Otherwise I'll include it in my next tcg pull.
Uh.. I'm not sure who this ping is directed at. I'm afraid this
series has dropped off my radar.
>
>
> r~
>
> On 5/18/19 9:15 PM, Richard Henderson wrote:
> > Based-on: <
On 18/06/2019 06:00, Richard Henderson wrote:
> Ping. Otherwise I'll include it in my next tcg pull.
>
> r~
I can give this another spin on my test images on a G4 over the next few days.
I've
also added Howard on CC as he reported some issues with the previous iteration
at
https://lists.gnu.o
Ping. Otherwise I'll include it in my next tcg pull.
r~
On 5/18/19 9:15 PM, Richard Henderson wrote:
> Based-on: <20190518190157.21255-1-richard.hender...@linaro.org>
> Aka "tcg: misc gvec improvements".
>
> Version 3 was last posted in March,
> https://lists.gnu.org/archive/html/qemu-devel/20
Based-on: <20190518190157.21255-1-richard.hender...@linaro.org>
Aka "tcg: misc gvec improvements".
Version 3 was last posted in March,
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg05859.html
Changes since v3:
* Add support for bitsel, with the vsx xxsel insn.
* Rely on the new rel
25 matches
Mail list logo
