http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #18 from Teresa Johnson <tejohnson at google dot com> 2012-12-19 16:44:21 UTC --- On Tue, Dec 18, 2012 at 9:25 AM, hubicka at ucw dot cz <gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-18 17:25:37 > UTC --- >> I did some measurements with tramp3d and in this case >> the default (999) gives the best performance: >> >> par. size time >> -------------------- >> 999 955859 3.71752 >> 990 933390 3.73969 >> 980 904718 3.84547 >> ... " " >> 750 904718 3.84769 >> 740 837654 7.67177 >> 600 836024 8.80879 > > Yep, tramp3d is unforutnately quite special case: we measure the number of > instructions prior > late optimization, while in tramp3d over 90% of code disappear as a result of > inlining and further > simplification, so we get GIGO problem... > > I am not sure how to handle these things in any resonable way.... > > I will test couple of values on spec2k this week and lets see how things scale > elsewhere. As another data point, in our internal benchmarks I had tried a few values and 99.9% gave the best performance. Just going down to 99.0% reduced the inlining too much, even compared to the old static cutoff count, missing some key inlines and reducing performance. Thanks, Teresa > > Honza > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
