This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)?

David

On Wed, Apr 28, 2010 at 2:44 AM, Bingfeng Mei <bmei@broadcom.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:richard.guenther@gmail.com]
>> Sent: 28 April 2010 10:33
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: LTO question
>>
>> On Tue, Apr 27, 2010 at 6:30 PM, Bingfeng Mei
>> <bmei@broadcom.com> 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
>> >
>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]