From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N80Il-0004hK-2U for qemu-devel@nongnu.org; Tue, 10 Nov 2009 18:39:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N80Ie-0004bT-7z for qemu-devel@nongnu.org; Tue, 10 Nov 2009 18:39:05 -0500 Received: from [199.232.76.173] (port=39860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N80Id-0004ax-T5 for qemu-devel@nongnu.org; Tue, 10 Nov 2009 18:38:59 -0500 Received: from mx20.gnu.org ([199.232.41.8]:55717) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N80Ic-0003eZ-3e for qemu-devel@nongnu.org; Tue, 10 Nov 2009 18:38:59 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N80IX-0008GL-GS for qemu-devel@nongnu.org; Tue, 10 Nov 2009 18:38:53 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 00/18] target-arm cleanup Date: Tue, 10 Nov 2009 23:38:49 +0000 References: <5b31733c0907190843k11ead885tc6b4c81b79f7257b@mail.gmail.com> <64E0C9BE-CEC5-44B4-87CE-A918AD8121B1@nokia.com> <761ea48b0910182335v799291a1l755515927e24ee9@mail.gmail.com> In-Reply-To: <761ea48b0910182335v799291a1l755515927e24ee9@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911102338.49991.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Laurent Desnogues , Juha.Riihimaki@nokia.com, aurelien@aurel32.net > > Some of the generated tcg code is not very optimal, for example a > > single vld4.8 instruction can generate over 250 tcg ops. I did some > > optimizations and got it under 200 but do you think it could be an > > issue that a single instruction can expand to so many tcg ops? I mean > > besides the fact that it causes TBs for only one or two guest > > instructions to be generated. > > Fabrice wrote this (tcg/README): > > Don't hesitate to use helpers for complicated or seldom used target > intructions. There is little performance advantage in using TCG to > implement target instructions taking more than about twenty TCG > instructions. > > How applicable is it, I can't say. It'd probably be a good thing > to benchmark the two versions, TCG vs helper. The problem is that you can not do memory accesses from within a helper function. Paul