This is the mail archive of the 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]

Re: [optimization missed] Why do x86 gcc need extension here?

On 09/28/2015 09:09 AM, Konstantin Vladimirov wrote:
Simple test:

struct U {
   unsigned s: 1;

struct V {
   unsigned short o: 7;
   unsigned short u: 1;

extern struct U t[];
extern struct V d[];

foo ()
     struct V descr = d[0];
     unsigned osize = descr.o;
     if ( descr.u )
         struct U udata = t[osize];
         if (udata.s) osize++;
     return osize;

Compiled with specified gcc:

gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure
--prefix=/tools/local/gcc-5.2.0 --program-suffix=-5.2.0
Thread model: posix
gcc version 5.2.0 (GCC)


with options:  -02 -S


Yields assembler:


         movzbl  d(%rip), %eax
         andl    $127, %eax
         cmpb    $0, d(%rip)
         movzbl  %al, %eax // <----- why this is here?
         jns     .L2
         movl    %eax, %edx
         movl    t(,%rdx,4), %edx
         andl    $1, %edx
         cmpb    $1, %dl
         sbbl    $-1, %eax
         rep ret

I can not understand why second movzbl is here? andl already bitwise
and register eax with 127, why do someone need to zero-extend it one
more time?

May be some optimization missed here and it makes sense to file a
ticket in bugzilla? Or maybe I do not understand something?

Problem go away if I change unsigned short to unsigned int in bitfield
type inside structure V.
Please file a bug report. The x86 backend is trying to avoid redundant prefixes via a splitter which is creating the redundant extension fairly late in the optimizer pipeline. Redundant extension removal doesn't remove it.


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