From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NM21m-0006v0-Sk for qemu-devel@nongnu.org; Sat, 19 Dec 2009 11:19:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NM21m-0006tX-1i for qemu-devel@nongnu.org; Sat, 19 Dec 2009 11:19:34 -0500 Received: from [199.232.76.173] (port=44714 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NM21l-0006tP-Ux for qemu-devel@nongnu.org; Sat, 19 Dec 2009 11:19:33 -0500 Received: from are.twiddle.net ([75.149.56.221]:34016) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NM21l-00025h-Kw for qemu-devel@nongnu.org; Sat, 19 Dec 2009 11:19:33 -0500 Message-ID: <4B2CFD14.3000206@twiddle.net> Date: Sat, 19 Dec 2009 08:19:32 -0800 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] tcg conditional set/move, round 3 References: <761ea48b0912170620l534dcb02m8ea6b59524d76dbe@mail.gmail.com> <761ea48b0912180337k627350b7ma7ab54cd248815eb@mail.gmail.com> <4B2BF650.80902@twiddle.net> <20091219130346.GN24729@hall.aurel32.net> In-Reply-To: <20091219130346.GN24729@hall.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Laurent Desnogues , qemu-devel@nongnu.org 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. > - Do we really want to make movcond mandatory? It can be easily > implemented using setcond, and, or instructions. I think so. In that every host does have something useful to emit that's better than the generic fallback, and we'll quickly have implementations for each. > - I am not sure using xor and followed by setcc *conditionally* instead > of a movzb after setcc is a good idea. The two instructions are > supposed to be executed at the same speed, and time spent in code > generation is not negligeable. I can certainly remove that bit if you insist. > - Pay attention to the coding style, there are a few cases of if > without {}. Ok. I try to remember, but it's at odds with my usual style, so please understand momentary lapses. > A final comment, would it be possible to split setcond and movcond in > different patches? setcond looks ready to go, there are probably some > more concerns/comments about movcond. Ok. r~