public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "uhmgawa at third-harmonic dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/43088]  New: [avr] Suspect optimizer missed code in gcc 4.4.3..
Date: Tue, 16 Feb 2010 06:03:00 -0000	[thread overview]
Message-ID: <bug-43088-18792@http.gcc.gnu.org/bugzilla/> (raw)

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).

-----------------------------------------------------------
Per requested bug report boilerplate:

/home/john/avr/gnu/toolbin//bin/avr-gcc -v -save-temps -c -o rt1.o -c
-mmcu=atmega48 -nostdlib -Os -funsigned-char -D__BUILD_GAS__
-DDATE=\"100215200656\" -g rt1.c
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/home/john/avr/gnu/toolbin --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.4.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE="100215200656"'
'-g'
 /home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/cc1 -E -quiet -v -imultilib
avr4 -D__BUILD_GAS__ -DDATE="100215200656" rt1.c -mmcu=atmega48 -funsigned-char
-g -fworking-directory -Os -fpch-preprocess -o rt1.i
ignoring nonexistent directory
"/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/include
 /home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/include-fixed
 /home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE="100215200656"'
'-g'
 /home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/cc1 -fpreprocessed rt1.i
-quiet -dumpbase rt1.c -mmcu=atmega48 -auxbase-strip rt1.o -g -Os -version
-funsigned-char -o rt1.s
GNU C (GCC) version 4.4.3 (avr)
        compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2cb821fe223eaff7cfe636a2c880b1cc
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE="100215200656"'
'-g'
 /home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/bin/as
-mmcu=atmega48 -o rt1.o rt1.s
COMPILER_PATH=/home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/:/home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/:/home/john/avr/gnu/toolbin/libexec/gcc/avr/:/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/:/home/john/avr/gnu/toolbin/lib/gcc/avr/:/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/bin/
LIBRARY_PATH=/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/avr4/:/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/lib/avr4/:/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/:/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE="100215200656"'
'-g'


-- 
           Summary: [avr] Suspect optimizer missed code in gcc 4.4.3..
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: uhmgawa at third-harmonic dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088


             reply	other threads:[~2010-02-16  6:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16  6:03 uhmgawa at third-harmonic dot com [this message]
2010-09-13  5:58 ` [Bug target/43088] " abnikant dot singh at atmel dot com
2010-09-20  2:30 ` eric dot weddington at atmel dot com
2010-09-20  4:24 ` abnikant dot singh at atmel dot com
2010-09-20 12:59 ` eric dot weddington at atmel dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-43088-18792@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).