Re: [Qemu-devel] TCG: AREG0 removal planning

[Blue Swirl]

On Wed, May 11, 2011 at 12:28 AM, Paul Brook <address@hidden> 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?