This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
2.95.3 x86 missed optimization
- To: gcc-bugs at gcc dot gnu dot org
- Subject: 2.95.3 x86 missed optimization
- From: bug-gcc at horizon dot com
- Date: 2 Jan 2001 08:43:10 -0000
- Cc: bug-gcc at horizon dot com
I was checking to make sure that GCC could optimize code like
int bar(int x)
{
return (x & 1) && !(x & 2) && (x & 4);
}
into a single AND and compare like I expected, when I noticed
that the code it generated:
bar:
movl 4(%esp),%eax
andl $7,%eax
cmpl $5,%eax
sete %al
andl $255,%eax
ret
Has a redundant final "andl". The one on the second line has taken
care of the job already.
It's probably not that important an optimization in the grand scheme
of things, but it might make an interesting test case for somebody.
gcc version 2.95.3 20001229 (prerelease)
.ident "GCC: (GNU) 2.95.3 20001229 (prerelease)"
From the Debian gcc-2.95 package version 1:2.95.3-2.001231
Compilation with -O -fomit-frame-pointer -S
Oh, while I'm on your case, while I don't know which is better, shouldn't
the code emitted for
int baz(int x)
{
return (x & 1) && (x & 2) && (x & 4);
}
.align 4
.globl baz
.type baz,@function
baz:
movl 4(%esp),%eax
andl $7,%eax
cmpl $7,%eax
sete %al
andl $255,%eax
ret
.Lfe3:
.size baz,.Lfe3-baz
be the same as the code generated for
int foo(int x)
{
return !(~x & 1) && !(~x & 2) && !(~x & 4);
}
.align 4
.globl foo
.type foo,@function
foo:
movl 4(%esp),%eax
notl %eax
testb $7,%al
sete %al
andl $255,%eax
ret
.Lfe4:
.size foo,.Lfe4-foo
All other things being equal, the latter is a smidgen shorter.