LTO question

LTO question

[Bingfeng Mei]

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? 

Many thanks,
Bingfeng 

Re: LTO question

[Ian Lance Taylor]

"Bingfeng Mei" <bmei@broadcom.com> writes:

> 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.

Speaking of which, I'd sure like to see a MIPS port for gold....

Ian

Re: LTO question

[Richard Guenther]

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
>

RE: LTO question

[Bingfeng Mei]

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

RE: LTO question

[Bingfeng Mei]

I just tried -fwhole-program. It can achieve extra 3%-4% saving.
That is brilliant. Thanks.

Bingfeng 

> -----Original Message-----
> From: Jan Hubicka [mailto:hubicka@ucw.cz] 
> Sent: 28 April 2010 13:59
> To: Bingfeng Mei
> Subject: Re: LTO question
> 
> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> > and it is just for solving scaling issue of large program.(These two
> > options do look similar :-). I shall try next.
> 
> Yep, -fwhopr is not ideal name, but I guess there is not much 
> to do about it.
> With -fwhole-program LTO should be a lot more effective.
> 
> Honza
> > 
> > Bingfeng
> > 
> > > -----Original Message-----
> > > From: Jan Hubicka [mailto:hubicka@ucw.cz] 
> > > Sent: 28 April 2010 12:21
> > > To: Bingfeng Mei
> > > Subject: Re: LTO question
> > > 
> > > > 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.
> > > Did you also tested with -fwhole-program? :)
> > > 
> > > Honza
> > > > 
> > > > 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
> > > > > >
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 

Re: LTO question

[Dave Korn]

On 28/04/2010 10:44, Bingfeng Mei wrote:
> Thanks, I will check what I can do with collect2. 

  I was also planning to work on this, but won't have any objection if you get
there before me!  We have an open PR about this, would you care to use

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376

to co-ordinate?

    cheers,
      DaveK

RE: LTO question

[Bingfeng Mei]

Thanks. I am not very familiar with ELF/lto format etc. But 
making LTO work for our port is definitely in high priority.
I shall see what I can achieve in next weeks. 

Bingfeng

> -----Original Message-----
> From: Dave Korn [mailto:dave.korn.cygwin@googlemail.com] 
> Sent: 28 April 2010 14:59
> To: Bingfeng Mei
> Cc: Richard Guenther; gcc@gcc.gnu.org
> Subject: Re: LTO question
> 
> On 28/04/2010 10:44, Bingfeng Mei wrote:
> > Thanks, I will check what I can do with collect2. 
> 
>   I was also planning to work on this, but won't have any 
> objection if you get
> there before me!  We have an open PR about this, would you care to use
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
> 
> to co-ordinate?
> 
>     cheers,
>       DaveK
> 
> 
> 

Re: LTO question

[Manuel López-Ibáñez]

>> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
>> > and it is just for solving scaling issue of large program.(These two
>> > options do look similar :-). I shall try next.
>>
>> Yep, -fwhopr is not ideal name, but I guess there is not much
>> to do about it.

It is marked as experimental, so if it is going to stay for GCC 4.6,
then we should change the name. I think one possibility discussed
somewhere is that LTO scales back automatically, so the option would
be not necessary.

Cheers,

Manuel.

Re: LTO question

[Diego Novillo]

On 4/28/10 10:26 , Manuel López-Ibáñez wrote:
>>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
>>>> and it is just for solving scaling issue of large program.(These two
>>>> options do look similar :-). I shall try next.
>>>
>>> Yep, -fwhopr is not ideal name, but I guess there is not much
>>> to do about it.
> 
> It is marked as experimental, so if it is going to stay for GCC 4.6,
> then we should change the name. I think one possibility discussed
> somewhere is that LTO scales back automatically, so the option would
> be not necessary.

Yes.  I think we should just keep -flto and make it use split
compilation if needed.  -fwhopr is only needed to explicitly enable it.
 My suggestion is to just keep -flto and invoke whopr with -flto=split
or -flto=big (until the automatic threshold is added).


Diego.

Re: LTO question

[Jan Hubicka]

> On 4/28/10 10:26 , Manuel LĂłpez-IbĂĄ?ez wrote:
> >>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> >>>> and it is just for solving scaling issue of large program.(These two
> >>>> options do look similar :-). I shall try next.
> >>>
> >>> Yep, -fwhopr is not ideal name, but I guess there is not much
> >>> to do about it.
> > 
> > It is marked as experimental, so if it is going to stay for GCC 4.6,
> > then we should change the name. I think one possibility discussed
> > somewhere is that LTO scales back automatically, so the option would
> > be not necessary.
> 
> Yes.  I think we should just keep -flto and make it use split
> compilation if needed.  -fwhopr is only needed to explicitly enable it.
>  My suggestion is to just keep -flto and invoke whopr with -flto=split
> or -flto=big (until the automatic threshold is added).

