This is the mail archive of the
mailing list for the GCC project.
RE: LTO question
I turned on -ffunction-sections and compiled with -Os.
The size gain at -O2 is less though.
> -----Original Message-----
> From: Xinliang David Li [mailto:email@example.com]
> Sent: 29 April 2010 17:17
> To: Bingfeng Mei
> Cc: Richard Guenther; firstname.lastname@example.org
> Subject: Re: LTO question
> Just curious, what is the base line size of your comparison? Did you
> turn on GC (-ffunction-sections -fdata-sections -Wl,--gc-sections)?
> On Wed, Apr 28, 2010 at 2:44 AM, Bingfeng Mei
> <email@example.com> wrote:
> > Thanks, I will check what I can do with collect2. LTO
> > seems to save 6-9% code size for applications I tested
> > and should be very useful for us.
> > Bingfeng
> >> -----Original Message-----
> >> From: Richard Guenther [mailto:firstname.lastname@example.org]
> >> Sent: 28 April 2010 10:33
> >> To: Bingfeng Mei
> >> Cc: email@example.com
> >> Subject: Re: LTO question
> >> On Tue, Apr 27, 2010 at 6:30 PM, Bingfeng Mei
> >> <firstname.lastname@example.org> wrote:
> >> > Hello,
> >> > I have been playing with LTO. I notice that LTO doesn't work when
> >> > object files are achived into static library files and the final
> >> > binary is linked against them, although these object files
> >> are compiled
> >> > with -flto and I can see all the lto related sections in
> .a files.
> >> > Is this what is described in LTO Wiki page?
> >> >
> >> > "As an added feature, LTO will take advantage of the
> plugin feature
> >> > in gold. This allows the compiler to pick up object
> files that may
> >> > have been stored in library archives. "
> >> >
> >> > So do I have to use gold to solve this issue?
> >> Yes. ?Or you fix collect2 to do processing of archives and hand
> >> lto1 the required information (it expects archive components
> >> with LTO bytecode like archive.a@offset with offset being the
> >> offset of the .o file with LTO bytecode inside the archive). ?See
> >> lto/lto-elf.c:lto_obj_file_open for "details".
> >> Richard.
> >> > Many thanks,
> >> > Bingfeng
> >> >