[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-devel
Subject:    Re: [PATCH v3 25/30] target/ppc: Move ADDI, ADDIS to decodetree, implement PADDI
From:       "Matheus K. Ferst" <matheus.ferst () eldorado ! org ! br>
Date:       2021-04-30 23:29:33
Message-ID: 7b81c95b-e661-68be-dd55-224882182038 () eldorado ! org ! br
[Download RAW message or body]

On 30/04/2021 15:43, Richard Henderson wrote:
> On 4/30/21 11:02 AM, Matheus K. Ferst wrote:
>>> But in this case ADDI probably doesn't use PLS_D.  You could use
>>> 
>>> static bool trans_PADDI(DisasContext *ctx, arg_PLS_D *a) { arg_D 
>>> d; if (!resolve_PLS_D(ctx, &d, a)) { return false; } return 
>>> trans_ADDI(ctx, &d); }
>>> 
>>> making sure to use int64_t in the offset for arg_D.
>>> 
>> 
>> We'd keep trans_ADDI with the same signature to avoid creating an 
>> arg_D on the stack. Patch 4 added type specification, maybe we can 
>> define an arg_D within arg_PLD_D? I'll play a bit to see if it 
>> works.
> 
> That starts to creep, with e.g. ADDIS now requiring arg_PLD_D. You'll
> want to audit the other D-form insns to see what other special cases
> there are.
> 
> r~

Well, anything that shares implementation with a prefixed instruction
would use the prefixed arg.

I got arg_D within arg_PLD_D using !function and calling
decode_insn32_extract_D. A bit on the ugly side, and probably not
worth the effort. Maybe changing decodetree would help, but that's 
another patch, for another series.

Anyway, my compiler (GCC 9.3) is inlining trans_ADDI calls with -O3, so 
I'd say that your trans_PADDI from the previous message, with trans_ADDI 
and trans_ADDIS using arg_D, would be the cleaner solution.

Thanks,
Matheus K. Ferst
Instituto de Pesquisas ELDORADO <http://www.eldorado.org.br/>
Analista de Software Júnior
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>

[prev in list] [next in list] [prev in thread] [next in thread]