From: "André Braga" <meianoite@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [patch] performance improvement (softmmu, x86, GCC 3)
Date: Wed, 4 Aug 2004 14:21:59 -0300 [thread overview]
Message-ID: <2ad73a04080410213b0ca110@mail.gmail.com> (raw)
In-Reply-To: <20040804125018.64462.qmail@web52508.mail.yahoo.com>
Hmmm, that's very, very interesting (and exciting)! Squeezing any
ounce of performance out of QEMU is *very* desirable IMO, provided
that it doesn't break compatibility with other architectures. I'd
personally enjoy to see a patch (better yet, three discrete and
independent patches) that disable GCSE (this one is done!), introduce
the "ecx thing" (sorry if I have no idea what you meant in your
message about this -- a patch with some code would certainly help) and
another one that manually inlines the function you mentioned. All in
all, I'd like to see all the code working without special GCC switches
that are not pro-optimization ones, because I see those as
regressions.
Could you send me these patches? I'd glad to test them! I'm not sure
if I can be any more helpful than this since I'm just beginning to get
familiar to the emulation techniques of QEMU, let alone the code by
itself...
----- Original Message -----
From: Piotr Krysik <piotrek_priv@yahoo.com>
Date: Wed, 4 Aug 2004 05:50:18 -0700 (PDT)
Subject: Re: [Qemu-devel] [patch] performance improvement (softmmu, x86, GCC 3)
To: qemu-devel@nongnu.org
Hi,
The "ecx thing" and disabling GCSE are not mutually
exclusive, but I didn't try to run/benchmark QEMU with
both. I'm not GCC guru, but I believe that it should not
significantly impact QEMU performance. If you are willing
to do some tests I could send you the "ecx" patch.
And yes, I tried different combinations of -fno-gcse
suboptions, but none worked.
To get more information about the problem, I used
compiler -da flag to trace GCC optimizations of
op_rolb_kernel_T0_T1_cc. I discovered that GCSE step
is introducing transformation that cannot be optimized
later. GCC insists on using copy of T0 value, instead of
using register ebx globally reserved for T0 (and as there
are no free register it gives error). The strangest thing
I noticed is that if I inline stXXXX function by hand instead
of using inline directive, problem disappears.
Piotrek
--
"Dealing with failure is easy: Work hard to improve. Success is also
easy to handle: You've solved the wrong problem. Work hard to improve"
Alan J. Perlis
next prev parent reply other threads:[~2004-08-04 17:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-28 14:24 [Qemu-devel] [patch] performance improvement (softmmu, x86, GCC 3) Piotr Krysik
2004-07-31 5:00 ` André Braga
2004-08-04 12:50 ` Piotr Krysik
2004-08-04 17:21 ` André Braga [this message]
2004-08-05 1:43 ` Piotr Krysik
2004-08-03 21:21 ` Fabrice Bellard
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=2ad73a04080410213b0ca110@mail.gmail.com \
--to=meianoite@gmail.com \
--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).