[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: |
Wed, 26 Jun 2019 20:38:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
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"
>> (0x3c800000)
>> 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
>> wonder if
>> it is special somehow? At least a quick search indicates that for 32-bit PPC
>> r2 is
>> supposed to be dedicated as a TOC pointer.
>>
>> Is there a quick way to disable r2 from the list of available registers to
>> see if
>> that gets things going?
>
> Interesting. I'm not sure why that's happening.
>
> As a quick hack,
>
>
> /* For some memory operations, we need a scratch that isn't R0. For the AIX
> calling convention, we can re-use the TOC register since we'll be
> reloading
> it at every call. Otherwise R12 will do nicely as neither a call-saved
> register nor a parameter register. */
> - #ifdef _CALL_AIX
> + #if 0
> # define TCG_REG_TMP1 TCG_REG_R2
> #else
> # define TCG_REG_TMP1 TCG_REG_R12
> #endif
>
>
> 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 ERROR
#endif that _CALL_AIX is *NOT* defined and _CALL_SYSV *is* defined.
I've also tried removing TCG_REG_R2 from tcg_target_reg_alloc_order[] and
tcg_regset_set_reg() for TCG_REG_R2 from tcg_target_init() and I'm still
generating
bad code that writes to r2(!).
Since I can't find any other mentions of TCG_REG_TMP1 and TCG_REG_R2 that isn't
inside an #ifdef _CALL_AIX ... #endif section I'm starting to get stuck. Is
there any
chance that the R_PPC_ADDR32 change could be causing this at all?
ATB,
Mark.
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, (continued)
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/22
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Aleksandar Markovic, 2019/06/23
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/25
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/25
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/25
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/25
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, BALATON Zoltan, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes,
Mark Cave-Ayland <=
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, BALATON Zoltan, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/27
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/27
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/27
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Mark Cave-Ayland, 2019/06/27
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, David Gibson, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Richard Henderson, 2019/06/26
- Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, Aleksandar Markovic, 2019/06/25
Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes, David Gibson, 2019/06/19