From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1BqH8p-0000UP-6x
	for qemu-devel@nongnu.org; Thu, 29 Jul 2004 16:04:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1BqH8n-0000U2-Tf
	for qemu-devel@nongnu.org; Thu, 29 Jul 2004 16:04:38 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1BqH8n-0000Tg-QO
	for qemu-devel@nongnu.org; Thu, 29 Jul 2004 16:04:37 -0400
Received: from [64.233.170.201] (helo=mproxy.gmail.com)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1BqH5O-0003p8-1M
	for qemu-devel@nongnu.org; Thu, 29 Jul 2004 16:01:06 -0400
Received: by mproxy.gmail.com with SMTP id 74so37017rnk
	for <qemu-devel@nongnu.org>; Thu, 29 Jul 2004 13:01:05 -0700 (PDT)
Message-ID: <2ad73a040729130164240863@mail.gmail.com>
Date: Thu, 29 Jul 2004 17:01:05 -0300
From: =?ISO-8859-1?Q?Andr=E9_Braga?= <meianoite@gmail.com>
Subject: Re: [Qemu-devel] Re: QEMU fails with different levels of compiler
	optimizati
In-Reply-To: <BAY7-F13E4D3MBhe3WY0002c20e@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BAY7-F13E4D3MBhe3WY0002c20e@hotmail.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Uh... Not yet, but you have a point: it makes it more likely that the
critical code will fit the cache. I did not enable
-fomit-frame-pointer because it makes debugging a *pain in the rear*,
and sometimes I run QEMU under GDB just to see if I can narrow the
problem down to some specific part of the code. And so far it seems
that the mingw runtime breaks something with the Windows timing
functions if I run higher levels of optimization. I'm yet to try it
under Linux.


On Wed, 28 Jul 2004 16:36:38 +0000, Tom Musgrove
<tommusgrove__@hotmail.com> wrote:
> Have you tried to optimize for size instead?
> 
> Ie -Os (and also -fomit-frame-pointer)
> 
> It sometimes creates more speed optimal code than the other optimization
> flags.
> 

--
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis