[Qemu-devel] QEMU fails with different levels of compiler optimization

[Qemu-devel] QEMU fails with different levels of compiler optimization

[André Braga]

First and foremost, I'd like to congratulate Fabrice Bellard and
everyone involved on this project. I've never been so excited with an
opensource emulation project like this, so I decided I just *had* to
jump in :)

Following other's experiments, I tried to build QEMU with different
compiler switches to see if I could get a more optimized binary. I'm
doing this build on mingw on a XP host now, but I have access to
Linux, FreeBSD on the Intel side and Mac OS X on the Apple side (a 1st
generation iMac, not a speed demon), and I might be able to fiddle
with a PA-RISC64 HP-UX machine.

Anyway.  So far, my goal is to produce a working binary with those switches:

CFLAGS=-march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse
-finline-functions -funroll-loops -O2 -s

which are the same I used to build SDL (ASM blitters, 1.2.7. Had to
fix a few declarations on SDL_yuv_mmx.c because they totally forgot
about NASM, it seems).

(I'm not doing -O3 by itself because of register constraints on the
x86, and the -s switch is superfluous, but I like to spare my time and
not run strip every other build. Besides, code that fits the cache is
nice. :))


With these switches, I can *almost* build a working binary. After
manually compiling helper.c changing the flags to "-march=pentium-mmx
-mmmx -finline-functions -funroll-loops -O2 -s" , I can actually load
a knoppix-based image up to the graphical LILO loader. As it gets to
loading the kernel, it fails with exception code  0xC000001E, which is
"STATUS_INVALID_LOCK_SEQUENCE". It might be something with the loop
unrolling or the inlining of functions, but I'd like to have more
guidance on where/how to debug it. I have GDB available but I have no
clue on how to use it in a meaningful way to this project (as I always
steptrace my own programs...).

BTW, the build works flawlessly if I run everything with

CFLAGS=-march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse
-finline-functions -funroll-loops -O2 -s

but only

HELPER_CFLAGS=-Wall -fno-strict-aliasing -O2 -s -fomit-frame-pointer

And surely enough, I hand-editted the makefiles, since they don't seem
to respect my environment... Maybe because CFLAGS is set again and not
re-declared as

CFLAGS?=blah
?

Sice there was already a bug found on GCC exactly on this helper.c
file, I'll not be surprised if this is but another bug, but I'd give
they a little more credit than that and come to this list first.

I might try to build it again with the flags I wanted first and trace
the execution up to the point where it fails, but, still, I'd
appreciate some instructions.

GCC reports itself as 'gcc version 3.2.3 (mingw special 20030504-1)'.
It's the stock one found on mingw site.

I'm running the latest CVS sources, also.


Thanks a lot!
André


PS: I tried to build it with the prerelease GCC3.4 mingw build by
bitWalk (found on http://www63.tok2.com/home/bitwalk/download.html),
but neither SDL nor QEMU build correctly on their toolchain (so I'd
chalk it up to compiler bugs and/or conflicting versions of the
toolchain). I also tried the thisiscool-gcc 3.5 build
(www.thisiscool.com/gcc_mingw.htm), and again it failed. I haven't
tried the thisiscool-gcc 3.4 toolchain yet.

PPS: Nework ain't working, but this seems to be a common problem under
XP host, right? I can ping the host's address, but nothing else works
(no DNS, no CIFS). And sound is also not working, but I haven't yet
applied the patches found on http://www.h7.dion.ne.jp/~qemu-win/ , so
this might be expected.


-- 
"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

[Qemu-devel] Re: QEMU fails with different levels of compiler optimization

[André Braga]

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