From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNid6-0007N2-Lv for qemu-devel@nongnu.org; Sat, 21 May 2011 05:37:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNid5-000472-E9 for qemu-devel@nongnu.org; Sat, 21 May 2011 05:37:52 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:42600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNid5-00046y-Bl for qemu-devel@nongnu.org; Sat, 21 May 2011 05:37:51 -0400 Received: by qyk10 with SMTP id 10so2578963qyk.4 for ; Sat, 21 May 2011 02:37:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <009487ED-9D21-4779-A064-30044601B443@web.de> References: <4DD6A9F9.7040805@twiddle.net> <20110520193741.GC27170@hall.aurel32.net> <009487ED-9D21-4779-A064-30044601B443@web.de> Date: Sat, 21 May 2011 11:37:49 +0200 Message-ID: From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/6] Implement constant folding and copy propagation in TCG List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: mj.mccormack@samsung.com, qemu-devel@nongnu.org, zhur@ispras.ru, Kirill Batuzov , Aurelien Jarno , Richard Henderson On Sat, May 21, 2011 at 1:31 AM, Andreas F=E4rber = wrote: [...] > Has anyone evaluated reusing LLVM optimization passes for TCG? Or maybe > GIMPL if there's an equivalent? IMHO the qemu_ld/st semantics and the size of TB blocks will always limit the usefulness of more involved optimizations than what already exists in QEMU. Basically qemu_ld/st ops prevent any code change across them which make optimization opportunities rather low. Considering they always take the fast path would surely change the situation, but then the slow path would have to be able to rebuild information; certainly possible, but quite involved too :-) Once this qemu_ld/st change is done, you'll the need to get to the problem of too short TB blocks; a way to do this is to generate traces of frequently executed blocks and consider them as a single block[1]; that would open the door to many more code generation improvements. This certainly doesn't mean Kirill and Aur=E9lien changes are not welcome, just that I think, in the current state, such changes will always have a limited impact. Laurent [1] See for instance section 2.3 of Derek Bruening's PhD thesis about DynamoRIO http://www.burningcutlery.com/derek/phd.html