From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Karg6-0000an-VR for qemu-devel@nongnu.org; Wed, 03 Sep 2008 08:41:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Karg6-0000aM-7y for qemu-devel@nongnu.org; Wed, 03 Sep 2008 08:41:42 -0400 Received: from [199.232.76.173] (port=57021 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Karg5-0000aH-QI for qemu-devel@nongnu.org; Wed, 03 Sep 2008 08:41:41 -0400 Received: from hall.aurel32.net ([91.121.138.14]:52265) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Karg6-0005uP-1w for qemu-devel@nongnu.org; Wed, 03 Sep 2008 08:41:42 -0400 Date: Wed, 3 Sep 2008 14:41:39 +0200 From: =?iso-8859-15?Q?Aur=E9lien?= Jarno Subject: Re: [Qemu-devel] [PATCH 5/x] ppc: Convert op_load_gpr_{T0, T1, T2} to TCG Message-ID: <20080903124139.GA9674@hall.aurel32.net> References: <1F0A98C0-A1DE-4548-8A4D-9E15EDC72686@web.de> <5CA2F35D-6016-4FE5-8289-EB8758A2D3A4@web.de> <5FBA68BE-2F96-41D9-B032-BCA4A96557A7@web.de> <16A6085C-BD53-4AB5-8E39-0CA993CE12FF@web.de> <8E69B597-ADAC-4E4B-A675-45FEDDAF65BF@web.de> <20080902232051.GS4681@volta.aurel32.net> <20080903050757.GX4681@volta.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Aurelien Jarno Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-15?Q?F=E4rber?= Cc: qemu-devel@nongnu.org On Wed, Sep 03, 2008 at 12:41:01PM +0200, Andreas Färber wrote: > > Am 03.09.2008 um 07:07 schrieb Aurelien Jarno: > > >On Wed, Sep 03, 2008 at 02:39:52AM +0200, Andreas Färber wrote: > >> > >>Am 03.09.2008 um 01:20 schrieb Aurelien Jarno: > >> > >>> > >>>>+ for (i = 0; i < 32; i++) { > >>>>+ cpu_gpr[i] = tcg_global_mem_new(TCG_TYPE_TL, TCG_AREG0, > >>>>+ offsetof(CPUState, > >>>>gpr[i]), > >>>>+ gprnames[i]); > >>> > >>>This is most probably wrong given the definition of ppc_gpr_t in > >>>cpu.h: > >>>- 64 bits on 64-bit targets > >>>- 32 bits on 32-bit targets and 32-bit hosts > >>>- *64 bits* on 32-bit targets and 64-bit hosts > >>> > >>>I think it is a bit weird, and I think the best is to modify cpu.h > >>>in > >>>order to have ppc_gpr_t matching the target bitness. > >> > >>This might be related to the 64-on-32 issue I just posted about. I > >>don't > >>remember seeing code that makes use of this sophisticated definition > >>though, for non-ppc64 it apparently uses a set of 32-bit gpr and gprh > >>variables. Let's not change ppc_gpr_t for now. > > > >Well that's different, your previous post is about T_* registers, I am > >speaking about the GPR registers. And either ppc_gpr_t or the init > >code > >of cpu_gpr[i] has to be changed, otherwise you will break existing > >targets. > > I'm quite sure it is related - the issue is that GPR / T TCGv size > does not always correspond to tl, and the only problem is the 32-bit > target with 64-bit host. > > Would there be a problem with using i64 in the 32-on-64 case? That is, > would it hurt to do i32 TCG operations on i64 variables on a 64-bit > host? If not, we could keep tl for the regular instructions and use > i64 for ppc64/ppc-on-64 and 2x i32 on ppc-on-32. That sounds more > efficient than reverting the ppc_gpr_t optimization and always using > 2x i32 independent of the host bitness. We'll need an inlined helper > for these any way. This optimization has been done with dyngen in mind, we surely don't want to keep it with TCG. I currently have plenty of time, but almost no network (travelling), so I'll work on implementing a solution, and commit the result most probably tomorrow morning. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net