[Bug other/17104] New: Non-optimal code generation for bitfield initialization

[Bug other/17104] New: Non-optimal code generation for bitfield initialization

[gcc-bugzilla at gcc dot gnu dot org]

Description:
A non-optimal code sequence is illustrated.    Duplicate using gcc 3.5 and
command line:

gcc -O3 -m32/-m64 -c test.c


Testcase:
struct {
 int f1 : 1;
 int f2 : 1;
 int f3 : 1;
 int f4 : 1;
 int f5 : 1;
 int f6 : 1;
 int f7 : 1;
 int f8 : 1;
 int f9 : 1;
 int f10 : 1;
 int f11 : 1;
 int f12 : 1;
 int f13 : 1;
 int f14 : 1;
 int f15 : 1;
 int f16 : 1;
 int f17 : 2;
 int f18 : 2;
 int f19 : 2;
 int f20 : 2;
 int f21 : 2;
 int f22 : 2;
 int f23 : 2;
 int f24 : 2;
 } s;

void foo ()
{

    s.f1 = 0;
    s.f2 = 0;
    s.f3 = 0;
    s.f4 = 0;
    s.f5 = 0;
    s.f6 = 0;
    s.f7 = 0;
    s.f8 = 0;
    s.f9 = 0;
    s.f10 = 0;
    s.f11 = 0;
    s.f12 = 0;
    s.f13 = 0;
    s.f14 = 0;
    s.f15 = 0;
    s.f16 = 0;
    s.f17 = 0;
    s.f18 = 0;
    s.f19 = 0;
    s.f20 = 0;
    s.f21 = 0;
    s.f22 = 0;
    s.f23 = 0;
    s.f24 = 0;

}

Assembly:
GCC 3.5 currently generates the following using:
 -m32 -O3

 foo:
      lis 9,s@ha
      li 11,0
      lwz 0,s@l(9)
      rlwinm 0,0,0,30,31
      rlwimi 0,11,0,30,31
      stw 0,s@l(9)
      blr

which could be simplified to:

 foo:
      lis 9,s@ha
      li 11,0
      stw 11,s@l(9)
      blr

the real problem, however, lies in the code generated
for 64 bit:
      -m64 -O3

 .foo:
      ld 11,.LC0@toc(2)
      lwz 0,0(11)
      rlwinm 0,0,0,1,31
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,1,1,31
      rlwinm 9,9,31,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,2,1,31
      rlwinm 0,0,30,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,3,1,31
      rlwinm 9,9,29,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,4,1,31
      rlwinm 0,0,28,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,5,1,31
      rlwinm 9,9,27,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,6,1,31
      rlwinm 0,0,26,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,7,1,31
      rlwinm 9,9,25,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,8,1,31
      rlwinm 0,0,24,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,9,1,31
      rlwinm 9,9,23,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,10,1,31
      rlwinm 0,0,22,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,11,1,31
      rlwinm 9,9,21,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,12,1,31
      rlwinm 0,0,20,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,13,1,31
      rlwinm 9,9,19,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,14,1,31
      rlwinm 0,0,18,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,15,1,31
      rlwinm 9,9,17,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,16,2,31
      rlwinm 0,0,16,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,18,2,31
      rlwinm 9,9,14,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,20,2,31
      rlwinm 0,0,12,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,22,2,31
      rlwinm 9,9,10,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,24,2,31
      rlwinm 0,0,8,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,26,2,31
      rlwinm 9,9,6,0xffffffff
      stw 9,0(11)
      lwz 0,0(11)
      rlwinm 0,0,28,2,31
      rlwinm 0,0,4,0xffffffff
      stw 0,0(11)
      lwz 9,0(11)
      rlwinm 9,9,0,0,29
      stw 9,0(11)
      blr



-- 
           Summary: Non-optimal code generation for bitfield initialization
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P1
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: steinmtz at us dot ibm dot com
                CC: gcc-bugs at gcc dot gnu dot org,steinmtz at us dot ibm
                    dot com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-19 15:31 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|other                       |rtl-optimization
     Ever Confirmed|                            |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-19 15:31:19
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2004-09-13 17:37 -------
Is the compiler really free to do much better?  XLC seems to produce slightly
more efficient, but generally similarly large amount of code for the assignment.
 The problem is that struct is an int -- 32 bits -- not an entire GPR in 64-bit
mode.  One ends up with a partial register -- only part of the register defined.
 If the struct is defined as a bitfield of "long int", the 64-bit code is
compact and essentially equivalent to the 32-bit version.  This may not be a
missed optimization.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-09-19 23:02 -------
There is certainly a better code sequence: a single assignment that writes "0"
into the memory occupied by "s".  The question is: how hard it is for the
compiler to recognize that opportunity?

I'm presently looking into that issue.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-09-20 01:56 -------
In 32-bit mode the initial RTL looks like:

  (set:SI (reg:SI 124) (mem:SI (reg:SI 122)))
  ...
  (set:SI (mem:SI (reg:SI 122)) (reg:SI 125))

CSE recognizes that at this point the MEM and REG 125 contain the same value,
and therefore replaces the next read of the MEM with REG 125.

In 64-bit mode, the RTL looks like:

  (set:DI (reg:DI 125) (zero_extend:DI (mem:SI (reg:DI 123))))
  ...
  (set:SI (mem:SI (reg:SI 123)) (reg:SI 127))

The zero-extends applied to the load prevent CSE from recognizing that the MEM
written and the MEM read are the same.

There are several possible approaches to consider: 

  (a) Modify the PowerPC machine description to emit an SImode load,
      instead of the zero-extend sequence.  (The hardware instruction
      actually *is* zero-extending, which is presumably why the
      machine description generates the zero-extension.)

  (b) Modify the PowerPC machine description to emit the
      zero-extension as a separate instruction.  (And hope that the
      compiler will combine them into one instruction later if
      possible.)

  (c) Modify CSE to recognize the zero_extend idiom and replace the
      operand to the zero_extend.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-20 01:59 -------
(set (match_operand:SI 0 "gpc_reg_operand" "=r,r")
        (zero_extend:SI (match_operand:HI 1 "reg_or_mem_operand" "m,r")))

Really this should be done in CSE and not a target specific way because it can effect other targets.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[nathan at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2004-11-02 09:48 -------
2004-11-02  Nathan Sidwell  <nathan@codesourcery.com>

	PR rtl-optimization/17104
	* config/rs6000/rs6000.c (rs6000_emit_move): Don't wrap small
	loads in zero_extend.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-02 09:50 -------
Subject: Bug 17104

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	nathan@gcc.gnu.org	2004-11-02 09:50:35

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: rs6000.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg: ppc-bitfield1.c 

Log message:
	.:
	PR rtl-optimization/17104
	* config/rs6000/rs6000.c (rs6000_emit_move): Don't wrap small
	loads in zero_extend.
	testsuite:
	PR rtl-optimization/17104
	* gcc.dg/ppc-bitfield1.c: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6130&r2=2.6131
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.733&r2=1.734
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4533&r2=1.4534
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ppc-bitfield1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104

[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization

[roger at eyesopen dot com]

------- Comment #9 from roger at eyesopen dot com  2006-04-30 19:52 -------
*** Bug 13335 has been marked as a duplicate of this bug. ***


-- 

roger at eyesopen dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104