qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] tcg/aarch64: implement new TCG target for a


From: Laurent Desnogues
Subject: Re: [Qemu-devel] [PATCH 3/3] tcg/aarch64: implement new TCG target for aarch64
Date: Tue, 28 May 2013 15:09:08 +0200

On Tue, May 28, 2013 at 3:01 PM, Claudio Fontana
<address@hidden> wrote:
> On 27.05.2013 23:14, Laurent Desnogues wrote:
>>
>>
>> On Monday, May 27, 2013, Richard Henderson <address@hidden 
>> <mailto:address@hidden>> wrote:
>>> On 2013-05-27 04:43, Claudio Fontana wrote:
>>>>>
>>>>> Hmm, true.  Although I'd been thinking more along the lines of
>>>>> arranging the code such that we'd use movz to set the zero.
>>>>
>>>> I think we need to keep treating zero specially if we want to keep the 
>>>> optimization where we don't emit needless MOVK instructions for half-words 
>>>> of value 0000h.
>>>>
>>>> I can however make one single function out of movi32 and movi64, it could 
>>>> look like this:
>>>>
>>>> if (!value) {
>>>>      tcg_out_movr(s, 0, rd, TCG_REG_ZXR);
>>>>      return;
>>>> }
>>>>
>>>> base = (value > 0xffffffff) ? 0xd2800000 : 0x52800000;
>>>>
>>>> while (value) {
>>>>      /* etc etc */
>>>> }
>>>
>>>
>>>     if (type == TCG_TYPE_I32) {
>>>         value = (uint32_t)value;
>>>         ext = 0;
>>>     } else if (value <= 0xffffffff) {
>>>         ext = 0;
>>>     } else {
>>>         ext = 0x80000000;
>>>     }
>>>
>>>     base = 0x52800000;  /* MOVZ */
>>>     do {
>>>         int shift = ctz64(value) & (63 & -16);
>>>         int half = (value >> shift) & 0xffff;
>>>         tcg_out32(s, base | ext | half << 5 | rd);
>>>         value &= ~(0xffffUL << shift);
>>>         base = 0x72800000;  /* MOVK */
>>>     } while (value != 0);
>>>
>>>
>>> Since we go through the loop at least once, we emit the movz for zero 
>>> input. No need for any extra tests.  And using ctz we can iterate fewer 
>>> times.
>>
>> You could probably go one step further and use the logical
>> immediate encoding.  Look at build_immediate_table in binutils
>> opcodes/aarch64-opc.c.  The problem would be the use of
>> binary search; perhaps one could come up with some perfect
>> hash function.
>>
>>
>> Laurent
>
> if it's ok I would go with a variation of Richard's approach.
> A more sofisticated approach, like the one you suggest, could be added by a 
> successive patch.


I definitely agree.


Laurent



reply via email to

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