Re: [Qemu-devel] [PATCH v5 0/3] tcg: enhance code generation quality for qemu_ld/st IRs

[Aurelien Jarno]

On Wed, Oct 10, 2012 at 01:17:36PM +0900, Yeongkyoon Lee wrote:
> On 2012년 10월 10일 02:09, Aurelien Jarno wrote:
> >On Tue, Oct 09, 2012 at 06:55:58PM +0200, Paolo Bonzini wrote:
> >>Il 09/10/2012 18:19, Aurelien Jarno ha scritto:
> >>>>>Instead of calling the MMU helper with an additional argument (7), and
> >>>>>then jump back (8) to the next code (4), what about pushing the address
> >>>>>of the next code (4) on the stack and use a jmp instead of the call. In
> >>>>>that case you don't need the extra argument to the helpers.
> >>>>>
> >>>Maybe it wasn't very clear. This is based on the fact that call is
> >>>basically push %rip + jmp. Therefore we can fake the return address by
> >>>putting the value we want, here the address of the next code. This mean
> >>>that we don't need to pass the extra argument to the helper for the
> >>>return address, as GET_PC() would work correctly (it basically reads the
> >>>return address on the stack).
> >>>
> >>>For other architectures, it might not be a push, but rather a move to
> >>>link register, basically put the return address where the calling
> >>>convention asks for.
> >>>
> >>>OTOH I just realized it only works if the end of the slow path (moving
> >>>the value from the return address to the correct register). It might be
> >>>something doable.
> >>Branch predictors will not oldschool tricks like this one. :)
> >>
> >Given it is only used in the slow path (ie the exception more than the
> >rule), branch prediction isn't that important there.
> >
> 
> I had already considered the approach of using jmp and removing
> extra argument for helper call.
> However, the problem is that the helper needs the gen code addr used
> by tb_find_pc() and cpu_restore_state().
> That means the code addr in the helper can be actually said the addr
> corresponding to QEMU_ld/st IR rather than the return addr.
> In my LDST optimization, the helper call site is not in the code of
> IR but in the end of TB.

GETPC() uses the return address to determine the call place, and as long
as the code at the end of the TB set a return address corresponding to
the one of the fast path instructions, tb_find_pc() will be able to find
the correct instruction.

That implies that at least one instruction at the end of the generated
code is shared between the slow path and the fast path, but in the other
hand it avoids having to different kind of mmu helpers.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net