Yep, I like this idea too.  I hope to be able to drop "experimental" status
from mainline whopr soonish (basically I need to implement references and then
I will burn a lot of time fixing how clones are streamed to enable ipa-cp).

We probably want something like

 -flto for "do whatever you think is best"
       (it will be interesting to unify the paths enough so WPA can decide to be
        LTO at its will after reading in cgraph and concluding on program size)
 -flto=n to force whopr optimized for N parallel coputations (we probably will
       end up with more than N units for sufficiently large programs since we anyway
       can't resonably expect that compile times will be even).
 -flto=incremental to force inremental LTO.

Honza
> 
> 
> Diego.

Re: LTO question

[Jan Hubicka]

> > On 4/28/10 10:26 , Manuel LĂłpez-IbĂĄ?ez wrote:
> > >>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> > >>>> and it is just for solving scaling issue of large program.(These two
> > >>>> options do look similar :-). I shall try next.
> > >>>
> > >>> Yep, -fwhopr is not ideal name, but I guess there is not much
> > >>> to do about it.
> > > 
> > > It is marked as experimental, so if it is going to stay for GCC 4.6,
> > > then we should change the name. I think one possibility discussed
> > > somewhere is that LTO scales back automatically, so the option would
> > > be not necessary.
> > 
> > Yes.  I think we should just keep -flto and make it use split
> > compilation if needed.  -fwhopr is only needed to explicitly enable it.
> >  My suggestion is to just keep -flto and invoke whopr with -flto=split
> > or -flto=big (until the automatic threshold is added).
> 
> Yep, I like this idea too.  I hope to be able to drop "experimental" status
> from mainline whopr soonish (basically I need to implement references and then
> I will burn a lot of time fixing how clones are streamed to enable ipa-cp).

And do something about paralelizing the whopr build.  I guess it means storing
ltrans partition list into file and making collect2 to execute compilation
and re-invent the Makefile code?
It would be great if someone took look at this, I am not at all familiar with that
code and in a way I would preffer it to stay that way ;))

Honza

Re: LTO question

[Richard Guenther]

2010/4/29 Jan Hubicka <hubicka@ucw.cz>:
>> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote:
>> > >>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
>> > >>>> and it is just for solving scaling issue of large program.(These two
>> > >>>> options do look similar :-). I shall try next.
>> > >>>
>> > >>> Yep, -fwhopr is not ideal name, but I guess there is not much
>> > >>> to do about it.
>> > >
>> > > It is marked as experimental, so if it is going to stay for GCC 4.6,
>> > > then we should change the name. I think one possibility discussed
>> > > somewhere is that LTO scales back automatically, so the option would
>> > > be not necessary.
>> >
>> > Yes.  I think we should just keep -flto and make it use split
>> > compilation if needed.  -fwhopr is only needed to explicitly enable it.
>> >  My suggestion is to just keep -flto and invoke whopr with -flto=split
>> > or -flto=big (until the automatic threshold is added).
>>
>> Yep, I like this idea too.  I hope to be able to drop "experimental" status
>> from mainline whopr soonish (basically I need to implement references and then
>> I will burn a lot of time fixing how clones are streamed to enable ipa-cp).
>
> And do something about paralelizing the whopr build.  I guess it means storing
> ltrans partition list into file and making collect2 to execute compilation
> and re-invent the Makefile code?
> It would be great if someone took look at this, I am not at all familiar with that
> code and in a way I would preffer it to stay that way ;))

I will look at moving the LTRANS driving to the driver, it should be
easy to do parallel execs from it and hopefully make debugging
WPA/LTRANS less of a headache.

Richard.

> Honza
>

Re: LTO question

[Jan Hubicka]

> 2010/4/29 Jan Hubicka <hubicka@ucw.cz>:
> >> > On 4/28/10 10:26 , Manuel LĂłpez-IbĂĄ?ez wrote:
> >> > >>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> >> > >>>> and it is just for solving scaling issue of large program.(These two
> >> > >>>> options do look similar :-). I shall try next.
> >> > >>>
> >> > >>> Yep, -fwhopr is not ideal name, but I guess there is not much
> >> > >>> to do about it.
> >> > >
> >> > > It is marked as experimental, so if it is going to stay for GCC 4.6,
> >> > > then we should change the name. I think one possibility discussed
> >> > > somewhere is that LTO scales back automatically, so the option would
> >> > > be not necessary.
> >> >
> >> > Yes.  I think we should just keep -flto and make it use split
> >> > compilation if needed.  -fwhopr is only needed to explicitly enable it.
> >> >  My suggestion is to just keep -flto and invoke whopr with -flto=split
> >> > or -flto=big (until the automatic threshold is added).
> >>
> >> Yep, I like this idea too.  I hope to be able to drop "experimental" status
> >> from mainline whopr soonish (basically I need to implement references and then
> >> I will burn a lot of time fixing how clones are streamed to enable ipa-cp).
> >
> > And do something about paralelizing the whopr build.  I guess it means storing
> > ltrans partition list into file and making collect2 to execute compilation
> > and re-invent the Makefile code?
> > It would be great if someone took look at this, I am not at all familiar with that
> > code and in a way I would preffer it to stay that way ;))
> 
> I will look at moving the LTRANS driving to the driver, it should be
> easy to do parallel execs from it and hopefully make debugging
> WPA/LTRANS less of a headache.

