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: 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.



reply via email to

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