https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 12 Nov 2014, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 > > --- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> --- > With early VRP (but also without) the inliner seems to now suffer from extreme > roundoff errors at badness. With VRP the first uninlined function still has > badness 0: > > Considering std::_Bit_reference& std::_Bit_reference::operator=(bool)/797 with > 15 size > to be inlined into <built-in>/47767 in /aux/hubicka/tramp3d-v4.cpp:38764 > Estimated badness is 0, frequency 0.71. > Badness calculation for <built-in>/47767 -> std::_Bit_reference& > std::_Bit_reference::operator=(bool)/797 > size growth 8, time 5 inline hints: declared_inline > 0: guessed profile. frequency 0.709000, benefit 0.002000%, time w/o > inlining 500006, time w inlining 499996 overall growth 612 (current) 398 > (original) > not inlinable: <built-in>/47767 -> std::_Bit_reference& > std::_Bit_reference::operator=(bool)/797, --param inline-unit-growth limit > reached > Estimating body: std::basic_ostream<char, _Traits>& > std::operator<<(std::basic_ostream<char, _Traits>&, const char*) [with _Traits > = std::char_traits<char>]/2076 > Known to be false: not inlined, op1 == 0B, op1 changed > size:7 time:22 > > so inline decisions are basically random. I tuned this few times, but it is > hard to balance the fixpoint arithmetic to not get into 0. The function in > question is very small, but there are too many of them. > > I wonder if we can't switch inliner to std::priority_queue and use sreal to > drive the priority queue? Or one can hold fractions and compare in wide int > calculations. I think using sreal is fine - I expect that to be faster than using wide_int (and smaller). Random inlining decisions are bad :/ (and hard to debug) Richard.
