From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NM6of-0000Lz-T6 for qemu-devel@nongnu.org; Sat, 19 Dec 2009 16:26:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NM6oa-0000Im-4i for qemu-devel@nongnu.org; Sat, 19 Dec 2009 16:26:21 -0500 Received: from [199.232.76.173] (port=54391 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NM6oa-0000Ih-16 for qemu-devel@nongnu.org; Sat, 19 Dec 2009 16:26:16 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:53442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NM6oZ-00011w-PL for qemu-devel@nongnu.org; Sat, 19 Dec 2009 16:26:15 -0500 Received: by ywh1 with SMTP id 1so3901309ywh.18 for ; Sat, 19 Dec 2009 13:26:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4B2D11C8.6040507@twiddle.net> References: <4259c837ce1a62fcb495e57f18b588eb7365d286.1261012798.git.rth@twiddle.net> <4B2D11C8.6040507@twiddle.net> From: Blue Swirl Date: Sat, 19 Dec 2009 21:25:54 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 5/7] tcg-sparc: Implement setcond, movcond, setcond2, brcond2. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On Sat, Dec 19, 2009 at 5:47 PM, Richard Henderson wrote: > On 12/19/2009 02:31 AM, Blue Swirl wrote: >>> >>> =C2=A0static inline void tcg_out_movi_imm32(TCGContext *s, int ret, uin= t32_t >>> arg) >>> =C2=A0{ >>> - =C2=A0 =C2=A0if (check_fit_tl(arg, 12)) >>> + =C2=A0 =C2=A0if (check_fit_tl(arg, 13)) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcg_out_movi_imm13(s, ret, arg); >> >> IIRC sign extension prevents this. > > Pardon? =C2=A0check_fit_tl checks a signed value, the OR opcode provides = one. > =C2=A0Where's the conflict? Long time ago I tried the same change, but the generated code was not correct. But now it seems to work. >>> - =C2=A0 =C2=A0if (const_arg2&& =C2=A0arg2 =3D=3D 0) >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0/* orcc %g0, r, %g0 */ >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0tcg_out_arith(s, TCG_REG_G0, TCG_REG_G0, a= rg1, ARITH_ORCC); >>> - =C2=A0 =C2=A0else >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0/* subcc r1, r2, %g0 */ >>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0tcg_out_arith(s, TCG_REG_G0, arg1, arg2, A= RITH_SUBCC); >>> - =C2=A0 =C2=A0tcg_out_branch_i32(s, tcg_cond_to_bcond[cond], label_ind= ex); >>> + =C2=A0 =C2=A0tcg_out_cmp(s, arg1, arg2, const_arg2); >> >> What's wrong with 'orcc' (produces the synthetic instruction 'tst')? > > What result does "orcc" give that isn't produced by "subcc"? =C2=A0Unlike= i386 > where "test x,x" is one byte smaller than "cmp $0,x", it seems to me ther= e's > no reason to distingish the arg2 =3D=3D constant zero case on sparc. Maybe it's faster on real CPUs. On my machine I don't see any difference. I timed the following program: #include #include #define N 100000000 int main(int argc, char **argv) { unsigned int i; if (atoi(argv[1])) { for (i =3D 0; i < N; i++) { asm volatile ("cmp %g1, 0"); } } else { for (i =3D 0; i < N; i++) { asm volatile ("tst %g1"); } } return 0; }