From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLgJs-0003m7-BA for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:22:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLgJq-0001ZA-Tk for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:22:24 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:48073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLgJq-0001Z6-Mm for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:22:22 -0400 Received: by mail-pa0-f45.google.com with SMTP id fb10so5597646pad.4 for ; Tue, 09 Oct 2012 13:22:22 -0700 (PDT) Sender: Richard Henderson Message-ID: <5074877C.2030002@twiddle.net> Date: Tue, 09 Oct 2012 13:22:20 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1349526621-13939-1-git-send-email-pbonzini@redhat.com> <1349526621-13939-15-git-send-email-pbonzini@redhat.com> In-Reply-To: <1349526621-13939-15-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/14] i386: optimize setcc instructions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 10/06/2012 05:30 AM, Paolo Bonzini wrote: > +static inline void gen_setcc1(DisasContext *s, int b, TCGv reg) > { > + int inv, jcc_op, size, cond; > + TCGv t0; > + > + inv = b & 1; > jcc_op = (b >> 1) & 7; > + > switch(s->cc_op) { > + /* we optimize relational operators for the cmp/jcc case */ > case CC_OP_SUBB: > case CC_OP_SUBW: > case CC_OP_SUBL: > case CC_OP_SUBQ: > + size = s->cc_op - CC_OP_SUBB; > + switch(jcc_op) { > + case JCC_BE: > + cond = inv ? TCG_COND_GTU : TCG_COND_LEU; > + tcg_gen_add_tl(cpu_tmp4, cpu_cc_dst, cpu_cc_src); > + gen_extu(size, cpu_tmp4); > + t0 = gen_ext_tl(cpu_tmp0, cpu_cc_src, size, false); > + tcg_gen_setcond_tl(cond, reg, cpu_tmp4, t0); > + break; I don't think this patch is going in the right direction. In particular, this is going to be largely redundant with gen_jcc1. Instead, c.f. the DisasCompare structure now present in target-sparc/, or a similar DisasCompare structure present in my jumbo target-s390x patch set. Here we use common code to generate a comparison, which can then be fed into brcond, setcond, or movcond as desired. I think that this Compare structure should be fed to gen_compute_eflags_* so that a parent gen_condition routine can make use of them for simple conditions like z/nz. At which point gen_jcc1 and gen_setcc1 become fairly trivial routines. r~