Re: Question about RTL for bitwise AND

["Matt Lee" <reachmatt.lee@xxxxxxxxx>]

Hi Ian,

Thanks for the help. I did suspect the costs and reviewd them,

Here is what I have,

    case AND:
    case IOR:
    case XOR:
        *total = COSTS_N_INSNS (1);
        return true;
    case ASHIFT:
    case ASHIFTRT:
    case LSHIFTRT:
         if (GET_CODE (XEXP (x, 1)) == CONST_INT)
             *total = COSTS_N_INSNS (INTVAL (XEXP (x, 1)));
         return true;


This looks quite OK to me. I tried debugging if rtx_costs was doing
something wrong. I do see rtx_cost being invoked for the lshiftrt
expressions in question, but never for the "and". Seems like GCC had
pre-decided to only use lshiftrt even though it is expensive.

Any other ideas? Btw, I couldn't find prefer_and_bit_test in dojump.c.

thanks,
Matt



On 13 Apr 2006 13:29:16 -0700, Ian Lance Taylor <ian@xxxxxxxx> wrote:
> "Matt Lee" <reachmatt.lee@xxxxxxxxx> writes:
>
> >  I am using powerpc-eabi-gcc (version 3.4.1) and I have a question
> > about the RTL that is produced for,
> >
> >  test.c
> >  int a;
> >
> >  if (a & 2) {
> >   // Do something
> >  } else
> >   // Do something else
> >  }
> >
> >
> >  I see in test.c.01.rtl,
> >
> >  (insn 12 11 13 (set (reg:SI 122)
> >          (lshiftrt:SI (reg:SI 121)
> >              (const_int 1 [0x1]))) -1 (nil)
> >      (nil))
> >
> >  (insn 13 12 14 (parallel [
> >              (set (reg:SI 123)
> >                  (and:SI (reg:SI 122)
> >                      (const_int 1 [0x1])))
> >              (clobber (scratch:CC))
> >          ]) -1 (nil)
> >      (nil))
> >
> >
> >  My question is, why is a logical shift right required? Wouldn't a
> > direct bit-wise AND with const_int 2 suffice?
>
> In general this kind of decision is made based on target specific
> costs.  See prefer_and_bit_test in dojump.c.
>
> For the PowerPC, you should look at later optimization passes.  It
> seems possible that the two instructions above will get combined into
> a single rlwinm instruction.  Although I haven't tried it.
>
> >  This is causing problems in my (other) port where I can do only
> > single-bit shifts. In the worst case, a & 0x80000000 the final
> > assembly contains 31 right shifts. This is a big optimization problem.
>
> Fix your costs to indicate this.
>
> Ian
>