From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxM1w-0002Jw-RX for qemu-devel@nongnu.org; Tue, 04 Nov 2008 08:33:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxM1v-0002JG-8a for qemu-devel@nongnu.org; Tue, 04 Nov 2008 08:33:12 -0500 Received: from [199.232.76.173] (port=56933 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxM1v-0002JB-1o for qemu-devel@nongnu.org; Tue, 04 Nov 2008 08:33:11 -0500 Received: from wf-out-1314.google.com ([209.85.200.170]:54859) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxM1u-0007qc-JI for qemu-devel@nongnu.org; Tue, 04 Nov 2008 08:33:10 -0500 Received: by wf-out-1314.google.com with SMTP id 27so3200350wfd.4 for ; Tue, 04 Nov 2008 05:33:08 -0800 (PST) Message-ID: <761ea48b0811040533o487c689ek8e8f776590717086@mail.gmail.com> Date: Tue, 4 Nov 2008 14:33:08 +0100 From: "Laurent Desnogues" Subject: Re: [Qemu-devel] [RFC] TCG new op: setcond In-Reply-To: <200811041316.39122.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <761ea48b0811040215l3fa16cd6j41e7ee750602e6ea@mail.gmail.com> <200811041316.39122.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Tue, Nov 4, 2008 at 2:16 PM, Paul Brook wrote: >> this patch implements a new TCG op, setcond, that sets a temp >> to 1 if the condition is true, else to 0. The benefit is the potential >> removal of brcond instructions, and helpers size reduction which >> can lead to using TCG instead of helpers. > >> - a variant that sets -1 instead of 1 for masking > > I'm worried about this. If we're not careful we'll end up with an explosion of > different patterns, many of which aren't optimal of different hosts. I am worried too. I added that because you mentioned you would prefer -1 over 1. I am still unsure which one of these variants is the most useful and/or host runtime critical (one can be derived from the other by generating one extra TCG op). >> - 64 bit setcond's > > You should do this sooner rather than later, and on a 32-bit host. OK. >> + /* clear ret since setcc only sets the lower 8 bits */ >> + tcg_out_modrm(s, 0x01 | (ARITH_XOR << 3) | rexw, ret, ret); > > This is broken. Inputs and outputs may overlap. Oh right. I will use some bit extending instruction. >> + // TODO this should use tcg_out_modrm >> + // however currently tcg_out_modrm outputs an extra byte for >> [abcd]l + //tcg_out_modrm(s, (0x90 + tcg_cond_to_jcc[cond]) | P_EXT | >> P_REXB, ret, 0) > > This is the wrong way to fix this. If you really care about the extra code > byte (which is harmless) you should fix tcg_out_modrm. I asked about that directly to Fabrice yesterday. I am waiting for his answer. I certainly am not very good at x86 and its baroque encoding :) > Also, please use C comments, not c++ style //. These were done so that it is explicit they are here temporarily for reviewers. They will disappear in the final patch. Thanks for the comments. Laurent