This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/54966] Does LTO requires a larger inline-unit-growth?
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 Oct 2012 14:02:05 +0000
- Subject: [Bug lto/54966] Does LTO requires a larger inline-unit-growth?
- Auto-submitted: auto-generated
- References: <bug-54966-4@http.gcc.gnu.org/bugzilla/>
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.