qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to spe


From: Richard Henderson
Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation?
Date: Tue, 18 Aug 2015 10:55:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 08/18/2015 02:24 AM, Artyom Tarasenko wrote:
> The unoptimized case is a sequence of multiple cmp and branch
> operations (likely created by a "case" statement in the original
> source code), especially where cmp is in a delay slot of a branch
> instruction.

Interesting.

> I wonder whether we always have to finish a TB on a conditional jump.
> Maybe it would make sense to translate further if a destination of a
> jump is not too far from dc->pc? The definition of "not too far" is
> indeed tricky.

We can only handle two chained exits from a TB.  If we continue past
a conditional branch, we may well encounter a second conditional branch, which
would leave us with three different exits from the TB.

Something that may be interesting to play with, however, is to change the TB
with which the insn in a delay slot is connected.

For instance, we currently spend some amount of effort computing and saving the
branch condition, so that we can then execute the delay slot, and afterwards
use the saved branch condition to perform the branch.

Another way of doing this is to immediately branch, exiting the TB.  But we set
up PC+NPC for the next TB such that the delay slot is the first insn that is
executed within the next TB.  In that way, the compare in the delay slot that
you mention *is* in the same TB as the branch that uses it, allowing
the case to be optimized.

This could wind up creating more TBs than the current solution, so it's not
clear that it would be a win.  One can mitigate that somewhat by noticing the
case where the delay slot is a nop.  I do think it's worth an experiment.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]