From patchwork Thu Oct 22 07:13:10 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juha.Riihimaki@nokia.com X-Patchwork-Id: 36652 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id C702DB7BAB for ; Thu, 22 Oct 2009 18:14:01 +1100 (EST) Received: from localhost ([127.0.0.1]:34099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0rrx-0005Wa-Ns for incoming@patchwork.ozlabs.org; Thu, 22 Oct 2009 03:13:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0rrU-0005WL-FW for qemu-devel@nongnu.org; Thu, 22 Oct 2009 03:13:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0rrQ-0005Vt-Ob for qemu-devel@nongnu.org; Thu, 22 Oct 2009 03:13:28 -0400 Received: from [199.232.76.173] (port=51807 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0rrQ-0005Vq-JF for qemu-devel@nongnu.org; Thu, 22 Oct 2009 03:13:24 -0400 Received: from smtp.nokia.com ([192.100.122.230]:33403 helo=mgw-mx03.nokia.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N0rrQ-00048Y-2x for qemu-devel@nongnu.org; Thu, 22 Oct 2009 03:13:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9M7CgPr028407; Thu, 22 Oct 2009 10:13:19 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:13:06 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:13:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:12:57 +0300 Received: from NOK-EUMSG-05.mgdnok.nokia.com ([65.54.30.90]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 22 Oct 2009 09:12:55 +0200 From: To: Date: Thu, 22 Oct 2009 09:13:10 +0200 Subject: Re: [Qemu-devel] [PATCH] target-arm: cleanup internal resource leaks Thread-Topic: [Qemu-devel] [PATCH] target-arm: cleanup internal resource leaks Thread-Index: AcpS5xObftS9+AL1Q4CFKzwZYRszZw== Message-ID: References: <761ea48b0910211220y758b4deeg4ec8595c30bf91f8@mail.gmail.com> In-Reply-To: Accept-Language: en, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2009 07:12:57.0164 (UTC) FILETIME=[14B268C0:01CA52E7] X-Nokia-AV: Clean X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Cc: qemu-devel@nongnu.org X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Oct 22, 2009, at 08:40, Riihimaki Juha (Nokia-D/Helsinki) wrote: >>> @@ -4676,12 +4694,16 @@ static int disas_neon_data_insn(CPUState * >>> env, DisasContext *s, uint32_t insn) >>> gen_neon_narrow_satu(size - 1, tmp, >>> cpu_V0); >>> } >>> if (pass == 0) { >>> + dead_tmp(tmp2); >> >> This looks wrong if size == 3 since we have TCGV_UNUSED(tmp2). > > You're right. However, looking at the surrounding code a bit closer I > began to wonder if it works correctly at all since tmp2 is used as a > shift value if size < 2 but it is also used to store the result of the > first pass. Therefore the result of the first pass is used as a shift > value during second pass... perhaps not correct? Wouldn't it make more > sense to store the result of the first pass in the lower half of the > destination neon register directly during the first pass? I see no > point in keeping it in a temporary variable and only store both halves > of the destination neon register during the second pass. Especially > since there is no memory access involved, everything is done in > registers. What do you think? To make it more clear what I'm after, look at the patch below that changes the code into what I think is correct functionality. The patch applies on top of the v2 resource leak patch which I just sent a short while ago. Cheers, Juha --- } else if (op == 10) { /* VSHLL */ diff --git a/target-arm/translate.c b/target-arm/translate.c index 813f661..7598246 100644 --- a/target-arm/translate.c +++ b/target-arm/translate.c @@ -4696,18 +4696,12 @@ static int disas_neon_data_insn(CPUState * env, DisasContext *s, uint32_t insn) else gen_neon_narrow_satu(size - 1, tmp, cpu_V0); } - if (pass == 0) { - if (size != 3) { - dead_tmp(tmp2); - } - tmp2 = tmp; - } else { - neon_store_reg(rd, 0, tmp2); - neon_store_reg(rd, 1, tmp); - } + neon_store_reg(rd, pass, tmp); } /* for pass */ if (size == 3) { tcg_temp_free_i64(tmp64); + } else { + dead_tmp(tmp2); }