From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IR7S4-0004Zy-E4 for qemu-devel@nongnu.org; Fri, 31 Aug 2007 10:26:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IR7S2-0004Y1-Ow for qemu-devel@nongnu.org; Fri, 31 Aug 2007 10:26:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IR7S2-0004Xm-Fh for qemu-devel@nongnu.org; Fri, 31 Aug 2007 10:26:22 -0400 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IR7S2-0006SD-1U for qemu-devel@nongnu.org; Fri, 31 Aug 2007 10:26:22 -0400 Date: Fri, 31 Aug 2007 15:17:33 +0100 From: Thiemo Seufer Subject: Re: [Qemu-devel] [patch] make qemu work with GCC 4 Message-ID: <20070831141733.GA4938@networkno.de> References: <20070830202811.GA11732@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Matz Cc: qemu-devel@nongnu.org, Alexander Graf Michael Matz wrote: > Hi, > > On Thu, 30 Aug 2007, Thiemo Seufer wrote: > > > > * ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared > > > to deal with the relocs resulting from using section anchors > > > > Maybe this should be handled more generally then, not ppc specific, like > > other "offending" compiler options: check if the compiler knows the > > option, if yes, disable the feature. > > Yeah, like is done for the other additions to OP_CFLAGS, which are guarded > by $(call cc-option, ...). > > > > I solved that by placing one of the T[012] operands into memory > > > for HOST_I386, thereby freeing one reg. Here's some justification > > > of why that doesn't really cost performance: with three free regs > > > GCC is already spilling like mad in the snippets, we just trade one > > > of those memory accesses (to stack) with one other mem access to > > > the cpu_state structure, which will be in cache. > > > > Could you back up this assumption with some numbers? :-) > > I did that downthread. To me the slowdown is not significant enough, > although it exists. I would like to have it conditional on GCC4. > > > --- qemu-0.9.0.cvs.orig/target-arm/cpu.h 2007-06-24 14:09:48.000000000 +0200 > > > +++ qemu-0.9.0.cvs/target-arm/cpu.h 2007-08-21 21:38:36.000000000 +0200 > > > @@ -52,6 +52,9 @@ typedef uint32_t ARMReadCPFunc(void *opa > > > */ > > > > > > typedef struct CPUARMState { > > > +#if defined(HOST_I386) > > > + uint32_t t1; > > > +#endif > > > /* Regs for current mode. */ > > > uint32_t regs[16]; > > > /* Frequently accessed CPSR bits are stored separately for efficiently. > > > diff -urp qemu-0.9.0.cvs.orig/target-arm/exec.h qemu-0.9.0.cvs/target-arm/exec.h > > > --- qemu-0.9.0.cvs.orig/target-arm/exec.h 2007-06-03 19:44:36.000000000 +0200 > > > +++ qemu-0.9.0.cvs/target-arm/exec.h 2007-08-21 21:48:48.000000000 +0200 > > > @@ -23,7 +23,12 @@ > > > register struct CPUARMState *env asm(AREG0); > > > register uint32_t T0 asm(AREG1); > > > register uint32_t T1 asm(AREG2); > > > +#ifndef HOST_I386 > > > register uint32_t T2 asm(AREG3); > > > +#else > > > +#define T2 (env->t1) > > > +#endif > > > > T2/t1 mismatch, it seems. Likewise for mips and ppc. > > Yes, well, I could have named the env member perhaps "temp" :-) I can > change it, though. I did expect T2 to map to env->t2, like it is done for 64bit-emu on 32bit-host. It keeps things a bit more comprehensible. :-) Thiemo