On 7/30/2021 4:39 AM, Aldy Hernandez via Gcc-patches wrote:
It occurs to me that I should not have disabled early jump threading in
this test, as it may hide an actual defect. I have reverted my change
and XFAILed the test instead. I have also opened a PR101690 to keep track
of this problem.
I have pushed this patch, but could benefit from someone with knowledge
of loop-ch and/or RTL shrink wrapping to look at the PR, as here we have
a valid jump thread that is causing loop_ch to drastically change the
probabilities ultimately having us fail at shrink wrapping.
Thanks.
gcc/testsuite/ChangeLog:
* gcc.dg/shrink-wrap-loop.c: Enable early jump threading. Mark as
XFAIL.
Getting the profile data right with jump threading can be painful. See
the huge comment at the start of
tree-ssa-threadupdate.c::compute_path_counts.
The backwards threader uses a completely different copying/update
mechanism. It's probably not using compute_path_counts (and it's not
even clear if it could) and I suspect the copier/updater that is being
used for backwards threading doesn't handle those cases right.
Jeff
---
gcc/testsuite/gcc.dg/shrink-wrap-loop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
b/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
index ba872fa23f6..6e1be8937fe 100644
--- a/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
+++ b/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
@@ -1,6 +1,5 @@
/* { dg-do compile { target { { { i?86-*-* x86_64-*-* } && lp64 } || {
arm_thumb2 } } } } */
/* { dg-options "-O2 -fdump-rtl-pro_and_epilogue" } */
-// { dg-additional-options "-fdisable-tree-ethread" }
/*
Our new threader is threading things a bit too early, and causing the
@@ -69,4 +68,4 @@ test (int *p1, int *p2)
return 1;
}
-/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue"
} } */
+/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue"
{ xfail *-*-* } } } */
