From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRl6f-0001Bc-8u for qemu-devel@nongnu.org; Tue, 18 Aug 2015 13:55:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZRl6b-00078T-5Y for qemu-devel@nongnu.org; Tue, 18 Aug 2015 13:55:29 -0400 Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]:36343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRl6b-000785-1u for qemu-devel@nongnu.org; Tue, 18 Aug 2015 13:55:25 -0400 Received: by qkdv3 with SMTP id v3so60898675qkd.3 for ; Tue, 18 Aug 2015 10:55:24 -0700 (PDT) Sender: Richard Henderson 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> <20150803091716.GF30591@aurel32.net> From: Richard Henderson Message-ID: <55D37189.3010809@twiddle.net> Date: Tue, 18 Aug 2015 10:55:21 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 , Aurelien Jarno Cc: qemu-devel , Dennis Luehring On 08/18/2015 02:24 AM, Artyom Tarasenko wrote: > The unoptimized case is a sequence of multiple cmp and branch > operations (likely created by a "case" statement in the original > source code), especially where cmp is in a delay slot of a branch > instruction. Interesting. > I wonder whether we always have to finish a TB on a conditional jump. > Maybe it would make sense to translate further if a destination of a > jump is not too far from dc->pc? The definition of "not too far" is > indeed tricky. We can only handle two chained exits from a TB. If we continue past a conditional branch, we may well encounter a second conditional branch, which would leave us with three different exits from the TB. Something that may be interesting to play with, however, is to change the TB with which the insn in a delay slot is connected. For instance, we currently spend some amount of effort computing and saving the branch condition, so that we can then execute the delay slot, and afterwards use the saved branch condition to perform the branch. Another way of doing this is to immediately branch, exiting the TB. But we set up PC+NPC for the next TB such that the delay slot is the first insn that is executed within the next TB. In that way, the compare in the delay slot that you mention *is* in the same TB as the branch that uses it, allowing the case to be optimized. This could wind up creating more TBs than the current solution, so it's not clear that it would be a win. One can mitigate that somewhat by noticing the case where the delay slot is a nop. I do think it's worth an experiment. r~