Re: [Qemu-devel] [PATCH 02/13] target-arm: A64: add support for logical (shifted register)

["Alex Bennée" <alex.bennee@linaro.org>]

rth@twiddle.net writes:

> On 12/06/2013 10:51 AM, Peter Maydell wrote:
>> +    if (invert) {
>> +        tcg_gen_not_i64(tcg_rm, tcg_rm);
>> +    }
>> +
>> +    tcg_rd = cpu_reg(s, rd);
>> +    tcg_rn = cpu_reg(s, rn);
>> +
>> +    switch (opc) {
>> +    case 0: /* AND, BIC */
>> +    case 3: /* ANDS, BICS */
>> +        tcg_gen_and_i64(tcg_rd, tcg_rn, tcg_rm);
>> +        break;
>> +    case 1: /* ORR, ORN */
>> +        tcg_gen_or_i64(tcg_rd, tcg_rn, tcg_rm);
>> +        break;
>> +    case 2: /* EOR, EON */
>> +        tcg_gen_xor_i64(tcg_rd, tcg_rn, tcg_rm);
>> +        break;
>> +    default:
>> +        assert(FALSE);
>> +        break;
>> +    }
>
> While correct, surely better to work with tcg and select on opc:invert to
> generate andc/orc/eqv?

Shouldn't the TCG optimiser/back-end just be smart enough to figure it
out? It seems clearer to express the tcg ops in terms of the front-end's
meaning?

> Also, isn't MOV (register) canonical for ORR (rn=31 && shift_amount=0), and MVN
> (register) canonical for ORN (rn=31 && shift_amount=0), and both therefore also
> worth a special case?

I suspect I'm being overly cheeky to expect the optimiser to detect and
optimise for that case as the ZR is a const ;-)


Cheers,

--
Alex Bennée
QEMU/KVM Hacker for Linaro