From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CFEJE-0006kX-NR for qemu-devel@nongnu.org; Wed, 06 Oct 2004 12:06:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CFEJC-0006jI-SF for qemu-devel@nongnu.org; Wed, 06 Oct 2004 12:06:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFEJC-0006iw-NC for qemu-devel@nongnu.org; Wed, 06 Oct 2004 12:06:30 -0400 Received: from [62.2.95.247] (helo=smtp.hispeed.ch) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CFECT-0002lG-Rg for qemu-devel@nongnu.org; Wed, 06 Oct 2004 11:59:34 -0400 Received: from nbbolle (80-218-110-20.dclient.hispeed.ch [80.218.110.20]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id i96FxTlg017911 for ; Wed, 6 Oct 2004 17:59:29 +0200 From: "Andreas Bollhalder" Subject: RE: [Qemu-devel] Idea for speed improvement Date: Wed, 6 Oct 2004 17:56:43 +0200 Message-ID: <000001c4abbd$1364fa90$6401a8c0@geodb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: Reply-To: bolle@geodb.org, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Looks fine ;-) Would GCC sort for example a case statement, that the most used op-codes will be the first entry ? Could shurly save some cycles. Or maybe I'm totaly wrong ? Andreas -----Original Message----- From: qemu-devel-bounces+bolle=3Dgeodb .org@nongnu.org [mailto:qemu-devel-bounces+bol le=3Dgeodb.org@nongnu.org] On Behalf Of Johannes Schindelin Sent: Wednesday, October 06, 2004 4:19 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] Idea for speed improvement *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi, how about the following scenario: We add a "-profile " option to QEmu, which just writes out profiling data: - all the (optimized) intermediate stages of all the translated blocks are written into that file. - the first op will be op_incr_tb_usage_counter, which increments a counter in the TB structure. - whenever a TB is flushed, the counter is written into that file also. After one run with "-profile", a tool can analyze that data, and generate a header file which inlines the most frequent sequences to produce new op_* functions, and code for the optimization phase of the dynamic translation, which collapses those sequences to the newly created ops. Then, QEmu is compiled anew, using that code. This all depends on gcc doing a good job at optimizing the hell out of those sequences, of course. Just op_exit_tb cannot be inlined like that, because of the stack problem I mentioned earlier on this list. Thoughts, comments, bashing? Ciao, Dscho P.S.: Fabrice, is this what you meant by "gcc backend"? ______________________________ _________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailma n/listinfo/qemu-devel