[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[cvs-commit at gcc dot gnu.org]

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

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9708ca2be40399d6266bc85c99e085e3fe27a809

commit r10-7392-g9708ca2be40399d6266bc85c99e085e3fe27a809
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 26 09:15:39 2020 +0100

    var-tracking: Mark as sp based more VALUEs [PR92264]

    With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
    for -m64), the find_base_term visited_vals.length () > 100 find_base_term
    statistics changed (fbt is before this patch, fbt2 with this patch):
    for k in '' '1$'; do for i in 32 64; do for j in fbt fbt2; do \
    echo -n "$j $i $k "; LC_ALL=C grep ^$i.*"$k" $j | wc -l; done; done; done
    fbt 32  5313355
    fbt2 32  4229854
    fbt 64  217523
    fbt2 64  217523
    fbt 32 1$ 1296
    fbt2 32 1$ 407
    fbt 64 1$ 0
    fbt2 64 1$ 0
    For frame_pointer_needed functions, we need to wait until we see the
    fp_setter insn in the prologue at which point we disassociate the fp based
    VALUEs from sp based VALUEs, but for !frame_pointer_needed functions,
    we IMHO don't need to wait anything.  For ACCUMULATE_OUTGOING_ARGS it isn't
    IMHO worth doing anything, as there is a single sp adjustment and so there
    is no risk of many thousands deep VALUE chains, but for
    !ACCUMULATE_OUTGOING_ARGS the sp keeps changing constantly.

    2020-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/92264
            * var-tracking.c (add_stores): Call cselib_set_value_sp_based even
            for sp based values in !frame_pointer_needed
            && !ACCUMULATE_OUTGOING_ARGS functions.