From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NM8Jw-0004ix-PY for qemu-devel@nongnu.org; Sat, 19 Dec 2009 18:02:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NM8Jt-0004hi-PO for qemu-devel@nongnu.org; Sat, 19 Dec 2009 18:02:42 -0500 Received: from [199.232.76.173] (port=59339 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NM8Jt-0004hW-Mc for qemu-devel@nongnu.org; Sat, 19 Dec 2009 18:02:41 -0500 Received: from hall.aurel32.net ([88.191.82.174]:45352) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NM8Jt-0001GS-7e for qemu-devel@nongnu.org; Sat, 19 Dec 2009 18:02:41 -0500 Date: Sun, 20 Dec 2009 00:02:33 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] tcg conditional set/move, round 3 Message-ID: <20091219230233.GA1348@volta.aurel32.net> References: <761ea48b0912170620l534dcb02m8ea6b59524d76dbe@mail.gmail.com> <761ea48b0912180337k627350b7ma7ab54cd248815eb@mail.gmail.com> <4B2BF650.80902@twiddle.net> <20091219130346.GN24729@hall.aurel32.net> <4B2CFD14.3000206@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4B2CFD14.3000206@twiddle.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Laurent Desnogues , qemu-devel@nongnu.org On Sat, Dec 19, 2009 at 08:19:32AM -0800, Richard Henderson wrote: > On 12/19/2009 05:03 AM, Aurelien Jarno wrote: > >- For the movcond instruction, is there a real use for vtrue and vfalse > > values? Most CPU actually implement a version with one value. > > Implementing it with two values moves complexity within the arch > > specific tcg code. > > The reason I added both is that rather than force TCG to insert > extra moves in order to always match VFALSE with DEST, I could have > the backend invert the condition if VTRUE happened to match DEST > already. > > I suppose it would be possible to tweek the TCG register allocator > to understand such commutative operations. That seemed harder, but > perhaps it really isn't considering that inversion code has to be > replicated across all the targets. It's certainly something to > think about. > My main concerns here is that we are introducing a complex code here that has to be multiplied by the number of TCG targets we have. On the other hand I am not sure there are a lot of use cases for the different architectures we support. In addition I am reserved to make such bug changes given I am not sure it will result in a speed gain. All the previous setcond implementations have been stopped because there was no measurable gain. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net