[Bug debug/96729] [11 Regression] slow compile with `-g -O3` since r11-39-gf9e1ea10e657af9f

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

https://gcc.gnu.org/g:ace10c37de7c2f9f2d419337dc1f173c01f7ec7d

commit r9-8911-gace10c37de7c2f9f2d419337dc1f173c01f7ec7d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Aug 26 10:30:15 2020 +0200

    dwarf2out: Fix up dwarf2out_next_real_insn caching [PR96729]

    The addition of NOTE_INSN_BEGIN_STMT and NOTE_INSN_INLINE_ENTRY notes
    reintroduced quadratic behavior into dwarf2out_var_location.
    This function needs to know the next real instruction to which the var
    location note applies, but the way final_scan_insn is called outside of
    final.c main loop doesn't make it easy to look up the next real insn in
    there (and for non-dwarf it is even useless).  Usually next real insn is
    only a few notes away, but we can have hundreds of thousands of consecutive
    notes only followed by a real insn.  dwarf2out_var_location to avoid the
    quadratic behavior contains a cache, it remembers the next note and when it
    is called again on that loc_note, it can use the previously computed
    dwarf2out_next_real_insn result, rather than walking the insn chain once
    again.  But, for NOTE_INSN_{BEGIN_STMT,INLINE_ENTRY} dwarf2out_var_location
    is not called while the code puts into the cache those notes, which means
if
    we have e.g. in the worst case NOTE_INSN_VAR_LOCATION and
    NOTE_INSN_BEGIN_STMT notes alternating, the cache is not really used.

    The following patch fixes it by looking up the next NOTE_INSN_VAR_LOCATION
    if any.  While the lookup could be perhaps done together with looking for
    the next real insn once (e.g. in dwarf2out_next_real_insn or its copy),
    there are other dwarf2out_next_real_insn callers which don't need/want that
    behavior and if there are more than two NOTE_INSN_VAR_LOCATION notes
    followed by the same real insn, we need to do that "find next
    NOTE_INSN_VAR_LOCATION" walk anyway.

    On the testcase from the PR this patch speeds it 2.8times, from 0m0.674s
    to 0m0.236s (why it takes for the reporter more than 60s is unknown).

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

            PR debug/96729
            * dwarf2out.c (dwarf2out_next_real_insn): Adjust function comment.
            (dwarf2out_var_location): Look for next_note only if next_real is
            non-NULL, in that case look for the first non-deleted
            NOTE_INSN_VAR_LOCATION between loc_note and next_real, if any.

    (cherry picked from commit ca1afa261d03c9343dff1208325f87d9ba69ec7a)