From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaV8S-0000tt-Ft for qemu-devel@nongnu.org; Tue, 13 Dec 2011 11:23:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaV8N-0001GS-W1 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 11:23:20 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:44630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaV8N-0001GO-PO for qemu-devel@nongnu.org; Tue, 13 Dec 2011 11:23:15 -0500 From: Paul Brook Date: Tue, 13 Dec 2011 16:23:11 +0000 References: <1323507747-16261-1-git-send-email-andreas.faerber@web.de> <201112121558.44919.paul@codesourcery.com> <4EE74F13.9000908@web.de> In-Reply-To: <4EE74F13.9000908@web.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112131623.12363.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH 0/4] tcg: Add debug facilities for TCGv List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?q?F=C3=A4rber?= Cc: Peter Maydell , qemu-devel@nongnu.org > Am 12.12.2011 16:58, schrieb Paul Brook: > >> For me the most annoying issue was that tcg_gen_qemu_{ld,st}* needs > >> TCGv. > > > > You mean the value transferred is always TCGv sized, so ld32u requires an > > additional truncation before doing 32-bit arithmetic? Fixing that is > > completely independent of making TCGv a separate type. > > tcg_gen_qemu_{ld,st} (guest) differs from tcg_gen_{ld,st} (host) in that > they require a TCGv ret/arg (all use TCGv addr). I.e., to read an 8-bit > memory-mapped register on a 64-bit target with tcg_gen_qemu_ld8u we need > a TCGv temporary and trunc to i32 afterwards (smallest currently > available variable size) or unnecessarily blow up storage size to > target_long/TCGv everywhere. > > So, yes, adding an _i32 version may make sense, to at least encapsulate > it at TCG level. > > And without my patches I might have not noticed this design flaw. :) This is purely an optimization issue. If you're concerned about cases where TCG generates dumb code then this is probably the least of your problems. If you omit the truncation then the build will fail. My guess is that in many cases we also manage to optimize away the worst of the redundant extension/truncation. Paul