|
From: | Matheus K. Ferst |
Subject: | Re: [PATCH v3 25/30] target/ppc: Move ADDI, ADDIS to decodetree, implement PADDI |
Date: | Fri, 30 Apr 2021 20:29:33 -0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 |
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 usestatic 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 notworth 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 Thread] | Current Thread | [Next in Thread] |