[Qemu-devel] yet another proposed solution for gcc 4.x

[Qemu-devel] yet another proposed solution for gcc 4.x

[Carlo Marcelo Arenas Belon]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Greetings,

attached patch, adds a ./configure option for setting the C compiler that will
be used to build op.c for each of the targets; letting the user compile
everything else with gcc 4.x if configured as the default C compiler while
isolating the opcode generation which currently relies in gcc 3.x for dyngen
to be able to make sense of it.

tested it in a gentoo 2006.0 system (amd64) using gcc-4.1.1 to compile
qemu-0.8.1 and the CVS HEAD, by instructing qemu to use gcc-3.4.5 for op.c,
configuring it with :

  ./configure --op-cc=gcc-3.4.5 --disable-gcc-check

didn't modify the gcc-check function in ./configure to test $op_cc instead to
minimize the changes proposed, and because I wasn't sure that doing so was
beneficial to the end user without a description of the options that can be
used to select a different compiler for different parts of the code.

FYI gcc-4.1.1 is not able to compile qemu-0.8.1 or the CVS HEAD because it
confuses dyngen and makes it generate invalid code as can be seen in gentoo's
bug 132667.

  https://bugs.gentoo.org/show_bug.cgi?id=132667

and which includes a hacky fix (by using a helper function), but i consider
wasn't worth fixing as the resulting binary won't work at all (as expected).

Carlo

[-- Attachment #2: qemu-opcc.patch --]
[-- Type: text/plain, Size: 2524 bytes --]

Index: Makefile.target
===================================================================
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.113
diff -u -p -r1.113 Makefile.target
--- Makefile.target	30 May 2006 01:48:12 -0000	1.113
+++ Makefile.target	4 Jun 2006 07:53:52 -0000
@@ -445,7 +445,7 @@ gen-op.h: op.o $(DYNGEN)
 	$(DYNGEN) -g -o $@ $<
 
 op.o: op.c
-	$(CC) $(OP_CFLAGS) $(DEFINES) -c -o $@ $<
+	$(OP_CC) $(OP_CFLAGS) $(DEFINES) -c -o $@ $<
 
 helper.o: helper.c
 	$(CC) $(HELPER_CFLAGS) $(DEFINES) -c -o $@ $<
Index: configure
===================================================================
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.102
diff -u -p -r1.102 configure
--- configure	14 May 2006 11:30:38 -0000	1.102
+++ configure	4 Jun 2006 07:53:53 -0000
@@ -23,6 +23,7 @@ static="no"
 cross_prefix=""
 cc="gcc"
 host_cc="gcc"
+op_cc="gcc"
 ar="ar"
 make="make"
 install="install"
@@ -182,6 +183,8 @@ for opt do
   ;;
   --host-cc=*) host_cc="$optarg"
   ;;
+  --op-cc=*) op_cc="$optarg"
+  ;;
   --make=*) make="$optarg"
   ;;
   --install=*) install="$optarg"
@@ -271,6 +274,7 @@ echo "  --source-path=PATH       path of
 echo "  --cross-prefix=PREFIX    use PREFIX for compile tools [$cross_prefix]"
 echo "  --cc=CC                  use C compiler CC [$cc]"
 echo "  --host-cc=CC             use C compiler CC [$host_cc] for dyngen etc."
+echo "  --op-cc=CC               use C compiler CC [$op_cc] for op.c"
 echo "  --make=MAKE              use specified make [$make]"
 echo "  --install=INSTALL        use specified install [$install]"
 echo "  --static                 enable static build [$static]"
@@ -417,7 +421,7 @@ int main(void) {
 EOF
 
 have_gcc3_options="no"
-if $cc -fno-reorder-blocks -fno-optimize-sibling-calls -o $TMPO $TMPC 2> /dev/null ; then
+if $op_cc -fno-reorder-blocks -fno-optimize-sibling-calls -o $TMPO $TMPC 2> /dev/null ; then
    have_gcc3_options="yes"
 fi
 
@@ -522,6 +526,7 @@ fi
 echo "Source path       $source_path"
 echo "C compiler        $cc"
 echo "Host C compiler   $host_cc"
+echo "OP C compiler     $op_cc"
 echo "make              $make"
 echo "install           $install"
 echo "host CPU          $cpu"
@@ -588,6 +593,7 @@ if test "$have_gcc3_options" = "yes" ; t
   echo "HAVE_GCC3_OPTIONS=yes" >> $config_mak
 fi
 echo "HOST_CC=$host_cc" >> $config_mak
+echo "OP_CC=$op_cc" >> $config_mak
 echo "AR=$ar" >> $config_mak
 echo "STRIP=$strip -s -R .comment -R .note" >> $config_mak
 echo "CFLAGS=$CFLAGS" >> $config_mak

Re: [Qemu-devel] yet another proposed solution for gcc 4.x

[Paul Brook]

On Sunday 04 June 2006 09:59, Carlo Marcelo Arenas Belon wrote:
> Greetings,
>
> attached patch, adds a ./configure option for setting the C compiler that
> will be used to build op.c for each of the targets; letting the user
> compile everything else with gcc 4.x if configured as the default C
> compiler while isolating the opcode generation which currently relies in
> gcc 3.x for dyngen to be able to make sense of it.

Why bother? As you say gcc4 has issues other than just op.c, so why not just 
compile everything with the old gcc?

Paul

Re: [Qemu-devel] yet another proposed solution for gcc 4.x

[Carlo Marcelo Arenas Belon]

<SNIP>
> Why bother? As you say gcc4 has issues other than just op.c, so why not just 
> compile everything with the old gcc?

using the new gcc for the parts that can compile with it, could lead to better
performance in some cases, as well to help clean up the code for conformance
to newer standards and overall maintainability, while making also clear that 
there are at least 2 different uses for gcc.

1) to compile the code for qemu to generate working binaries
2) to generate the code to be used for opcode translation

