[Bug c/21690] New: gcc misses trivial optimizations ?
TazForEver at dlfp dot org
gcc-bugzilla@gcc.gnu.org
Sat May 21 00:24:00 GMT 2005
hi, i'm using Debian SID experimental gcc-4.0
gcc-4.0 -v
Using built-in specs.
Target: powerpc-linux
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-mpfr --disable-multilib --disable-werror --enable-checking=release
powerpc-linux
Thread model: posix
gcc version 4.0.1 20050508 (prerelease) (Debian 4.0.0-6)
i'm compiling the following simple code :
BEGIN_CODE
void
foo(void*);
static inline char*
bar(char * const p)
{
foo(p);
return p;
}
unsigned long
baz(char * const p)
{
return (unsigned long)(bar(p+1) - bar(p));
}
END_CODE
it's obvious that baz(...) == 1. But gcc outputs the following (gcc -O3 -S -Wall
foo.c)
BEGIN_CODE
baz:
stwu 1,-32(1)
mflr 0
stw 28,16(1)
addi 28,3,1
stw 29,20(1)
mr 29,3
mr 3,28
stw 0,36(1)
bl foo
mr 3,29
bl foo
lwz 0,36(1)
subf 3,29,28
lwz 28,16(1)
lwz 29,20(1)
mtlr 0
addi 1,1,32
blr
END_CODE
if i remove the call foo(p) in function bar, gcc outputs
BEGIN_CODE
baz:
li 3,1
blr
END_CODE
I would have expect gcc to output the same trivial code in both cases.
Now,
addi 28,3,1
...
mr 29,3
mr 3,28
...
mr 3,29
...
subf 3,29,28
is a complex way to get 1.
Why gcc is not able to optimize this kind of code ?
gcc-2.95, gcc-3.3 and gcc-4.0 output the same result.
Thank you.
--
Summary: gcc misses trivial optimizations ?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: TazForEver at dlfp dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21690
More information about the Gcc-bugs
mailing list