diff options
| author | Xinliang David Li <davidxl@google.com> | 2011-04-19 16:48:40 +0000 |
|---|---|---|
| committer | Xinliang David Li <davidxl@gcc.gnu.org> | 2011-04-19 16:48:40 +0000 |
| commit | 444b39959c3515529988f1b67974f46cddbb7976 (patch) | |
| tree | b761a2ebc50f88e931330b62899b2971018be996 /gcc | |
| parent | d708ce50e3a360ff34f855ce9089b040d1c87d74 (diff) | |
| download | gcc-444b39959c3515529988f1b67974f46cddbb7976.zip gcc-444b39959c3515529988f1b67974f46cddbb7976.tar.gz gcc-444b39959c3515529988f1b67974f46cddbb7976.tar.bz2 | |
revert 172213 and add assertion
From-SVN: r172722
Diffstat (limited to 'gcc')
| -rw-r--r-- | gcc/ChangeLog | 10 | ||||
| -rw-r--r-- | gcc/ipa-cp.c | 23 |
2 files changed, 11 insertions, 22 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 959d07b..9956f1a 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2011-04-19 Xinliang David Li <davidxl@google.com> + + * ipa-cp.c (ipcp_update_profiling): asserting + scale_completement is not negative. + 2011-04-19 Jakub Jelinek <jakub@redhat.com> PR target/48678 @@ -1654,6 +1659,11 @@ 2011-04-08 Xinliang David Li <davidxl@google.com> + * ipa-cp.c (ipcp_update_profiling): Correct + negative scale factor due to insane profile data. + +2011-04-08 Xinliang David Li <davidxl@google.com> + * final.c (dump_basic_block_info): New function. (final): Dump basic block. (final_scan_insn): Remove old dump. diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c index 270e58a..261d074 100644 --- a/gcc/ipa-cp.c +++ b/gcc/ipa-cp.c @@ -1115,28 +1115,7 @@ ipcp_update_profiling (void) node->count = orig_node->count * scale / REG_BR_PROB_BASE; scale_complement = REG_BR_PROB_BASE - scale; - /* Negative scale complement can result from insane profile data - in which the total incoming edge counts in this module is - larger than the callee's entry count. The insane profile data - usually gets generated due to the following reasons: - - 1) in multithreaded programs, when profile data is dumped - to gcda files in gcov_exit, some other threads are still running. - The profile counters are dumped in bottom up order (call graph). - The caller's BB counters may still be updated while the callee's - counter data is already saved to disk. - - 2) Comdat functions: comdat functions' profile data are not - allocated in comdat. When a comdat callee function gets inlined - at some callsites after instrumentation, and the remaining calls - to this function resolves to a comdat copy in another module, - the profile counters for this function are split. This can - result in sum of incoming edge counts from this module being - larger than callee instance's entry count. */ - - if (scale_complement < 0 && flag_profile_correction) - scale_complement = 0; - + gcc_assert (scale_complement >= 0); orig_node->count = orig_node->count * scale_complement / REG_BR_PROB_BASE; for (cs = node->callees; cs; cs = cs->next_callee) |