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

[David Brown]

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:
> > address@hidden
> > [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
> > -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 address@hidden
> > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list