From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUHuN-0003nK-Gf for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:40:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUHuK-00083h-OK for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:39:55 -0400 Received: from mail-wg0-x22c.google.com ([2a00:1450:400c:c00::22c]:59989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUHuK-00083N-H0 for qemu-devel@nongnu.org; Mon, 22 Apr 2013 10:39:52 -0400 Received: by mail-wg0-f44.google.com with SMTP id a12so959701wgh.11 for ; Mon, 22 Apr 2013 07:39:51 -0700 (PDT) Sender: Richard Henderson Message-ID: <51754BAE.4030809@twiddle.net> Date: Mon, 22 Apr 2013 15:39:42 +0100 From: Richard Henderson MIME-Version: 1.0 References: <1364769305-3687-1-git-send-email-rth@twiddle.net> <1364769305-3687-19-git-send-email-rth@twiddle.net> <20130422125958.GA9133@ohm.aurel32.net> In-Reply-To: <20130422125958.GA9133@ohm.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 18/19] tcg-arm: Convert to CONFIG_QEMU_LDST_OPTIMIZATION List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org On 2013-04-22 13:59, Aurelien Jarno wrote: >> >+ /* The code buffer is limited to 16MB, with the prologue located >> >+ at the end of it. Therefore we needn't care for any out of >> >+ range branches. */ >> >+ assert(val - 8 < 0x01fffffd && val - 8 > -0x01fffffd); >> >+ >> >+ tcg_out_b(s, cond, val); > While this is currently true, I am not sure we want to get rid of that > code, and I hope we'll be able to eventually get rid of the 16MB limit. > > For me this dramatically reduce the boot time of guests. That said it is > not a real benchmark, and it should theoretically reduce the > performances in some cases as doing so interleaves code and data. > Someone has to spend time doing benchmarks before we can progress on that. > Ok, sure, but how do we progress in the short term? Certainly rejecting this patch and its changes to tcg_out_goto is not compatible with approving 19/19, which relies on it. IMO, tcg_out_goto should be the simple case of goto within a TB, with only the code for INDEX_goto_tb needing to handle the >16MB case. r~