From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLq99-0002er-2U for qemu-devel@nongnu.org; Wed, 10 Oct 2012 02:51:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLq98-0003Ue-0b for qemu-devel@nongnu.org; Wed, 10 Oct 2012 02:51:59 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:37776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLq97-0003U8-Qj for qemu-devel@nongnu.org; Wed, 10 Oct 2012 02:51:57 -0400 Received: by mail-wg0-f53.google.com with SMTP id dr1so127755wgb.10 for ; Tue, 09 Oct 2012 23:51:56 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <50751B0A.4090406@redhat.com> Date: Wed, 10 Oct 2012 08:51:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1349526621-13939-1-git-send-email-pbonzini@redhat.com> <1349526621-13939-15-git-send-email-pbonzini@redhat.com> <5074877C.2030002@twiddle.net> In-Reply-To: <5074877C.2030002@twiddle.net> 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: Richard Henderson Cc: qemu-devel@nongnu.org Il 09/10/2012 22:22, Richard Henderson ha scritto: > 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. Yes, it is. That's something I had started after posting this series, but didn't finish in time for the weekend... :) You can look at a few more changes in the eflags2 branch of my github repo, including: - delaying the actual generation of conditions, so that they can be used in setcond/brcond/movcond - optimization of setle/setl similar to setbe (shift OF onto SF, XOR, mask to SF or SF+ZF, after which you can already do a brcond) There are also TCG changes that add zero-bit tracking to optimize.c to eliminate redundant ext (leading to both better code generation and better copy propagation). Paolo > 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~ > >