this will free us to work in whatever technical solutions are needed to fix 2)
in our own schedule without the pressure from all the people that now feel
compelled to "port" qemu to a newer gcc, because it is now the default on
their corresponding distributions.

the long term solution for 2) will be to get the qemu hand written code
generator completed, but could also include having an in tree version of gcc
that can be used for that simple purpose (like a dependant library/tool) or a
reference to an external one as a dependency, and as an intermediate step.

Carlo

PS. eventhough it wasn't the cleanest build, gcc-4.1.1 when used to build
everything but op.c resulted in working binaries on my gentoo 2006.0 amd64
system.

Re: [Qemu-devel] yet another proposed solution for gcc 4.x

[Christian MICHON]

On 6/4/06, Carlo Marcelo Arenas Belon wrote:
> PS. eventhough it wasn't the cleanest build, gcc-4.1.1 when used to build
> everything but op.c resulted in working binaries on my gentoo 2006.0 amd64
> system.

did you get better benchmark results than using gcc-3.x ?

-- 
Christian

Re: [Qemu-devel] yet another proposed solution for gcc 4.x

[Carlo Marcelo Arenas Belon]

On Mon, Jun 05, 2006 at 01:21:48PM +0200, Christian MICHON wrote:
> did you get better benchmark results than using gcc-3.x ?

proportionally to native execution, yes (the gcc-4.1.1's compiled sha1-i386 
binary from the tests was slower than the one compiled with gcc-3.4.5)

results for running in an amd64 box with native x86 support and no kqemu for a
manually tweaked (as the Makefile won't work for amd64) `make speed` shown 
below :

for the gcc-3.4.5 compiled qemu 0.8.1 (vanilla untar in /var/tmp):

carenas@laptop /var/tmp/qemu-0.8.1/tests $ cat ../config-host.mak | grep CC
CC=gcc-3.4.5
HAVE_GCC3_OPTIONS=yes
HOST_CC=gcc-3.4.5

carenas@laptop /var/tmp/qemu-0.8.1/tests $ gcc-3.4.5 -m32 -Wall -O2 -g -o
sha1-i386 sha1.c 

carenas@laptop /var/tmp/qemu-0.8.1/tests $ time ./sha1-i386 
SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6

real    0m0.027s
user    0m0.025s
sys     0m0.001s

carenas@laptop /var/tmp/qemu-0.8.1/tests $ time ../i386-user/qemu-i386
./sha1-i386 
SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6

real    0m0.255s
user    0m0.250s
sys     0m0.005s

carenas@laptop /var/tmp/qemu-0.8.1/tests $ echo | awk '{ print 255/27; }'
9.44444

for the patched qemu with hybrid compilers (patched in /var/tmp with
directory name qemu-0.8.1-hybrid)

carenas@laptop /var/tmp/qemu-0.8.1-hybrid/tests $ cat ../config-host.mak |
grep CC
CC=gcc
HAVE_GCC3_OPTIONS=yes
HOST_CC=gcc
OP_CC=gcc-3.4.5

carenas@laptop /var/tmp/qemu-0.8.1-hybrid/tests $ gcc -m32 -Wall -O2 -g -o
sha1-i386 sha1.c

carenas@laptop /var/tmp/qemu-0.8.1-hybrid/tests $ time ./sha1-i386 
SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6

real    0m0.031s
user    0m0.030s
sys     0m0.000s

carenas@laptop /var/tmp/qemu-0.8.1-hybrid/tests $ time ../i386-user/qemu-i386
./sha1-i386 
SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6

real    0m0.287s
user    0m0.284s
sys     0m0.004s

carenas@laptop /var/tmp/qemu-0.8.1-hybrid/tests $ echo | awk '{ print 287/31;
}'
9.25806

Carlo

PS. is there any "standard" way to benchmark qemu that is all agreed upon as
authoritative other than `make speed`?
PS2. showing here the output of a typical sample, but obviously i run them
several times to eliminate any statistical noise.

Re: [Qemu-devel] yet another proposed solution for gcc 4.x

[Paul Brook]

(everything compiled with gcc3)
> user    0m0.250s
> 9.44444
(everything compiled with gcc4)
> user    0m0.284s
> 9.25806

Your comparison is not valid. You should only change one variable at once.
We don't care whether a gcc4 sha1 is faster or slower than gcc3 sha1. By your 
own numbers gcc4 is slower in absolute terms. We only care whether qemu goes 
faster or slower when running the same binary.

You should also state how any runs you did and what the variation is. 
Especially on modern systems there can be a lot of variation between 
successive runs.

> PS. is there any "standard" way to benchmark qemu that is all agreed upon as
> authoritative other than `make speed`?

Not really. Also, simple benchmarks (which tend to be dominated by a 
single "hot" loop) are not neccly a representative measure of qemu 
performance.

Paul