Re: [Qemu-devel] [PATCH v2 1.3] build: compile translate.o with -fno-gcse option

[Stefan Weil]

Am 27.11.2012 17:30, schrieb Paolo Bonzini:
> Il 27/11/2012 17:24, Alexander Graf ha scritto:
> > > +# Workaround for http://gcc.gnu.org/PR55489.  Happens with -fPIE/-fPIC
> > > +# and large functions that use global variables.  The bug is in all
> > > +# releases of GCC, but it became particularly acute in 4.7.x.  We
> > > +# should be able to delete this at the end of 2013.
> > Can we add a version check for gcc here?
> I don't think it is useful unless somebody finds that the patch gives
> substantially worse TCG performance.
>
> Paolo


Hi Paolo,

latest native MinGW-w64 uses gcc 4.7.2 for w64. It compiles */translate.c
without needing too much RAM.

In a short test, I compiled target-ppc/translate.c without and with 
-fno-gcse.
This compiler option increases compilation speed a little and creates a 
smaller
binary (tested with Debian amd64-mingw32msvc-gcc 4.4.4):

standard

time: user    0m31.966s
size: 1113760      70216       1376    1185352  121648    
target-ppc/translate.o

with -fno-gcse

time: user    0m30.542s
size: 1111056      70216       1376    1182648  120bb8    
target-ppc/translate.o

To summarize, -fno-gcse is not needed for MinGW, but I don't expect
that it would do any harm there.

A real problem could arise from compilers which don't support -fno-gcse.
As this option is not checked for compatibility in configure, such compilers
would no longer work with unmodified QEMU sources. clang obviously
supports -fno-gcse, so maybe we don't have a real problem currently.

For the buildbot machines, "configure --enable-debug" wouldsolve the
OOM problem, dramatically reduce compilation time, add some
compile time checks for TCG, reduce CO2 emission, ... For most buildbots,
--enable-debug would be a good choice. There are some kinds of errors
which compilers only detect during their optimization pass, so some
buildbots should still run without --enable-debug.

Do we need -fno-gcse for all */translate.c or only for some of them?

The problem with gcc using large quantities of RAM for those files
is not new (it was a good RAM tester on a defective PC some time
ago for me). I think it is caused by huge switch statements
in those files. Splitting those switch statements might also help.
If the memory needed grows with n * n (n = number of case statements
in one switch statement), then splitting a switch statement in two
would reduce the memory needed from 2 GiB to 0.5 GiB.

Regards
Stefan