Please cherry-pick several debug-info patches for llvm-14-rc1

[jmorse]

Hi Tom / release-engineering team,

I've been working on a debug-info variable location feature which missed the llvm-14 branch by a few hours. It was enabled on main for x86_64 for 2 weeks without much trouble, but I turned it off after receiving a reproducer for excessive memory consumption, for which I now have patches. I've got several commits that would need to be cherry picked (below), would you be alright with this being
in llvm14-rc1?

A few faults reported from the initial landing are here, https://reviews.llvm.org/D116821, which I can summarise if needs be, but they're all now fixed. I ended up disabling the feature after some auto-generated code in https://reviews.llvm.org/D116821#3278089 led to a 5x increase in memory consumption, fixed by https://reviews.llvm.org/D118601 adding an upper bound on tracking too much debug-info.

The patches to cherry-pick in would be:

• 14aaaa1 (Re-)Apply max an upper-bound on the amount of debug-info to track,

• d556eb7 A performance patch (memoize some queries)

• a80181a Early-free some data structures

• 9fd9d56 Optimise an algorithm to reduce max-rss

• 206cafb Follow up to the above for an accident with asan

• 43de305 Fix for a crash introduced by an unrelated performance opt

• 6e03a68 Re-enable this feature by default for x86_64

The last of these just landed a few minutes ago, so it's worth leaving things ~24h to settle on main. As mentioned, it was on for 2 weeks beforehand without any major incidents.

(If needs be I can cherry-pick -x these to the release branch myself, exactly what the protocol is before -rc1 is unclear to me).

[jmorse]

NB: I've put all the cherry picks on this branch: https://github.com/jmorse/llvm-project/tree/release-14-instr-ref , for ease of access if these get merged.

Note that this also features 4654fa8, a temporary fix to keep asan happy while D118774 is finished. It's a very shallow object lifetime problem that I wasn't paying enough attention to, rather than a deep-seated issue.

[tstellar]

/cherry-pick 14aaaa1 d556eb7 a80181a 9fd9d56 206cafb 43de305 6e03a68

[llvmbot]

/branch llvmbot/llvm-project/issue53548

[llvmbot]

/pull-request llvmbot#8

[llvmbot]

@llvm/issue-subscribers-debuginfo

[jmorse]

For the avoidance of doubt: 4654fa8 will also be required to avoid a memory leak found by LeakSanitizer. As mentioned in my previous comment there's a generalised solution to this problem in D118774 being developed, but that's likely to only be ready for -rc2.

[tstellar]

For the avoidance of doubt: 4654fa8 will also be required to avoid a memory leak found by LeakSanitizer. As mentioned in my previous comment there's a generalised solution to this problem in D118774 being developed, but that's likely to only be ready for -rc2.

My mistake, I did not realize 4654fa8 was upstream. I will cherry-pick that one too.

[tstellar]

/cherry-pick 4654fa8

[tstellar]

Merged: b391c02 e870e07 762c17b 89d7063 87f0dd3 64adff8 a03ffad

[tstellar]

/branch llvmbot/llvm-project/issue53548

[llvmbot]

/pull-request llvmbot#12

[tstellar]

Merged: 54a8365