From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKDAd-0000G2-NR for qemu-devel@nongnu.org; Wed, 11 May 2011 13:26:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QKDAc-0007hz-1j for qemu-devel@nongnu.org; Wed, 11 May 2011 13:25:59 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:33691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKDAb-0007hq-RL for qemu-devel@nongnu.org; Wed, 11 May 2011 13:25:57 -0400 Received: by qyk10 with SMTP id 10so436033qyk.4 for ; Wed, 11 May 2011 10:25:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201105102228.37340.paul@codesourcery.com> References: <201105102228.37340.paul@codesourcery.com> From: Blue Swirl Date: Wed, 11 May 2011 20:25:36 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] TCG: AREG0 removal planning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel On Wed, May 11, 2011 at 12:28 AM, Paul Brook wrote: >> TCG uses a fixed global register (AREG0) to which points to currently >> used CPUState, also known as 'env'. Using a fixed register has the >> downsides that the register must be reserved by TCG for generated code >> and by the compiler for compiling a few critical files (op_helper.c >> etc.). The latter also means that any calls to C library may be unsafe >> from those files. >> >> Here are my sketches about transition to AREG0-less world. >> ... >> Translators/op helpers >> ... >> Comments? There are a few blank spots too. > > I think a useful, and incremental goal is elimination of global cpu_env s= tate > in C code (i.e eliminate HELPER_CFLAGS and dyngen-exec.h). > We already have much of the infrastructure for this - op_helper v.s. help= er.c > and code_gen_prologue for transition in/out of "generated code" state. > > In practice generated code probably accesses CPUState often enough that a > dedicated register isn't a bad idea. =C2=A0My guess is that eliminating i= t from C > code gets us almost all of the useful benefit. =C2=A0Removing it from the= code > generator (i.e. TCG_AREG0) may be more pain that it's worth. I don't think moving the helpers from op_helper.c to helper.c will be a performance win if AREG0 is not eliminated. The code gets to use one register more, but AREG0 needs to be moved to a function argument register in most cases and AREG0 has to be restored. I think the benefit should come from generated code getting one more available register. TCG side doesn't look so difficult, just qemu_ld/st ops and using a stack frame. Converting translators and helpers is a much bigger job. > For changes to > the TCG side we want to consider how we can provide useful aliasing > information, rather than a naive replacement of TCG_AREG0 with a variable= . What aliasing information?