rth@xxxxxxxxxxx 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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
