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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
commit r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Mon Mar 9 13:38:23 2020 +0100

    alias: Punt after walking too many VALUEs during a toplevel find_base_term
call [PR94045]

    As mentioned in the PR, on a largish C++ testcase the compile time
    on i686-linux is about 16 minutes on a fast box, mostly spent in
    find_base_term recursive calls dealing with very deep chains of preserved
    VALUEs during var-tracking.

    The following patch punts after we process many VALUEs (we already have
code
    to punt if we run into a VALUE cycle).

    I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
    function columns piped through sort | uniq -c | sort -n):
         36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
        108 32 _first_test.go reflect_test.reflect_test..import
       1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
       1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
       1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
       1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
       2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
       6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
       6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
       8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
       8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
      41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
    Additionally, for most of these (for the builtins definitions tested just
    one) I've verified with a different alias.c change which didn't punt but
    in the toplevel find_base_term recorded if visited_vals reached the limit
    whether the return value was NULL_RTX or something different, and in all
    these cases the end result was NULL_RTX, so at least in these cases it
    should just shorten the time until it returns NULL.

    2020-03-09  Jakub Jelinek  <ja...@redhat.com>

            PR rtl-optimization/94045
            * params.opt (-param=max-find-base-term-values=): New option.
            * alias.c (find_base_term): Add cut-off for number of visited
VALUEs
            in a single toplevel find_base_term call.

Reply via email to