[avr-gcc-list] Suspect optimizer missed code in avr-gcc 4.4.3..

[uhmgawa]

I just built a recent toolchain (avr-gcc 4.4.3, binutils
2.20) in hopes of eliminating what appeared to be
a few artifacts apparently escaping optimization even
with -Os relative to a 4.0.2 version.  Referencing the dump
below, use of r25 is superfluous as it is cleared at 0x14c,
ANDed with zero at 0x150, and then participates in an
additionally unneeded word wide test operation at 0x152:

00000142 <foo>:

void foo(void)
   {
       static unsigned char count;

       if (++count & 0x3f)
142:   80 91 01 01     lds     r24, 0x0101
146:   8f 5f           subi    r24, 0xFF       ; 255
148:   80 93 01 01     sts     0x0101, r24
14c:   90 e0           ldi     r25, 0x00       ; 0
14e:   8f 73           andi    r24, 0x3F       ; 63
150:   90 70           andi    r25, 0x00       ; 0
150:   90 70           andi    r25, 0x00       ; 0
152:   00 97           sbiw    r24, 0x00       ; 0
154:   11 f0           breq    .+4             ; 0x15a <foo+0x18>
               PORTC &= ~0x1;
156:   40 98           cbi     0x08, 0 ; 8
158:   08 95           ret
       else
               PORTC |= 0x1;
15a:   40 9a           sbi     0x08, 0 ; 8
15c:   08 95           ret
   }


This is slightly different (although appearing to derive
from the same code generation logic) than I'd seen with a
4.0.2 toolchain where the first two operations above are
followed by an OR of r25 into r24 as a word width test:

0000013c <foo>:

void foo(void)
   {
       static unsigned char count;

       if (++count & 0x3f)
13c:   80 91 00 01     lds     r24, 0x0100
140:   8f 5f           subi    r24, 0xFF       ; 255
142:   80 93 00 01     sts     0x0100, r24
146:   99 27           eor     r25, r25
148:   8f 73           andi    r24, 0x3F       ; 63
14a:   90 70           andi    r25, 0x00       ; 0
14c:   89 2b           or      r24, r25
14e:   11 f0           breq    .+4             ; 0x154 <foo+0x18>
               PORTC &= ~0x1;
150:   40 98           cbi     0x08, 0 ; 8
152:   08 95           ret
       else
               PORTC |= 0x1;
154:   40 9a           sbi     0x08, 0 ; 8
156:   08 95           ret
   }


Both examples above were compiled with:

"-mmcu=atmega48 -nostdlib -Os -funsigned-char"

FWIW -O2 and -O3 give the same results. It seems to be
an artifact of a scalar widening operation during code
generation although can be quietly eliminated post-code
generation given the char width type.

I've seen some similar bug reports but not specifically
related to a bitwise-and operation where more than one
set bit exists in the constant operand.  Note if the
constant '3' is replaced with an 'unsigned char'
variable of the same value, the expected minimal
code sequence results (sans the fetch of the added
variable from memory).

-john

--
address@hidden