Re: [Qemu-devel] [PATCH v4 08/33] tcg-aarch64: Introduce tcg_fmt_Rdnm and tcg_fmt_Rdnm_lsl

[Richard Henderson]

On 09/16/2013 08:32 AM, Richard Henderson wrote:
> Nor do we provide ASR or ROR shifts; should we provide those too?  Please 
> think
> about what situations in which those would be useful.  Also think about the 
> one
> operation at a time nature of TCG.
> 
> My guess is that, beyond the one explicit use in the tlb, we could only make
> use of shifted operations if TCG grew some sort of peephole optimizer so that
> we can look across single operations.  And I don't ever see that happening.
> 
> Therefore I think adding LSR, ASR and ROR shifts is both a waste of time and
> bloats the backend.


Unless: one decides NOT to use the alias definitions in the manual:

   LSR d, n, shift => UBFM d, n, shift, 63
   LSL d, n, shift => UBFM d, n, 64 - shift, 63 - shift
   ASR d, n, shift => SBFN d, n, shift, 63
   ROR d, n, shift => EXTR d, n, n, shift

and instead use

   LSR d, n, shift => ORR d, xzr, n, lsr #shift
   LSL d, n, shift => ORR d, xzr, n, lsl #shift
   ASR d, n, shift => ORR d, xzr, n, asr #shift
   ROR d, n, shift => ORR d, xzr, n, ror #shift

It's not implausible that using the same (base) insn for all of these could
result in more code sharing and therefore smaller code size within the tcg 
backend.


r~


PS: All rather academic, but considering that AArch64 ORR (shifted register) is
the preferred implementation for MOV, and AArch32 MOV (shifted register) is the
preferred implementation for shift immediates, I'm actually surprised that:
there is no AArch64 MOV (shifted register) alias for AArch32 compatibility, and
that ORR isn't the preferred implementation of shift immediates for AArch64.