From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rjrr2-0003Vz-C7 for qemu-devel@nongnu.org; Sun, 08 Jan 2012 07:28:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rjrr0-0007EF-O7 for qemu-devel@nongnu.org; Sun, 08 Jan 2012 07:28:04 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:56779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rjrr0-0007EB-Jt for qemu-devel@nongnu.org; Sun, 08 Jan 2012 07:28:02 -0500 Received: by iagj37 with SMTP id j37so6217871iag.4 for ; Sun, 08 Jan 2012 04:28:02 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20120108005247.GA20125@hall.aurel32.net> References: <20120108005247.GA20125@hall.aurel32.net> From: Blue Swirl Date: Sun, 8 Jan 2012 12:27:39 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/6] AREG0 patches v4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel On Sun, Jan 8, 2012 at 00:52, Aurelien Jarno wrote: > On Sat, Jan 07, 2012 at 10:24:09PM +0000, Blue Swirl wrote: >> In this version, I made basic AREG0 free load/store implementations >> for all targets. Only x86-64 is tested, others have probably problems, >> especially 64 bit guest (Sparc64 in this case) on 32 bit hosts. >> >> I think this should be committed as a starting point if there are no >> major objections. >> > > If it is known to be broken on 32-bit hosts, I am not sure it's really > a good idea to commit these patches. It's just going to prevent all > people developing on x86 to continue testing or developing QEMU. No, the brokenness is limited to 32 bit hosts with 64 bit AREG0 free targets, which currently means Sparc64 on i386, Sparc64 on ARM etc. Sparc32 should run unless there are other problems. Other targets which are not AREG0 free (like x86) should be unchanged on any host. I'm not familiar with various host ABIs, fixing all of the targets is too m= uch. > Also I have to say I still don't get the goal of these patch series. I > have just tried it on an x86-64 guest with a 32-bit sparc guest. It > works well, but the generated TB are slightly bigger. I have done a > quick and dirty performance test by compiling some code inside the > guests, and I get a slow down of about 0.6%, though for this kind of > performance changes, it should probably done with other methods. Thank you for testing. I also made some tests earlier which were near that figure but there performance increased. But my test setup adds a lot of noise (CPU throttling etc.) so I didn't trust the figures much. The slow down could come from changed compiler flags. IIRC looking at disassembled functions, stack protector kicks in. > Is there another goal behind this patch series beside performance? Yes, we eliminate the global register variable, which has given us a lot of trouble. Those are not supported by for example LLVM or sparse. The semantics of calling code which has not been compiled with register variables from code which has been compiled so is not defined, but it happens to work most of the time by saving the variable by hand. On Sparc hosts, global register handling is a mess. After the change has been made, all QEMU code is just plain C. With TCI it should even be portable to any host. When AREG0 is only used internally to TCG generated code, we could even put the CPUState structure to stack and use stack pointer to access them, freeing a global variable there too. > -- > Aurelien Jarno =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPG: 1024D/F1BCDB73 > aurelien@aurel32.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 http://www.aurel32.net