From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2LbZ-0001y5-6x for qemu-devel@nongnu.org; Mon, 26 Oct 2009 05:11:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2LbY-0001xr-ER for qemu-devel@nongnu.org; Mon, 26 Oct 2009 05:11:08 -0400 Received: from [199.232.76.173] (port=41659 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2LbY-0001xo-C2 for qemu-devel@nongnu.org; Mon, 26 Oct 2009 05:11:08 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:55009) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2LbY-0001rW-1M for qemu-devel@nongnu.org; Mon, 26 Oct 2009 05:11:08 -0400 Received: by fg-out-1718.google.com with SMTP id d23so4077299fga.10 for ; Mon, 26 Oct 2009 02:11:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4F9750C3-A196-4518-8021-D02BFE645A4F@nokia.com> References: <1256386749-85299-1-git-send-email-juha.riihimaki@nokia.com> <1256386749-85299-10-git-send-email-juha.riihimaki@nokia.com> <761ea48b0910250701q3a452eaama8a07059ed8aec30@mail.gmail.com> <4F9750C3-A196-4518-8021-D02BFE645A4F@nokia.com> Date: Mon, 26 Oct 2009 10:11:07 +0100 Message-ID: <761ea48b0910260211k12d199c5l794eb0f9d45e3b77@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH v2 09/10] target-arm: optimize neon vld/vst ops From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juha.Riihimaki@nokia.com Cc: qemu-devel@nongnu.org On Mon, Oct 26, 2009 at 8:46 AM, wrote: > > On Oct 25, 2009, at 16:01, ext Laurent Desnogues wrote: > >> I don't really like the idea of having tcg_qemu_ld/st not factored >> in some place, as it makes memory access tracing extensions >> more intrusive. >> >> This brings us back to the problem having function freeing tmps. >> In that case, you could perhaps create a gen_st16_dont_free >> function as a temporary workaround? > > I could, but it is getting ugly =/ How about if I create another patch > that moves the temporary variable (de)allocation outside the gen_ldx/ > gen_stx functions and then refactor this patch on top of that? I'd personally like this, but I guess you'd better wait for some inputs from other QEMU dev's before doing it. Laurent