qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 19/29] tcg-aarch64: Introduce tcg_fmt_Rd_uimm


From: Claudio Fontana
Subject: Re: [Qemu-devel] [PATCH v3 19/29] tcg-aarch64: Introduce tcg_fmt_Rd_uimm_s
Date: Fri, 6 Sep 2013 11:06:52 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 05.09.2013 17:41, Richard Henderson wrote:
> On 09/05/2013 06:32 AM, Claudio Fontana wrote:
>>>  {
>>> -    uint32_t half, base, shift, movk = 0;
>>> -    /* construct halfwords of the immediate with MOVZ/MOVK with LSL */
>>> -    /* using MOVZ 0x52800000 | extended reg.. */
>>> -    base = (value > 0xffffffff) ? 0xd2800000 : 0x52800000;
>>> -    /* count trailing zeros in 16 bit steps, mapping 64 to 0. Emit the
>>> -       first MOVZ with the half-word immediate skipping the zeros, with a 
>>> shift
>>> -       (LSL) equal to this number. Then morph all next instructions into 
>>> MOVKs.
>>> -       Zero the processed half-word in the value, continue until empty.
>>> -       We build the final result 16bits at a time with up to 4 
>>> instructions,
>>> -       but do not emit instructions for 16bit zero holes. */
>>
>> Please do not remove these comments.
>> In my judgement this part of the code profits from some verbose 
>> clarification.
>> What is happening might be obvious to you, but not to others trying to step 
>> in.
> 
> Fair enough.
> 
>> In general I'd prefer to keep movi as it was (functionally-wise) for the
>> time being, replacing it with a more efficient version once we can get some
>> numbers (which will be soon) with which to justify (or not) the added code
>> complexity.
> 
> The most important thing we're not doing at the moment is handling negative
> numbers efficiently.  E.g. we're using 4 insns to load -1.

Ok, lets punctually address that then.

> r~
> 

Claudio





reply via email to

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