From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLnjZ-0002TC-Mb for qemu-devel@nongnu.org; Wed, 10 Oct 2012 00:17:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLnjY-0004qM-Ct for qemu-devel@nongnu.org; Wed, 10 Oct 2012 00:17:25 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:11431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLnjY-0004pl-1f for qemu-devel@nongnu.org; Wed, 10 Oct 2012 00:17:24 -0400 Received: from epcpsbgm2.samsung.com (epcpsbgm2 [203.254.230.27]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MBN006LKT7ZQCB0@mailout3.samsung.com> for qemu-devel@nongnu.org; Wed, 10 Oct 2012 13:17:20 +0900 (KST) Received: from [172.21.111.108] ([182.198.1.3]) by mmp1.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MBN00JDET8VJD90@mmp1.samsung.com> for qemu-devel@nongnu.org; Wed, 10 Oct 2012 13:17:20 +0900 (KST) Date: Wed, 10 Oct 2012 13:17:36 +0900 From: Yeongkyoon Lee In-reply-to: <20121009170923.GF9643@ohm.aurel32.net> Message-id: <5074F6E0.1090206@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE References: <1349786252-12343-1-git-send-email-yeongkyoon.lee@samsung.com> <20121009142610.GA14078@ohm.aurel32.net> <20121009161956.GG14078@ohm.aurel32.net> <5074571E.60700@redhat.com> <20121009170923.GF9643@ohm.aurel32.net> Subject: Re: [Qemu-devel] [PATCH v5 0/3] tcg: enhance code generation quality for qemu_ld/st IRs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Paolo Bonzini , qemu-devel@nongnu.org On 2012=EB=85=84 10=EC=9B=94 10=EC=9D=BC 02:09, Aurelien Jarno wrote: > On Tue, Oct 09, 2012 at 06:55:58PM +0200, Paolo Bonzini wrote: >> Il 09/10/2012 18:19, Aurelien Jarno ha scritto: >>>>> Instead of calling the MMU helper with an additional argument (= 7), and >>>>> then jump back (8) to the next code (4), what about pushing the= address >>>>> of the next code (4) on the stack and use a jmp instead of the = call. In >>>>> that case you don't need the extra argument to the helpers. >>>>> >>> Maybe it wasn't very clear. This is based on the fact that call i= s >>> basically push %rip + jmp. Therefore we can fake the return addre= ss by >>> putting the value we want, here the address of the next code. Thi= s mean >>> that we don't need to pass the extra argument to the helper for t= he >>> return address, as GET_PC() would work correctly (it basically re= ads the >>> return address on the stack). >>> >>> For other architectures, it might not be a push, but rather a mov= e to >>> link register, basically put the return address where the calling >>> convention asks for. >>> >>> OTOH I just realized it only works if the end of the slow path (m= oving >>> the value from the return address to the correct register). It mi= ght be >>> something doable. >> Branch predictors will not oldschool tricks like this one. :) >> > Given it is only used in the slow path (ie the exception more than = the > rule), branch prediction isn't that important there. > I had already considered the approach of using jmp and removing extra= =20 argument for helper call. However, the problem is that the helper needs the gen code addr used = by=20 tb_find_pc() and cpu_restore_state(). That means the code addr in the helper can be actually said the addr= =20 corresponding to QEMU_ld/st IR rather than the return addr. In my LDST optimization, the helper call site is not in the code of I= R=20 but in the end of TB. So, if the code addr is not explicitly given as a helper argument, it= is=20 too difficult to calculate it using such GETPC() manner.