This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: possible regression... where to look at?
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Dmitry <diwil at spec dot ru>, gcc at gcc dot gnu dot org
- Date: Sat, 13 Mar 2004 21:26:05 +0000
- Subject: Re: possible regression... where to look at?
- References: <200403121526.06765.diwil@spec.ru><20040312233035.GA27743@redhat.com>
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