This is the mail archive of the gcc-bugs@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]

[Bug lto/54966] Does LTO requires a larger inline-unit-growth?


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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> 2012-10-23 14:02:05 UTC ---
On Tue, 23 Oct 2012, hubicka at ucw dot cz wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966
> 
> --- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> 2012-10-23 13:59:38 UTC ---
> > I'm not sure how we count the initial unit size, given that when not using
> > LTO not merged comdats are probably counted here, so overall they add up
> > while the initial LTO unit size may be considerably smaller than the sum
> > of the non-LTO unit sizes.
> 
> I do not realy see problem here.   We simply count size of the unit by summing
> all the functions in the callgraph prior inlining (after merging). So in the
> case of LTO we count COMDATs once and if they are unused by non-LTO we promote
> them to static and get better inlining due removing offline copies (that we are
> acccounting as inline decisions are made).  In the case of non-LTO we count
> COMDAT in every unit that has the COMDAT used + we have heuristic predicting
> that most likely the COMDAT will be eliminated in the other units, too, if it
> is eliminated in the current unit.  So we inline them almost as aggressively as
> statics, but not quite.
> 
> What kind of problem are you looking into?

I was just guessing why our overall unit-growth heuristics would
lead to different overall inlining with LTO vs. single TUs.

Richard.


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