[Bug tree-optimization/71148] [7 Regression] Compile time hog w/ -O3 -funroll-loops

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue May 17 08:36:00 GMT 2016


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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-05-17
                 CC|                            |ienkovich at gcc dot gnu.org
   Target Milestone|---                         |7.0
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Most of the time this is dominator queries w/o the FAST query
support,
that is, a pass forgetting to call caculcate_dominance_info.

For the first testcase the pass/caller is

#3  0x00000000009a046d in redirect_immediate_dominators (dir=CDI_DOMINATORS, 
    bb=0x7ffff6a16548, to=0x7ffff6891c30)
    at /space/rguenther/src/svn/trunk/gcc/dominance.c:849
849           et_split (son);
(gdb) 
#4  0x000000000091509e in merge_blocks (a=0x7ffff6891c30, b=0x7ffff6a16548)
    at /space/rguenther/src/svn/trunk/gcc/cfghooks.c:842
842         redirect_immediate_dominators (CDI_DOMINATORS, b, a);
(gdb) 
#5  0x0000000001758bfb in try_optimize_cfg (mode=96)
    at /space/rguenther/src/svn/trunk/gcc/cfgcleanup.c:2804
2804                          merge_blocks (b, c);
(gdb) 
#6  0x0000000001759d87 in cleanup_cfg (mode=96)
    at /space/rguenther/src/svn/trunk/gcc/cfgcleanup.c:3151
3151      while (try_optimize_cfg (mode))
(gdb) 
#7  0x000000000179843b in rest_of_handle_cse2 ()
    at /space/rguenther/src/svn/trunk/gcc/cse.c:7637
7637          cse_cfg_altered |= cleanup_cfg (CLEANUP_CFG_CHANGED);

thus cleanup_cfg updating dominance info.  Note the et_splay operation itself
is this slow (another reason for this may be a corrupt et forest after the
recent x86 backend "issues" with dominance info).


More information about the Gcc-bugs mailing list