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]
Other format: [Raw text]

[Bug optimization/12508] New: weak optimization for some constants < 2^16


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.


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