From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcJVw-0006OU-NY for qemu-devel@nongnu.org; Wed, 16 Sep 2015 16:41:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcJVr-0002Wk-No for qemu-devel@nongnu.org; Wed, 16 Sep 2015 16:41:12 -0400 Received: from mail-qk0-x22f.google.com ([2607:f8b0:400d:c09::22f]:33988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcJVr-0002WX-HC for qemu-devel@nongnu.org; Wed, 16 Sep 2015 16:41:07 -0400 Received: by qkfq186 with SMTP id q186so91984707qkf.1 for ; Wed, 16 Sep 2015 13:41:06 -0700 (PDT) Sender: Richard Henderson References: <1441173123-25540-1-git-send-email-rth@twiddle.net> <87r3m685pg.fsf@linaro.org> <55F87D53.1060108@twiddle.net> <8737yeoi3r.fsf@linaro.org> From: Richard Henderson Message-ID: <55F9D3DD.6050003@twiddle.net> Date: Wed, 16 Sep 2015 13:41:01 -0700 MIME-Version: 1.0 In-Reply-To: <8737yeoi3r.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: aurelien@aurel32.net, qemu-devel@nongnu.org, dl.soluz@gmx.net, atar4qemu@gmail.com On 09/16/2015 01:59 AM, Alex Bennée wrote: > > Richard Henderson writes: > >> On 09/10/2015 11:55 AM, Alex Bennée wrote: >>> I've only had a quick glance so far but I'm fairly familiar with the >>> concept from a previous life. I'll aim to do a full review later once >>> I've gotten through my MTTCG review backlog. >>> >>> Anyway some quick points: >>> >>> * You can save data by only marking faulting instructions >>> >>> Assuming that all asynchronous instructions trigger at the end/prologue >>> of basic blocks you only actually need to record the address of >>> potentially faulting instructions. In fact only a few backend >>> instructions will actually synchronously fault. >>> >>> Of course this does have the downside of having to mark all those >>> instructions in the front end. >> >> We have that. The only tcg opcodes that can fault are qemu_ld, qemu_st, and >> call. So, yes, I could do exactly this. Perhaps not for round 1, >> however? > > I unfortunately haven't got a SPARC manual handy (or my old testsuite) > but I was sure there was more than just loads/stores. I guess all the FP > related exceptions are handled in Softfloat for QEMU and the hardcoded > cases caught during instruction decode. Yes indeed. A tcg-opcode based "might it trap" test will be more inclusive than one that actually examined the target insns. But it'll work universally without needing to modify the translators, and it will save *some* space. r~