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

[Richard Henderson]

On 05/10/2011 01:54 PM, Blue Swirl wrote:
> TCG the generator backend
> -AREG0 is used for qemu_ld/st ops for TLB access. It should be
> possible for the translators to pass instead a pointer to either
> CPUState or directly to the TLB.

I believe that AREG0 should continue to be present in the generated
code.  There are simply too many references to it throughout the
translated code for allocating this dynamically to be a win.

What should change, however, is the removal of AREG0 outside the
generated code.  The cpu-state pointer should be passed as a regular
parameter wherever it is required.  This includes tcg_qemu_tb_exec,
which means that the generated prologue would change, setting up
AREG0 in the process.

> New qemu_ld/st ops are needed for all TCG targets.

Yes, qemu_ld/st would have to change to accommodate the new parameter
being passed.

While we're at it, let us change things a bit further to allow guest
byte-swap load/store insns to be implemented more efficiently.  For
instance, currently a sparc load_asr (little-endian), as emulated on
an x86 host, does the byte swap twice.

There is, currently, a const int parameter to qemu_ld/st that encodes
the size of the load.  Almost all TCG backends behind the scenes 
extend this parameter with a bit to indicate byte swap needed.  Let us
formalize this, and allow this to be set in the original TCG op, with
appropriate new inlines in tcg-op.h to access it from the translators.

We can also make things easier for the backends by allowing them
to declare that they do or do not have byte swap load/store insns.
If the such are not available, a separate bswap opcode is emitted
right from tcg_gen_qemu_st32 et al.

This would allow a nice cleanup for i386, which currently has a small
register allocation problem in the store path, what with needing to
not clobber the input register while byte swapping.  (This problem is
solved by restricting the set of input registers for qemu_ld/st.)

All this does require the slow path to be changed to accommodate this.
In particular, if byte-swap memory ops are available, we need slow
path functions that also byte swap.  Indeed, I'd expect them to use
the byte-swap memory ops themselves.  Further, if byte-swap memory
ops are not available, the slow path should always return memory in
the host byte order, because a separate bswap operation will be done
on behalf of the fast path.

> -TCG temps are stored in CPUState field temp_buf[], accessed via
> AREG0. Maybe a regular stack frame should be allocated instead?

Probably.  Most of the backends manage a stack frame anyway, to
handle registers saved in the prologue.  All that would be needed
is a define from TCG to tell the backends how much memory is required,
and some value passed from the backends to tell TCG what the offset
of that area is from the stack pointer.


r~