This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/12508] New: weak optimization for some constants < 2^16
- From: "gpiez at users dot sourceforge dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 4 Oct 2003 18:20:23 -0000
- Subject: [Bug optimization/12508] New: weak optimization for some constants < 2^16
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12508
Summary: weak optimization for some constants < 2^16
Product: gcc
Version: 3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gpiez at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
the function
int f(int x) {
if (x & 0x1fff0)
return 1;
else
return 0;
}
compiled with '-O2 -fomit-framepointer' for a x86, yields
xor %eax,%eax
testl $0x1fff0,0x4(%esp,1)
setne %al
ret
This is ok (at least for me). But if I change the constant 0x1fff0 to 0xfff0,
f() now looks like
mov 0x4(%esp,1),%eax
and $0xfffffff0,%eax
test %ax,%ax <----- this is very ugly
setne %al
movzbl %al,%eax
ret
I suspect, the compiler wants to use the three bytes saving 'and imm8,%eax'
instruction, but this doesn't make up for the additional 6 bytes it needs
elsewhere. And the partial register read after a register write probably
causes a stall, at least the second version did run 20% slower in a short
test.