possible regression... where to look at?

possible regression... where to look at?

[Dmitry]

Fellows,

I moved my port from 3.2 to 3.4 and found the following:

for the code given:

uint16_t a;
void f()
{
	if(a & 8) gettt();
}

gcc-3.4-20040310 produces something like:

move a, reg
reg >>= 1
reg >>= 1
reg >>= 1
reg = reg & 1 (this sets bit C if result is not zero)
if C then gettt()
return

Which enlarges result code, etc.
gcc-3.2.X did it the way:

move a,reg
reg = reg & 8
if C then gettt()
return

So, the question is:
Is it general gcc-3.4 regression or I have to define something extra?

Thanks in advance,
Dmitry.

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

[Richard Henderson]

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.


r~

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

[Richard Sandiford]

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

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

[Roger Sayle]

On Sat, 13 Mar 2004, Richard Sandiford wrote:
> 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.

I previously worried about this myself, and even considered adding
a special case to BIT_AND_EXPR in do_jump.  However, I believe the
assumption is that if "(A & C1) op 0" isn't used in an assignment, the
later RTL simplification passes will transform "((A >> C2) & 1) != 0"
back into the unshifted sequence.  This certainly happens on x86.


The solutions include either (1) ensure that the inverse transformation
can always be performed on MIPS (and elsewhere) at the RTL-level, (2)
special case the inverse tranform in do_jump, (3) move this optimization
from fold into expand_expr and do_jump or (4) something else I haven't
though of.

Roger
--

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

[Dmitry]

Richard,
This happens regardless to the rtx_cost value.
So, currently shift costs COSTs_N_INSNS (10) whereas and costs 2 of them.

Even when I undefine all 'cost' stuff from the code it behaves the same.

Cheers,
Dmitry.

On Saturday 13 March 2004 02:30, Richard Henderson wrote:
> 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.
>
>
> r~