From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOgJW-0007rP-Pj for qemu-devel@nongnu.org; Wed, 17 Oct 2012 22:58:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOgJV-0006K3-Rk for qemu-devel@nongnu.org; Wed, 17 Oct 2012 22:58:26 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:21596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOgJV-0006JW-Gs for qemu-devel@nongnu.org; Wed, 17 Oct 2012 22:58:25 -0400 Received: from epcpsbgm1.samsung.com (epcpsbgm1 [203.254.230.26]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MC2004GVIX8RLA0@mailout4.samsung.com> for qemu-devel@nongnu.org; Thu, 18 Oct 2012 11:58: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 <0MC200467IX8CRE0@mmp1.samsung.com> for qemu-devel@nongnu.org; Thu, 18 Oct 2012 11:58:20 +0900 (KST) Date: Thu, 18 Oct 2012 11:58:22 +0900 From: Yeongkyoon Lee In-reply-to: <507F42CD.6000209@twiddle.net> Message-id: <507F704E.90709@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE References: <1350372190-32186-1-git-send-email-yeongkyoon.lee@samsung.com> <1350372190-32186-4-git-send-email-yeongkyoon.lee@samsung.com> <507F42CD.6000209@twiddle.net> Subject: Re: [Qemu-devel] [PATCH v6 3/3] tcg: Optimize qemu_ld/st by generating slow paths at the end of a block List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org, aurelien@aurel32.net On 2012=EB=85=84 10=EC=9B=94 18=EC=9D=BC 08:44, Richard Henderson wro= te: > On 2012-10-16 17:23, Yeongkyoon Lee wrote: >> + /* Code generation of qemu_ld/st's slow path calling MMU help= er >> + >> + PRE_PROC ... >> + call MMU helper >> + jmp POST_PROC (2b) : short forward jump <- GETRA() >> + jmp next_code (5b) : dummy long backward jump which is nev= er executed >> + POST_PROC ... : do post-processing <- GETRA() + 7 >> + jmp next_code : jump to the code corresponding to next IR = of qemu_ld/st >> + */ > Is this jump over jump really any better than passing next_code > as another function argument? > > In 32-bit mode > =09push $next_code > In 64-bit mode > =09leaq next_code(%rip),%r8 > > > r~ > Only one advantage is no fragmentation of MMU helpers, that is, we wi= ll=20 still have the same helper prototypes. In my opinion, the performance degradation of using jmp instead of pu= sh=20 or something, is negligible because it is executed on slow path.