From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMorP-00038s-HV for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:28:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMorN-000370-Mh for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:28:06 -0500 Received: from [199.232.76.173] (port=52513 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMorN-00036h-6W for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:28:05 -0500 Received: from are.twiddle.net ([75.149.56.221]:35940) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMorM-0004FI-Ku for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:28:04 -0500 Message-ID: <4B2FDA53.6040605@twiddle.net> Date: Mon, 21 Dec 2009 12:28:03 -0800 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4 References: <200912202257.22503.paul@codesourcery.com> <4B2ED6D0.1010900@twiddle.net> <761ea48b0912210113p42608776q7677f79eec83f5a6@mail.gmail.com> In-Reply-To: <761ea48b0912210113p42608776q7677f79eec83f5a6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: Paul Brook , aurelien@aurel32.net, qemu-devel@nongnu.org On 12/21/2009 01:13 AM, Laurent Desnogues wrote: > The question for the generalized movcond is how useful is it? > Which front-ends would need it and would the cost to generate > code for it on some (most?) back-ends be amortized? ... Any front end that has a conditional move instruction? Sparcv9, Mips32, Alpha, ARM... That said, I think the *biggest* gains are to be had because with movcond -- at least on some targets -- we can have one BB per TB, and avoid any intermediate spilling of global registers back to memory. > My guess (I use that word given that I didn't do any benchmark > to sustain my claim) is that your implementation is too complex. Too complex for what? The message against which you are quoting has an implementation of 2 lines. > Of course setcond can be implemented in terms of movcond, > but my guess (again that word...) is that setcond could be > enough and even faster in most cases. To implement condition codes, yes, to implement compare instructions (e.g. mips slt, alpha cmp{eq,lt,lte}), yes. To implement conditional moves, no. At least not without using 5 instructions where 1 would suffice. > Regarding your patches, I would like to see setcond put in > mainline with a simplified version for i386. Again, simplified from what? The last setcond implementation was 2 lines. r~