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.