[Bug tree-optimization/32901] New: [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[Bug tree-optimization/32901] New: [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[j at uriah dot heep dot sax dot de]

When defining a bitfield constant where multiple bitfields have initializing
values, this constant is moved into .data in GCC 4.1.  GCC 3.x could realize
it can be written and assigned as a single integer number.  GCC 4.x only
realizes this situation as long as a single bitfield is initialized.

Verified on i386 and avr targets, so this is apparently completely independent
of the target CPU.


-- 
           Summary: [4.1 regression] bitfield constants with multiple
                    bitfields take up space in .data
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: j at uriah dot heep dot sax dot de


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

[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[j at uriah dot heep dot sax dot de]

------- Comment #1 from j at uriah dot heep dot sax dot de  2007-07-26 08:38 -------
Created an attachment (id=13982)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13982&action=view)
Test file

Test case.  Compile with -Os -S, and optionally -DONLY_ONE_BITFIELD
to see the difference.


-- 


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

[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[j at uriah dot heep dot sax dot de]

------- Comment #2 from j at uriah dot heep dot sax dot de  2007-07-26 08:39 -------
Created an attachment (id=13983)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13983&action=view)
Result on i386 target from GCC 3.4.4


-- 


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

[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[j at uriah dot heep dot sax dot de]

------- Comment #3 from j at uriah dot heep dot sax dot de  2007-07-26 08:40 -------
Created an attachment (id=13984)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13984&action=view)
Result on i386 arch from GCC 4.1.2


-- 


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

[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[j at uriah dot heep dot sax dot de]

------- Comment #4 from j at uriah dot heep dot sax dot de  2007-07-26 08:41 -------
Created an attachment (id=13985)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13985&action=view)
Result on avr target from GCC 4.1.2


-- 


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

[Bug tree-optimization/32901] [4.1 regression] bitfield constants with multiple bitfields take up space in .data

[eweddington at cso dot atmel dot com]

------- Comment #5 from eweddington at cso dot atmel dot com  2007-08-22 17:16 -------
Confirmed on the AVR target for 4.3.0 20070817 snapshot.


-- 

eweddington at cso dot atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.1.2 4.3.0
      Known to work|                            |3.4.4
   Last reconfirmed|0000-00-00 00:00:00         |2007-08-22 17:16:01
               date|                            |


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1 regression] bitfield   |[4.1/4.2/4.3 regression]
                   |constants with multiple     |bitfield constants with
                   |bitfields take up space in  |multiple bitfields take up
                   |.data                       |space in .data
   Target Milestone|---                         |4.1.3


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

-- 

aldyh at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

------- Comment #6 from aldyh at gcc dot gnu dot org  2007-12-04 19:30 -------
Ok, here's the deal.

gimplify_init_constructor promotes the constructor to a static because it is a
const aggregate variable, here:

          /* If a const aggregate variable is being initialized, then it        
             should never be a lose to promote the variable to be static.  */
          if (valid_const_initializer
          ...

This isn't a good idea if we are initializing bitfields from static numbers. 
If I keep the compiler from promoting to static in the above code, the
gimplifier splits the constructor into independent assignments:

  init = {};
  init.a1 = 1;
  init.a2 = 5;

...which later combine munges into the expected constant, thus fixing the
problem reported.

Perhaps we should keep the above code from executing if initializing a
structure containing only bitfields that fit into a HOST_WIDE_INT, something we
can do with one move?  Or is there a better generalization we can code here? 
Any suggestions?


-- 

aldyh at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at google dot com


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2007-12-04 19:58 -------
The problem is that we really don't have any optimization which would before
expand merge all the sets to adjacent bitfield fields into one (or few)
BITFIELD_REFs.  If we are lucky and the RTL passes merge it together,
initializing small structs containing bitfields this way will be a win, but
it might be an pessimization as well.
BTW, shouldn't TER try to merge several consecutive initializations of fields
of one aggregate into a CONSTRUCTOR again, so that RTL expanders can do better
job on it?  This wouldn't be the only bug which could be helped by that.


-- 


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2007-12-04 20:02 -------
E.g. for PR22141 it would help too (for PR32901 only if the constructor
gimplification heuristics is also adjusted).


-- 


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

------- Comment #9 from aldyh at gcc dot gnu dot org  2007-12-04 23:43 -------
TER would never see the consecutive initializations because the code I pointed
out in gimplify_init_constructor() keeps the gimplifier from splitting up the
constructor into consecutive MODIFY_EXPRs.

After gimplification we end up with:

setup_foo ()
{
  static const struct foo init = {.a1=1, .a2=5};
  thefoo = init;
}

So there's nothing to merge back.

What I'm suggesting *is* splitting this up, so subsequent passes can take a
stab at it.  In this case, combine cleans it up.


-- 


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

------- Comment #10 from aldyh at gcc dot gnu dot org  2007-12-04 23:54 -------
(In reply to comment #8)
> E.g. for PR22141 it would help too (for PR32901 only if the constructor
> gimplification heuristics is also adjusted).
> 

Ok, I see what you mean.  We adjust the heuristic as I've suggested, and write
some pass to merge consecutive bitfield stores.  I wonder what pass we can
hijack and add the smarts to, instead of writing a whole new pass...


-- 


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 Regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

------- Comment #11 from aldyh at gcc dot gnu dot org  2007-12-11 19:04 -------
testing a patch


-- 


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

[Bug tree-optimization/32901] [4.1/4.2/4.3 Regression] bitfield constants with multiple bitfields take up space in .data

[aldyh at gcc dot gnu dot org]

------- Comment #12 from aldyh at gcc dot gnu dot org  2007-12-12 11:18 -------
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00525.html


-- 

aldyh at gcc dot gnu dot org changed:

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


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