qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH 02/13] target-arm: A64: add support for logical (shifted register)
Date: Fri, 06 Dec 2013 09:36:40 +0000
User-agent: mu4e 0.9.9.6pre2; emacs 24.3.2

address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]