qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-arm: Fix garbage collection of temporari


From: Christophe Lyon
Subject: Re: [Qemu-devel] [PATCH] target-arm: Fix garbage collection of temporaries in Neon emulation.
Date: Tue, 18 Jan 2011 17:58:38 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

On 18.01.2011 16:26, Peter Maydell wrote:
> On 18 January 2011 14:34, Christophe Lyon <address@hidden> wrote:
>> +
>> +    /* gen_helper_neon_mull_[su]{8|16} do not free their parameters.
>> +       Don't forget to clean them now.  */
>> +    switch ((size << 1) | u) {
>> +    case 0:
>> +    case 1:
>> +    case 2:
>> +    case 3:
>> +      dead_tmp(a);
>> +      dead_tmp(b);
>> +      break;
>> +    }
>>  }
> 
> This seems a rather convoluted way to write "if (size < 2) { ... }"
> 
It was for consistency/readability with the preceding paragraph.

>> @@ -5235,9 +5245,12 @@ static int disas_neon_data_insn(CPUState * env,
>> DisasContext *s, uint32_t insn)
>>                             tmp = neon_load_reg(rn, 0);
>>                         } else {
>>                             tmp = tmp3;
>> +                           /* tmp2 has been discarded in
>> +                              gen_neon_mull during pass 0, we need to
>> +                              recreate it.  */
>> +                           tmp2 = neon_get_scalar(size, rm);
>>                         }
> 
> I think this will give the wrong results for instructions where the
> scalar operand is in the same Neon register as the destination
> for the first pass, because calling neon_get_scalar() again will
> do a reload from the Neon register and it might have changed.
> (Also loading it once at the start rather than in every pass is
> more efficient as well as being correct :-))

I agree it's more efficient, but as the temporary is freed by gen_neon_mull, 
how can I make an efficient copy?

If we decide not to free the temporary in gen_mul[us]_i64_i32, we'll have to 
make sure clean up is performed correctly in many places.

 
> Also your patch has hard-coded tabs in it (please see
> CODING_STYLE on the subject of whitespace) and your
> mail client or server has line-wrapped long lines in the patch
> so it doesn't apply cleanly...

Sorry, I know we have some trouble with the mail client or server. Is it 
possible to send patches as attachments on this list?





reply via email to

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