From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMBs3-0000RG-H4 for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:17:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMBry-0004H7-IW for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:17:23 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:33093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMBry-0004GS-Cc for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:17:18 -0400 Date: Mon, 3 Aug 2015 11:17:16 +0200 From: Aurelien Jarno Message-ID: <20150803091716.GF30591@aurel32.net> References: <55B870A9.4090008@gmx.net> <20150729150147.GO11361@aurel32.net> <55B99F95.8010603@gmx.net> <20150730075252.GT11361@aurel32.net> <55B9DD60.8020801@gmx.net> <20150730085500.GV11361@aurel32.net> <20150730155003.GE30591@aurel32.net> <20150731154323.GD23508@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel , Dennis Luehring On 2015-08-03 10:31, Artyom Tarasenko wrote: > Hi Aurelien, > > On Fri, Jul 31, 2015 at 5:43 PM, Aurelien Jarno wrote: > > >> > It uses a lot of integer functions > >> > based on CPU flags, so most of the time is spent computing them in > >> > helper_compute_psr. > >> > >> I wonder if this can be optimized. I guess most RISC CPUs would have a > >> similar problem. Unlike x86, the compilers usually optimize > >> instructions on flag usage. If there is an instruction modifying flags > >> in a code, the flags will be used for sure, so it probably makes a > >> little sense to pospone the flag computation? > > > > Indeed. ARM and SH4 use one TCG temp per flag, and they can be computed > > one by one using setcond. The optimizer and the liveness analysis then > > get rid of the unused computation. However while it allows intra-TB > > optimization, it prevent any other flags optimization. Therefore the > > only way to know if it is a good idea or not is to implement it and > > benchmark that, but using a bit more than a single biased benchmark like > > the one from sysbench. > > > > Also note that the current implementation predates the introduction of > > setcond, which is necessary to be able to compute the flags using TCG > > code. > > Thanks for explaining it, the problem is much more clear now. > Moving to setcond is definitely worth a shot. I'd like to play with it. > What would be the minimal entity to change without reworking the complete TCG: > a) one flag for one instruction, > b) all flags for one instruction, > c) one flag for all instructions, > or d) all flags for all instructions (gradually moving to setcond is > not possible) ? You should with the c) option. You can look at how I done this for SH4, starting with commit 5ed9a259c164bb9fd2a6fe8a363a4bda2e4a5461. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net