From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRpDK-0001wu-Ey for qemu-devel@nongnu.org; Tue, 08 May 2012 14:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRpDI-0005XH-CM for qemu-devel@nongnu.org; Tue, 08 May 2012 14:32:46 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alexander Graf In-Reply-To: Date: Tue, 8 May 2012 20:32:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4487E0EF-5383-425C-8C4B-D5C91BA742D8@suse.de> References: <1336347984-3714-1-git-send-email-afaerber@suse.de> <1336347984-3714-4-git-send-email-afaerber@suse.de> <33D5ECBF-46DC-404A-979E-FDF5AEBB7594@suse.de> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.1 3/3] tcg/ppc: Fix CONFIG_TCG_PASS_AREG0 mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Andreas_F=E4rber?= Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 08.05.2012, at 20:20, Alexander Graf wrote: >=20 > On 08.05.2012, at 19:43, Alexander Graf wrote: >=20 >>=20 >> On 08.05.2012, at 19:39, Alexander Graf wrote: >>=20 >>>=20 >>> On 07.05.2012, at 01:46, Andreas F=E4rber wrote: >>>=20 >>>> Adjust the tcg_out_qemu_{ld,st}() slow paths to pass AREG0 in r3. >>>> Automate the register numbering to avoid double-coding the two = modes, >>>> and introduce TCG_TARGET_CALL_ALIGN_I64_ARG() macro to align for = SVR4 >>>> but not for Darwin ABI. >>>>=20 >>>> Based on patch by malc. >>>=20 >>> AREG0-free PPC works for me with this patch on a ppc32 host. >>>=20 >>> Tested-by: Alexander Graf >>=20 >> I take that one back - it breaks once things get more complex. = Debugging ... >=20 > I have no idea how this code could have ever worked. We are getting = unknown register numbers as input variables. Then mr them into our C ABI = parameter registers (r3+). Then we call the C helper to do the = load/store for us. >=20 > Now, what if one of those input parameters is within r3-r7 (which is = the highest register passed into the C ld function)? We'd happily do = something like >=20 > mr r3, r5 > mr r4, r3 > mr r5, ... >=20 > at which point we have long overwritten the actual value of r3! This actually makes me wonder. How do we guarantee that all the volatile = registers at the state of a ld/st are declared as clobbered? [a few minutes later] Aha! Through constraints. Then the below patch (which also fixes the = issue for me) is a lot better of course: diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c index ace5548..5750a2b 100644 --- a/tcg/ppc/tcg-target.c +++ b/tcg/ppc/tcg-target.c @@ -258,6 +258,9 @@ static int target_parse_constraint(TCGArgConstraint = *ct, const char **pct_str) tcg_regset_set32(ct->u.regs, 0, 0xffffffff); tcg_regset_reset_reg(ct->u.regs, TCG_REG_R3); tcg_regset_reset_reg(ct->u.regs, TCG_REG_R4); + tcg_regset_reset_reg(ct->u.regs, TCG_REG_R5); + tcg_regset_reset_reg(ct->u.regs, TCG_REG_R6); + tcg_regset_reset_reg(ct->u.regs, TCG_REG_R7); break; case 'K': /* qemu_st[8..32] constraint */ ct->ct |=3D TCG_CT_REG; @@ -267,6 +270,7 @@ static int target_parse_constraint(TCGArgConstraint = *ct, const char **pct_str) tcg_regset_reset_reg(ct->u.regs, TCG_REG_R5); #if TARGET_LONG_BITS =3D=3D 64 tcg_regset_reset_reg(ct->u.regs, TCG_REG_R6); + tcg_regset_reset_reg(ct->u.regs, TCG_REG_R7); #endif break; case 'M': /* qemu_st64 constraint */