This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test
- From: "hubicka at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 17 Jan 2017 13:44:41 +0000
- Subject: [Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test
- Auto-submitted: auto-generated
- References: <bug-77445-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that the remaining missed threads loop exit condition test state !=
INVALID which after sequence of threads gets to probability 0 because original
guess from profile_estimate is not realistic.
I guess such repeated threading may be common. It may be interesting to
benchmark the following hack both for speed and size:
Index: tree-ssa-threadbackward.c
===================================================================
--- tree-ssa-threadbackward.c (revision 244527)
+++ tree-ssa-threadbackward.c (working copy)
@@ -311,7 +311,11 @@ profitable_jump_thread_path (vec<basic_b
return NULL;
}
- if (speed_p && optimize_edge_for_speed_p (taken_edge))
+ if (speed_p
+ && (optimize_edge_for_speed_p (taken_edge)
+ || optimize_edge_for_speed_p (find_edge
+ ((*path)[path->length () - 1],
+ (*path)[path->length () - 2]))))
{
if (n_insns >= PARAM_VALUE (PARAM_MAX_FSM_THREAD_PATH_INSNS))
{
It makes us to consider threading the path if at least it starts by an hot
edge.