[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Thu Nov 13 09:03:00 GMT 2014


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.



More information about the Gcc-bugs mailing list