On 05/11/2011 08:25 PM, Blue Swirl wrote:
>
> 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.
If you use a callee-saved register then you don't need to restore it.
Looks like that's already the case, at least on x86.
--
error compiling committee.c: too many arguments to function
