This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

2.95.3 x86 missed optimization


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]