https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96729
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:ca1afa261d03c9343dff1208325f87d9ba69ec7a commit r11-2872-gca1afa261d03c9343dff1208325f87d9ba69ec7a Author: Jakub Jelinek <ja...@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 <ja...@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.
