From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37423 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhlXq-00024u-Fz for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:15:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhlX1-0000vz-SC for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:14:12 -0500 Received: from b.mail.sonic.net ([64.142.19.5]:41724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhlX1-0000vb-L2 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 11:14:11 -0500 Message-ID: <4D3EF6C1.3080502@twiddle.net> Date: Tue, 25 Jan 2011 08:13:53 -0800 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/7] tcg-i386: Implement deposit operation. References: <1294716228-9299-1-git-send-email-rth@twiddle.net> <1294716228-9299-6-git-send-email-rth@twiddle.net> <20110125122749.GA19736@edde.se.axis.com> In-Reply-To: <20110125122749.GA19736@edde.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: qemu-devel@nongnu.org, aurelien@aurel32.net, agraf@suse.de On 01/25/2011 04:27 AM, Edgar E. Iglesias wrote: > I've tested this patch a bit and got mixed results. I tested with patched > CRIS and MicroBlaze translators. The patch works OK (it doesn't break > anything) for the usecases I had but I saw a bit of a slowdown with > MicroBlaze (compare to not using deposit at all). > > I suspect that the fast 8 and 16 bit x86 deposits are giving me a slight > speedup with CRIS. But MicroBlaze uses one bit fields into bit 2 and > 31. Those seem to be slower with deposit than with other tcg sequences. > > I would have guessed that at worst, this patch would be equally fast > as any TCG sequence. Am I missing something? With or without the i386 tcg-target.c changes? If without, then I'm stumped, since it looks like identical tcg ops being emitted. It with, then perhaps SHLD is slower than I thought. I see that GCC lists this insn as "vector decoded" for AMD cores, as opposed to "direct decoded". If this insn is indeed microcoded on some hosts then maybe the i386 tcg-target patch isn't such a great idea. That said, there are still other tcg targets which support this operation directly. I would be shocked if you measured a slowdown with these changes on a ppc host, for instance. r~