From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3D68-0005yS-Q0 for qemu-devel@nongnu.org; Sat, 17 Apr 2010 14:50:32 -0400 Received: from [140.186.70.92] (port=35973 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3D66-0005xk-JL for qemu-devel@nongnu.org; Sat, 17 Apr 2010 14:50:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3D62-0000CA-Qp for qemu-devel@nongnu.org; Sat, 17 Apr 2010 14:50:30 -0400 Received: from mail-pz0-f204.google.com ([209.85.222.204]:42913) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3D62-0000Be-Hl for qemu-devel@nongnu.org; Sat, 17 Apr 2010 14:50:26 -0400 Received: by pzk42 with SMTP id 42so2648466pzk.4 for ; Sat, 17 Apr 2010 11:50:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BC9F749.70608@twiddle.net> References: <1271429444-900-1-git-send-email-rth@twiddle.net> <1271429444-900-2-git-send-email-rth@twiddle.net> <4BC9F4AC.1080001@twiddle.net> <4BC9F749.70608@twiddle.net> Date: Sat, 17 Apr 2010 21:50:25 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 2/3] target-sparc: Free instruction temporaries. From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On 4/17/10, Richard Henderson 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.