Inefficient initialization of bit-packed fields

Bug #1639509 reported by Marc Singer
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
Confirmed
Undecided
Unassigned

Bug Description

Greetings,

We'd like to replace macro field packing with a structure, preferrable a bit field. Yet when we made an implementation the code size grew by 1/2KiB for a small program.

Here's the principle of the macro, though the complete implementation is probably more elaborate.

#define X(a,b,c,d) (((a)<<24)|((b)<<16)((c)<<8)|(d))

The C++ language implementations are in the attachment.

With -Os, we get something pretty verbose for initialization:

   2: 2301 movs r3, #1
   4: f363 0007 bfi r0, r3, #0, #8
   8: 2302 movs r3, #2
   a: f363 200f bfi r0, r3, #8, #8
   e: 2303 movs r3, #3
  10: f363 4017 bfi r0, r3, #16, #8
  14: 2304 movs r3, #4

With -O3, we get a constant word load for the bit fields which seems pretty optimal size-wise. The byte-wise version is a little less compact because it handles truncation after loading the word.

It seems like the output machine code could be improved by selecting the O3 strategy for Os. The byte-wise initialization may deserve some attention as well.

Cheers

Revision history for this message
Marc Singer (eleventen) wrote :
Revision history for this message
Marc Singer (eleventen) wrote :

Checking the selection of the CPU, it seems this might related to the M4. The M0 target generates efficient code for Os. Also, it's not clear why function lookup_bifi with O3 for M4 is longer than the M0 version.

Changed in gcc-arm-embedded:
status: New → Confirmed
Revision history for this message
Morty (morty-rh) wrote :

This is not only bit-field related, but a more general problem that applies to any member < 32 bit. Especially for large classes that have many small 0-initilized members this makes the constructor explode in size.

See:
https://godbolt.org/z/LyqvCe

Revision history for this message
Samuel Kleiser (kleisers) wrote :

Also in more trivial cases, sp is incremented and decremented without reason. Maybe this belongs to the same bug. See https://godbolt.org/z/5bobzhrPf

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.