[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] binutils 2.22 blow up program size with -flto

From: David Brown
Subject: Re: [avr-gcc-list] binutils 2.22 blow up program size with -flto
Date: Mon, 30 Jul 2012 09:23:25 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0


Also note that code size is not the only measure of how good a compiler (or option) is. While it is clearly an important measure (especially on small systems), sometimes speed is more important. Maybe the code has ended up a little bigger but noticeably faster - indicating an issue with priority balance rather than LTO itself? (I haven't tried LTO as yet, this is just a general comment.)

What we really need is not an "optimise for size" switch, but an "optimise for the fastest possible code within the specific limit of X KB". Is that on the things-to-do list? :-)



On 29/07/2012 18:07, Weddington, Eric wrote:
Hi Volker

There are known issues with LTO and AVR, though unknown reasons why.
For now I would suggest that you avoid that feature.

However, please file a bug report at the GCC Bugzilla database. That
way we can keep track of the various LTO issues and eventually try to
get them fixed.

Thanks, Eric Weddington

-----Original Message----- From:
[mailto:avr- address@hidden
On Behalf Of Volker Kuhlmann Sent: Saturday, July 28, 2012 9:44 PM
To: address@hidden Subject: [avr-gcc-list] binutils 2.22
blow up program size with -flto

I am finding that with binutils 2.22 and newer gcc the program size
goes through the roof:

Tested with Seismograph 1.8.3, avr-libc 1.7.1 with progmem const
patch, binutils 2.22 or 2.19.1 (indicated by bin219), avr-gcc flags
(the nolto are missing -flto) -mmcu=atmega328p -Os
-ffunction-sections -fdata-sections -mrelax -flto -g2 -gstabs

text   data  bss    dec   hex filename 21156    752  967  22875
595b output/Seismograph-183-436.elf 21156    752  967  22875  595b

22742   1008  960  24710  6086 output/Seismograph-183-463.elf 20730
750  966  22446  57ae output/Seismograph-183-463-bin219.elf 21088
750  967  22805  5915 output/Seismograph-183-463-nolto.elf 21088
750  967  22805  5915 output/Seismograph-183-463-bin219-nolto.elf

22016    748  960  23724  5cac output/Seismograph-183-471.elf 21144
746  966  22856  5948 output/Seismograph-183-471-bin219.elf 21278
746  967  22991  59cf output/Seismograph-183-471-nolto.elf 21278
746  967  22991  59cf output/Seismograph-183-471-bin219-nolto.elf

What could be the reason for this? gcc was recompiled for each
binutils version.

The other sad thing is that gcc 4.7.1 does not improve code size
over 4.3.6, and matches it only with binutils 2.19.1 and no LTO,
otherwise being significantly worse. That's rather unexpected. Why
could this be?

The combination of binutils 2.22, gcc 4.6.3 and LTO produces a
broken program - never mind that for now. It's also the largest
code size ever.

I'm still trying to get the optimum out of LTO, so far gcc 4.6.3
with binutils 2.19.1 and LTO gets top by far.

Any hints thanksfully received,


-- Volker Kuhlmann                      is list0570 with the domain in header.
http://volker.dnsalias.net/     Please do not CC list postings to me.

_______________________________________________ AVR-GCC-list
mailing list address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]