From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3C9N-0000Qd-Uu for qemu-devel@nongnu.org; Sat, 17 Apr 2010 13:49:49 -0400 Received: from [140.186.70.92] (port=36758 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3C9M-0000QR-Kp for qemu-devel@nongnu.org; Sat, 17 Apr 2010 13:49:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3C9L-0003o6-Js for qemu-devel@nongnu.org; Sat, 17 Apr 2010 13:49:48 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:44473) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3C9L-0003nu-4Y for qemu-devel@nongnu.org; Sat, 17 Apr 2010 13:49:47 -0400 Received: by gyd5 with SMTP id 5so1850454gyd.4 for ; Sat, 17 Apr 2010 10:49:46 -0700 (PDT) Sender: Richard Henderson Message-ID: <4BC9F4AC.1080001@twiddle.net> Date: Sat, 17 Apr 2010 12:49:32 -0500 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/3] target-sparc: Free instruction temporaries. References: <1271429444-900-1-git-send-email-rth@twiddle.net> <1271429444-900-2-git-send-email-rth@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org 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. Aurelien's patch does a good job of building the full constant that the RISC instruction stream needed to use to generate the full 32-bit or 64-bit constant. If the host is x86, that's just about all we need. However, if the host is a RISC, we'll generally need to decompose the constant again. I've got the outline of an idea by which TCG can remember which constants are actually loaded into registers. And it should be designed so that the host backend can call into it to load other constants. In this way when we have a pair of constants like 0xfff00011 0xfff00022 the sparc backend can (if things go well with register allocation) load the %hi(0xfff00000) just once, and form the full constants with addition from there. r~