From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2WkV-0000hz-98 for qemu-devel@nongnu.org; Mon, 26 Oct 2009 17:05:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2WkT-0000hf-T3 for qemu-devel@nongnu.org; Mon, 26 Oct 2009 17:05:06 -0400 Received: from [199.232.76.173] (port=34417 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2WkT-0000hc-Lx for qemu-devel@nongnu.org; Mon, 26 Oct 2009 17:05:05 -0400 Received: from hall.aurel32.net ([88.191.82.174]:44308) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N2WkT-0000qo-5y for qemu-devel@nongnu.org; Mon, 26 Oct 2009 17:05:05 -0400 Date: Mon, 26 Oct 2009 22:05:02 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH v2 09/10] target-arm: optimize neon vld/vst ops Message-ID: <20091026210502.GT26129@hall.aurel32.net> 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> <761ea48b0910260211k12d199c5l794eb0f9d45e3b77@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <761ea48b0910260211k12d199c5l794eb0f9d45e3b77@mail.gmail.com> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: Juha.Riihimaki@nokia.com, qemu-devel@nongnu.org On Mon, Oct 26, 2009 at 10:11:07AM +0100, Laurent Desnogues wrote: > 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. Looks like the best option to me. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net