From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DN70Y-0001JV-BP for qemu-devel@nongnu.org; Sun, 17 Apr 2005 06:28:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DN70V-0001JC-DT for qemu-devel@nongnu.org; Sun, 17 Apr 2005 06:28:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DN70U-0001J2-U6 for qemu-devel@nongnu.org; Sun, 17 Apr 2005 06:28:03 -0400 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DN71Q-000164-8X for qemu-devel@nongnu.org; Sun, 17 Apr 2005 06:29:00 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Profiling Qemu for speed? Date: Sun, 17 Apr 2005 11:27:35 +0100 References: <20050417055844.48210.qmail@web51601.mail.yahoo.com> <1113726074.25892.526.camel@aragorn> <70867645caaf37338ce6a98cdfb0bdc2@elis.ugent.be> In-Reply-To: <70867645caaf37338ce6a98cdfb0bdc2@elis.ugent.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504171127.36489.paul@codesourcery.com> Reply-To: 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 On Sunday 17 April 2005 09:59, Jonas Maebe wrote: > On 17 Apr 2005, at 10:21, John R. Hogerhuis wrote: > > One thought would be to have a peephole optimizer that looks back over > > the just translated basic block (or a state machine that matches such > > sequences as an on-line algorithm) and match against common, known > > primitive sequences, and replaces them with optimized versions. > > Another thing I've thought about is checking what sequences of > instructions often appear in x86 programs (such as e.g. "push %ebp; > movl %esp, %ebp") and then creating C-functions which emulate such an > antire block, so they can be optimized as a whole by gcc. That would > give a similar performance gain on all supported targets, and not just > on the one you created the peephole optimizer for (+ less work to > debug). Unfortunately it's not that simple. The push instruction may cause an exception. Whatever optimizations you apply you've got to make sure that the guest state is still consistent when the exception occurs. Paul