From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upi9X-0004Li-1h for qemu-devel@nongnu.org; Thu, 20 Jun 2013 12:56:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upi9U-0001uZ-AV for qemu-devel@nongnu.org; Thu, 20 Jun 2013 12:56:06 -0400 Received: from mail-qc0-x22f.google.com ([2607:f8b0:400d:c01::22f]:47738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upi9U-0001uO-6t for qemu-devel@nongnu.org; Thu, 20 Jun 2013 12:56:04 -0400 Received: by mail-qc0-f175.google.com with SMTP id k14so3811952qcv.6 for ; Thu, 20 Jun 2013 09:56:03 -0700 (PDT) Sender: Richard Henderson Message-ID: <51C3341F.3020801@twiddle.net> Date: Thu, 20 Jun 2013 09:55:59 -0700 From: Richard Henderson MIME-Version: 1.0 References: <51C2DDFD.4030702@huawei.com> <51C2DF23.3020202@huawei.com> <51C3189A.5010206@huawei.com> In-Reply-To: <51C3189A.5010206@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] tcg/aarch64: Implement tlb lookup fast path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Claudio Fontana Cc: Peter Maydell , Jani Kokkonen , "qemu-devel@nongnu.org" On 06/20/2013 07:58 AM, Claudio Fontana wrote: >> > + tcg_out_ldst(s, TARGET_LONG_BITS == 64 ? LDST_64 : LDST_32, >> > + LDST_LD, TCG_REG_X0, TCG_REG_X2, tlb_offset & 0xfff); >> > + tcg_out_ldst(s, LDST_64, LDST_LD, TCG_REG_X1, TCG_REG_X2, >> > + (tlb_offset & 0xfff) + (offsetof(CPUTLBEntry, addend) - >> > + (is_read ? offsetof(CPUTLBEntry, addr_read) : >> > + offsetof(CPUTLBEntry, addr_write)))); >> > + >> > + tcg_out_cmp(s, 1, TCG_REG_X0, TCG_REG_X3, 0); >> > + *label_ptr = s->code_ptr; >> > + tcg_out_goto_cond_noaddr(s, TCG_COND_NE); >> > +} > hmm should not the compare and branch actually be before the loading of the addend? > If we jump to the slow path we don't need to load the addend do we? > No, but it's the slow path, and we don't care if we do extra work. What's more important is minimizing the memory load delay for the fast path. r~