qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2/3] target-sparc: Free instruction tempora


From: Blue Swirl
Subject: Re: [Qemu-devel] Re: [PATCH 2/3] target-sparc: Free instruction temporaries.
Date: Sat, 17 Apr 2010 21:50:25 +0300

On 4/17/10, Richard Henderson <address@hidden> wrote:
> On 04/17/2010 12:49 PM, Richard Henderson wrote:
>  > On 04/17/2010 11:41 AM, Blue Swirl wrote:
>  >> About this patch: it's good that we now free the constants, but
>  >> constant handling is still not optimal and I think this series
>  >> actually may add extra 'movi' ops in the worst case. It would be nice
>  >> if we detected if constants are in play and call immediate versions
>  >> (addi, subi etc) automatically. This may need bigger refactoring,
>  >> though.
>  >
>  > No, that won't help, since the first thing that addi, subi, etc
>  > do is to load the constant into a temporary.
>  >
>  > What would *really* help though, is something along the lines of
>  > Aurelien's constant propagation patch, followed by some mechanism
>  > to refactor constants in the backend.
>
>
> ... Actually, I forgot to mention that the biggest thing that would
>  help the Sparc target would be to eliminate the explicit loads/stores
>  of the windowed reigsters, such that the generic TCG propagation and
>  dead code elimination passes can do their job properly.

I had postponed that until AREG1/2 are freed, now we could take one
host register for regwptr.

>  I've been meaning to try changing the windowing code on the sparc to
>  memcpy the registers into and out of fixed slots in the CPUState and
>  see what kind of effect that has on overall performance.  I have a
>  feeling that it will be an improvement, since it should avoid some
>  of the myriad of redundant loads and stores in the generated code.

Maybe. Performance figures for that would be very interesting.

Alternative approach could be that If we could rely on all hosts
(especially x86) having plenty of registers, we could even use
different regwptrs for %o, %l and %i sets.

Then there are host page mapping tricks (map the same page at two
locations to simulate wrapping) but that may be too tricky.




reply via email to

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