That would be great, thanks!
It would be also great to get the parallel build working, but I guess it can be done
inrementally.

One problem is that we output .o files via assembly.  We produce a lot of temporary
data and producing all temporary .s files and processing them alter from collect
will increase memory use etc...
So probably doing as from wpa itself is sort of needed to avoid this bottleneck.

Honza
> 
> Richard.
> 
> > Honza
> >

Re: LTO question

[Xinliang David Li]

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

RE: LTO question

[Bingfeng Mei]

I turned on -ffunction-sections and compiled with -Os. 
The size gain at -O2 is less though.

Bingfeng

> -----Original Message-----
> From: Xinliang David Li [mailto:davidxl@google.com] 
> Sent: 29 April 2010 17:17
> To: Bingfeng Mei
> Cc: Richard Guenther; gcc@gcc.gnu.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)?
> 
> 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
> >> >
> >>
> >>
> >
> 
> 

Re: LTO question

[Xinliang David Li]

On Thu, Apr 29, 2010 at 9:28 AM, Bingfeng Mei <bmei@broadcom.com> wrote:
> I turned on -ffunction-sections and compiled with -Os.
> The size gain at -O2 is less though.

Interesting.

Thanks,

David
>
> Bingfeng
>
>> -----Original Message-----
>> From: Xinliang David Li [mailto:davidxl@google.com]
>> Sent: 29 April 2010 17:17
>> To: Bingfeng Mei
>> Cc: Richard Guenther; gcc@gcc.gnu.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)?
>>
>> 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
>> >> >
>> >>
>> >>
>> >
>>
>>
>

Re: LTO question

[Richard Guenther]

On Tue, Oct 13, 2009 at 5:18 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
>
>
>> -----Original Message-----
>> From: Richard Guenther [mailto:richard.guenther@gmail.com]
>> Sent: 13 October 2009 16:15
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: LTO question
>>
>> On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei
>> <bmei@broadcom.com> wrote:
>> > Hello,
>> > I just had the first taste with the latest LTO merge on our port.
>> > Compiler is configured with LTO enabled and built correctly.
>> > I tried the following example:
>> >
>> > a.c
>> > extern void foo(int);
>> > int main()
>> > {  foo(20);
>> >  return 1;
>> > }
>> >
>> > b.c
>> > #include <stdio.h>
>> > void foo(int c)
>> > {
>> >  printf("Hello world: %d\n", c);
>> > }
>> >
>> > compiled with:
>> > firepath-elf-gcc -flto a.c b.c -save-temps -O2
>> >
>> > I expected that foo should be inlined into main, but not.
>> Both functions
>> >  of main and foo are present in a.s, while b.s contains the
>> LTO code.
>> >
>> > Did I miss something here? Are there new hooks I should
>> specify or tune for
>> > LTO? I checked the up-to-date internal manual and found nothing.
>>
>> non-inline declared functions are inlined at -O2 only if doing so
>> does not increase program size.  Use -O3 or -finline-functions.
>
> But the function is only called once here. It should always decrease size unless
> my cost function is terribly wrong.  I will check how other targets such as
> x86 do here.

The function is still exported if you do not use -fwhole-program.

Richard.

RE: LTO question

[Bingfeng Mei]

 

> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com] 
> Sent: 13 October 2009 16:15
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: LTO question
> 
> On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei 
> <bmei@broadcom.com> wrote:
> > Hello,
> > I just had the first taste with the latest LTO merge on our port.
> > Compiler is configured with LTO enabled and built correctly.
> > I tried the following example:
> >
> > a.c
> > extern void foo(int);
> > int main()
> > {  foo(20);
> >  return 1;
> > }
> >
> > b.c
> > #include <stdio.h>
> > void foo(int c)
> > {
> >  printf("Hello world: %d\n", c);
> > }
> >
> > compiled with:
> > firepath-elf-gcc -flto a.c b.c -save-temps -O2
> >
> > I expected that foo should be inlined into main, but not.  
> Both functions
> >  of main and foo are present in a.s, while b.s contains the 
> LTO code.
> >
> > Did I miss something here? Are there new hooks I should 
> specify or tune for
> > LTO? I checked the up-to-date internal manual and found nothing.
> 
> non-inline declared functions are inlined at -O2 only if doing so
> does not increase program size.  Use -O3 or -finline-functions.

