On Wed, May 11, 2011 at 12:28 AM, Paul Brook <p...@codesourcery.com> 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 state > 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. helper.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. My guess is that eliminating it from C > code gets us almost all of the useful benefit. Removing 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?
