qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 14/14] i386: optimize setcc instructions


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 14/14] i386: optimize setcc instructions
Date: Wed, 10 Oct 2012 08:51:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

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~
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]