But the function is only called once here. It should always decrease size unless
my cost function is terribly wrong.  I will check how other targets such as 
x86 do here. 


> 
> Richard.
> 
> > Thanks,
> > Bingfeng Mei
> >
> >
> >
> 
> 

Re: LTO question

[Richard Guenther]

On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> Hello,
> I just had the first taste with the latest LTO merge on our port.
> Compiler is configured with LTO enabled and built correctly.
> I tried the following example:
>
> a.c
> extern void foo(int);
> int main()
> {  foo(20);
>  return 1;
> }
>
> b.c
> #include <stdio.h>
> void foo(int c)
> {
>  printf("Hello world: %d\n", c);
> }
>
> compiled with:
> firepath-elf-gcc -flto a.c b.c -save-temps -O2
>
> I expected that foo should be inlined into main, but not.  Both functions
>  of main and foo are present in a.s, while b.s contains the LTO code.
>
> Did I miss something here? Are there new hooks I should specify or tune for
> LTO? I checked the up-to-date internal manual and found nothing.

non-inline declared functions are inlined at -O2 only if doing so
does not increase program size.  Use -O3 or -finline-functions.

Richard.

> Thanks,
> Bingfeng Mei
>
>
>

Re: LTO question

[Diego Novillo]

On Tue, Oct 13, 2009 at 09:46, Bingfeng Mei <bmei@broadcom.com> wrote:

> Thanks. It works. I thought -fwhole-program was used with --combine and they are replaced
> by -flto. Now it seems that -flto is equivalent of --combine, and -fwhole-program is still
> important.

That's approximately correct, yes.  --combine will likely be
deprecated soon in favour of -flto.  The -fwhole-program flag simply
allows the inter-procedural optimizer to make more aggressive
assumptions.


Diego.

RE: LTO question

[Bingfeng Mei]

Thanks. It works. I thought -fwhole-program was used with --combine and they are replaced
by -flto. Now it seems that -flto is equivalent of --combine, and -fwhole-program is still
important. 

Bingfeng  

> -----Original Message-----
> From: Diego Novillo [mailto:dnovillo@google.com] 
> Sent: 13 October 2009 14:30
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: LTO question
> 
> On Tue, Oct 13, 2009 at 08:47, Bingfeng Mei <bmei@broadcom.com> wrote:
> 
> > a.c
> > extern void foo(int);
> > int main()
> > {  foo(20);
> >  return 1;
> > }
> >
> > b.c
> > #include <stdio.h>
> > void foo(int c)
> > {
> >  printf("Hello world: %d\n", c);
> > }
> >
> > compiled with:
> > firepath-elf-gcc -flto a.c b.c -save-temps -O2
> >
> > I expected that foo should be inlined into main, but not.  
> Both functions
> >  of main and foo are present in a.s, while b.s contains the 
> LTO code.
> 
> Try adding -fwhole-program.
> 
> 
> Diego.
> 
> 

Re: LTO question

[Diego Novillo]

On Tue, Oct 13, 2009 at 08:47, Bingfeng Mei <bmei@broadcom.com> wrote:

> a.c
> extern void foo(int);
> int main()
> {  foo(20);
>  return 1;
> }
>
> b.c
> #include <stdio.h>
> void foo(int c)
> {
>  printf("Hello world: %d\n", c);
> }
>
> compiled with:
> firepath-elf-gcc -flto a.c b.c -save-temps -O2
>
> I expected that foo should be inlined into main, but not.  Both functions
>  of main and foo are present in a.s, while b.s contains the LTO code.

Try adding -fwhole-program.


Diego.

LTO question

[Bingfeng Mei]

Hello,
I just had the first taste with the latest LTO merge on our port.  
Compiler is configured with LTO enabled and built correctly. 
I tried the following example: 
 
a.c
extern void foo(int);
int main()
{  foo(20);
  return 1;
}  

b.c
#include <stdio.h>
void foo(int c)
{
  printf("Hello world: %d\n", c);
}

compiled with:
firepath-elf-gcc -flto a.c b.c -save-temps -O2
 
I expected that foo should be inlined into main, but not.  Both functions
 of main and foo are present in a.s, while b.s contains the LTO code. 
 
Did I miss something here? Are there new hooks I should specify or tune for 
LTO? I checked the up-to-date internal manual and found nothing.
 
Thanks,
Bingfeng Mei