qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "André Braga" <meianoite@gmail.com>
To: qemu-devel@nongnu.org
Cc: Felix von Leitner <leitner@fefe.de>
Subject: [Qemu-devel] Re: QEMU fails with different levels of compiler optimization
Date: Wed, 28 Jul 2004 02:37:14 -0300	[thread overview]
Message-ID: <2ad73a04072722372231b102@mail.gmail.com> (raw)
In-Reply-To: <20040723213844.GA18562@fefe.de>

On Fri, 23 Jul 2004 23:38:44 +0200, Felix von Leitner <leitner@fefe.de> 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

      parent reply	other threads:[~2004-07-28  5:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 16:02 [Qemu-devel] QEMU fails with different levels of compiler optimization André Braga
     [not found] ` <20040723213844.GA18562@fefe.de>
2004-07-28  5:37   ` André Braga [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ad73a04072722372231b102@mail.gmail.com \
    --to=meianoite@gmail.com \
    --cc=leitner@fefe.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).