From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BphBR-0008Hp-Ez for qemu-devel@nongnu.org; Wed, 28 Jul 2004 01:40:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BphBQ-0008Hd-UK for qemu-devel@nongnu.org; Wed, 28 Jul 2004 01:40:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BphBQ-0008Ha-RY for qemu-devel@nongnu.org; Wed, 28 Jul 2004 01:40:56 -0400 Received: from [64.233.170.201] (helo=mproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bph7v-0004kH-NS for qemu-devel@nongnu.org; Wed, 28 Jul 2004 01:37:19 -0400 Received: by mproxy.gmail.com with SMTP id 74so92771rnk for ; Tue, 27 Jul 2004 22:37:14 -0700 (PDT) Message-ID: <2ad73a04072722372231b102@mail.gmail.com> Date: Wed, 28 Jul 2004 02:37:14 -0300 From: =?ISO-8859-1?Q?Andr=E9_Braga?= In-Reply-To: <20040723213844.GA18562@fefe.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2ad73a04072209021aed732c@mail.gmail.com> <20040723213844.GA18562@fefe.de> Subject: [Qemu-devel] Re: QEMU fails with different levels of compiler optimization 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 Cc: Felix von Leitner On Fri, 23 Jul 2004 23:38:44 +0200, Felix von Leitner wrote: > -O3 is basically the same as -O2 -finline-functions. And -frename-registers. I explicitly opted not to run -O3 because of that. But I surely wanted the other flags turned on. > And enabling mmx 3dnow and sse is superfluous if you use > -march=athlon-xp. I thought so also, and I even suspect that turning the verbose flag on GCC shows that those are enabled when you run -march=athlon-xp, but the GCC manpage on the subject is somewhat unclear: http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/X86-Built-in-Functions.html#X86%20Built-in%20Functions > The point is, optimizing qemu is not what you need to > do to improve runtime. qemu is a code generator. You would need to > improve the code qemu generates. Unless I completely missed the point made on http://fabrice.bellard.free.fr/qemu/qemu-tech.html#TOC9 , QEMU doesn't actually generate code "by hand", but instead it relies on what GCC outputs when compiling op.c . Thus, if by any chance I can get GCC to produce more optimized code when compiling op.c, that would mean QEMU as a whole would use the smartest possible logic on my processor, and so it would run way faster than vanilla compilations. I'm forwarding this to Fabrice just in case he finds it worthy to comment on my hypothesis -- whether it's correct or not, and if compiler optimizations can indeed produce faster code and/or more performing emulation in this case. I hope he won't get pissed off :) Thanks! -- "Structure is nothing if it is all you've got. Skeletons spook people if they try to walk around on their own; I really wonder why XML does not" -Erik Naggum