From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdPif-0000bF-HR for qemu-devel@nongnu.org; Tue, 27 Nov 2012 13:17:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdPiZ-0006UQ-Gs for qemu-devel@nongnu.org; Tue, 27 Nov 2012 13:17:17 -0500 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:56458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdPiZ-0006UD-9Y for qemu-devel@nongnu.org; Tue, 27 Nov 2012 13:17:11 -0500 Message-ID: <50B503A2.20003@weilnetz.de> Date: Tue, 27 Nov 2012 19:17:06 +0100 From: Stefan Weil MIME-Version: 1.0 References: <1354033263-32748-1-git-send-email-pbonzini@redhat.com> <50B4E924.109@suse.de> <50B4EA92.60805@redhat.com> In-Reply-To: <50B4EA92.60805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1.3] build: compile translate.o with -fno-gcse option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: peter.maydell@linaro.org, kraxel@redhat.com, Alexander Graf , qemu-devel@nongnu.org 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