This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: possible regression... where to look at?


Richard Henderson <rth@redhat.com> writes:
> On Fri, Mar 12, 2004 at 03:26:06PM +0300, Dmitry wrote:
>> Is it general gcc-3.4 regression or I have to define something extra?
>
> If you have your rtx_cost set up such that shift is more expensive
> than and, then I'd classify it as a bug.

FWIW, I was looking at the same thing for MIPS earlier today.  The
transformation seems to be coming from fold-const.c:fold_single_bit_test(),
specifically the bit beginning:

      /* Otherwise we have (A & C) != 0 where C is a single bit, 
	 convert that into ((A >> C2) & 1).  Where C2 = log2(C).
	 Similarly for (A & C) == 0.  */

This happens unconditionally, regardless of rtx_costs etc.  Obviously
it's a win on some architectures if the result of the != or == is used as
a strictly 0/1 value.  Unfortunately, it seems to get applied in other
contexts too.

Like in the OP's example, MIPS gcc 3.4 expands:

        void f (unsigned int x)
        {
          if (x & 8) g ();
        }

as:

        sra     $4,$4,3
        andi    $4,$4,0x1
        bne     $4,$0,$L4
        ...

whereas 3.3 and earlier just had the expected 'andi $4,$4,0x8'.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]