https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
If we have release checking enabled then we shuould hit
static void
df_analyze_1 (void)
{
...
#ifndef ENABLE_DF_CHECKING
if (df->changeable_flags & DF_VERIFY_SCHEDULED)
#endif
df_verify ();
so I wonder why df->changeable_flags & DF_VERIFY_SCHEDULED is ever true
for release checking. Can you track that down? I can't reproduce
df_verify being called on the 4.9 branch with release checking on x86_64
(OTOH x86_64 doesn't have a doloop pattern). Compile-time is 186s for 4.9,
main offenders:
df reaching defs : 24.61 (13%) usr
alias stmt walking : 13.72 ( 7%) usr
dominator optimization : 33.26 (18%) usr
expand vars : 48.89 (26%) usr
GCC 5 seems to be quite a bit worse with 400s:
df reaching defs : 13.16 ( 3%) usr
alias stmt walking : 216.73 (54%) usr
expand vars : 25.86 ( 6%) usr
load CSE after reload : 83.96 (21%) usr
GCC 6 uses a _load_ more memory on this testcase (I end up swapping with 8GB
ram
and finally get killed). So even on x86_64 the testcase looks interesting.
Note that
static bool
doloop_optimize (struct loop *loop)
{
...
iv_analysis_loop_init (loop);
/* Find the simple exit of a LOOP. */
desc = get_simple_loop_desc (loop);
performs iv_analysis_loop_init and thus df_analyze_loop twice ...
But yes, performing df_verify for each loop in a function is excessive,
we seem to lack ever clearing said flag. Does
Index: gcc/df-core.c
===================================================================
--- gcc/df-core.c (revision 239276)
+++ gcc/df-core.c (working copy)
@@ -1833,6 +1833,7 @@ df_verify (void)
if (df_live)
df_live_verify_transfer_functions ();
#endif
+ df->changeable_flags &= ~DF_VERIFY_SCHEDULED;
}
#ifdef DF_DEBUG_CFG
help in the non-DF-checking case?
