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.
