GNU Arm Embedded Toolchain

Does libgcc have different versions built for size and speed?

Asked by john

I just noticed that a small program grew from ~3200 bytes to ~3600 bytes when transitioning from gcc-4.8 to gcc-4.9. It turns out that practically all the extra code came from libgcc. It was __divsi3. Apparently, this routine is coded in C and gcc-4.9 decided to unroll a loop. Hence the dramatic increase in code size.
An extra 400 bytes for integer division routine doesn't sound right. The program in question was being built with -Os. Apparently, -Os does not have any influence on libgcc, or does it?

CFLAGS=-mthumb -mcpu=cortex-m0 -fno-strict-aliasing -Os -flto
LDFLAGS=-T stm32f051.ld -Wl,--gc-sections -fwhole-program -static --specs=nano.specs -lc -lm -lnosys

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Thomas Preud'homme
Solved:
Last query:
Last reply:
Revision history for this message
Best Thomas Preud'homme (thomas-preudhomme) said : 		#1

Hi John,

Indeed, at the moment the libgcc used is the same without regards for the optimization level. Only the architecture (ARMv7-M, ARMv7e-M, etc.) influences the libgcc chosen.

Best regards.

Revision history for this message
john (jkovach) said : 		#2

Hi Thomas,

Thank you for the quick reply.
Should I report this as a bug? The increase in size appears to be rather dramatic: _udivsi3.o went from 156 bytes to 288 bytes, _divsi3.o went from 192 bytes to 480 bytes.

Regards.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#3

It is up to you really. I will create an internal ticket for us to look into it whenever we have time so a Launchpad bug does not need to be created. It is more of a convenience for you to see the evolution of the status of the bug. We also try to provide updates on this forum though.

Best regards.

Revision history for this message
john (jkovach) said : 		#4

Thanks Thomas Preud'homme, that solved my question.

Revision history for this message
john (jkovach) said : 		#5

By the way, if libgcc was built with -flto, the problem would not exist. Appropriate optimizations (for speed or size) would be applied automatically at link time.