public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/64072] New: wrong cgraph node profile count
@ 2014-11-25 18:50 wmi at google dot com
  2020-04-29 17:43 ` [Bug tree-optimization/64072] " asolokha at gmx dot com
  0 siblings, 1 reply; 2+ messages in thread
From: wmi at google dot com @ 2014-11-25 18:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64072

            Bug ID: 64072
           Summary: wrong cgraph node profile count
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wmi at google dot com
                CC: davidxl at gcc dot gnu.org, hubicka at gcc dot gnu.org

We have a program like this:

A() {    // hot func
  ...
}

B() {
  A();    // very hot
  if (i) {
    A();  // very cold
  }
}

Both callsites of A will be inlined into B. In gcc func
save_inline_function_body in inline_transform stage, A's first clone
will be choosen and materialized. For our case, the clone
node choosen corresponds to the cold callsite of A.
cgraph_rebuild_references in tree_function_versioning will reset the
cgraph node count of the choosen clone to the entry bb count of func A
(A is hot). So the cgraph node count of the choosen clone becomes hot
while its inline edge count is still cold. It breaks the assumption
described here:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01366.html:
for inline node, bb->count == edge->count == edge->callee->count

For the patch committed in the thread above (it is listed below),
cg_edge->callee->count is used for profile update to its inline
instance, which leads to a hot BB in func B which is actually very
cold. The wrong profile information causes performance regression in
one of our internal benchmarks. Our internal workround is to change
cg_edge->callee->count to MIN(cg_edge->callee->count, cg_edge->count).

Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c (revision 210535)
+++ gcc/tree-inline.c (working copy)
@@ -4355,7 +4355,7 @@ expand_call_inline (basic_block bb, gimple stmt, c
      function in any way before this point, as this CALL_EXPR may be
      a self-referential call; if we're calling ourselves, we need to
      duplicate our body before altering anything.  */
-  copy_body (id, bb->count,
+  copy_body (id, cg_edge->callee->count,
        GCOV_COMPUTE_SCALE (cg_edge->frequency, CGRAPH_FREQ_BASE),
      bb, return_block, NULL);


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug tree-optimization/64072] wrong cgraph node profile count
  2014-11-25 18:50 [Bug tree-optimization/64072] New: wrong cgraph node profile count wmi at google dot com
@ 2020-04-29 17:43 ` asolokha at gmx dot com
  0 siblings, 0 replies; 2+ messages in thread
From: asolokha at gmx dot com @ 2020-04-29 17:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64072

Arseny Solokha <asolokha at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asolokha at gmx dot com

--- Comment #1 from Arseny Solokha <asolokha at gmx dot com> ---
Is it still an issue?

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-29 17:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-25 18:50 [Bug tree-optimization/64072] New: wrong cgraph node profile count wmi at google dot com
2020-04-29 17:43 ` [Bug tree-optimization/64072] " asolokha at gmx dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).