Hi,
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? :-)
mvh.,
David
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:
avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org
[mailto:avr- gcc-list-bounces+eric.weddington=atmel....@nongnu.org]
On Behalf Of Volker Kuhlmann Sent: Saturday, July 28, 2012 9:44 PM
To: avr-gcc-list@nongnu.org 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
-std=gnu++0x
text data bss dec hex filename 21156 752 967 22875
595b output/Seismograph-183-436.elf 21156 752 967 22875 595b
output/Seismograph-183-436-bin219.elf
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
-- 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 AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
