[all-commits] [llvm/llvm-project] b391c0: Re-apply 3fab2d138e30, now with a triple added

Mon Feb 7 13:27:08 PST 2022

  Branch: refs/heads/release/14.x
  Home:   https://github.com/llvm/llvm-project
  Commit: b391c02561bc14e7b2c761dcfff08ea621158acc
      https://github.com/llvm/llvm-project/commit/b391c02561bc14e7b2c761dcfff08ea621158acc
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h
    A llvm/test/DebugInfo/MIR/InstrRef/spill-slot-limits.mir
    M llvm/unittests/CodeGen/InstrRefLDVTest.cpp

  Log Message:
  -----------
  Re-apply 3fab2d138e30, now with a triple  added

Was reverted in 1c1b670a73a9 as it broke all non-x86 bots. Original commit
message:

[DebugInfo][InstrRef] Add a max-stack-slots-to-track cut-out

In certain circumstances with things like autogenerated code and asan, you
can end up with thousands of Values live at the same time, causing a large
working set and a lot of information spilled to the stack. Unfortunately
InstrRefBasedLDV doesn't cope well with this and consumes a lot of memory
when there are many many stack slots. See the reproducer in D116821.

It seems very unlikely that a developer would be able to reason about
hundreds of live named local variables at the same time, so a huge working
set and many stack slots is an indicator that we're likely analysing
autogenerated or instrumented code. In those cases: gracefully degrade by
setting an upper bound on the amount of stack slots to track. This limits
peak memory consumption, at the cost of dropping some variable locations,
but in a rare scenario where it's unlikely someone is actually going to
use them.

In terms of the patch, this adds a cl::opt for max number of stack slots to
track, and has the stack-slot-numbering code optionally return None. That
then filters through a number of code paths, which can then chose to not
track a spill / restore if it touches an untracked spill slot. The added
test checks that we drop variable locations that are on the stack, if we
set the limit to zero.

Differential Revision: https://reviews.llvm.org/D118601

(cherry picked from commit 14aaaa12366f7d1328b5ec81c71c63de9d878e75)

  Commit: e870e07019abf9c05660f30c49458b7699f9c5bd
      https://github.com/llvm/llvm-project/commit/e870e07019abf9c05660f30c49458b7699f9c5bd
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h

  Log Message:
  -----------
  [DebugInfo][InstrRef][NFC] Cache some PHI resolutions

Install a cache of DBG_INSTR_REF -> ValueIDNum resolutions, for scenarios
where the value has to be reconstructed from several DBG_PHIs. Whenever
this happens, it's because branch folding + tail duplication has messed
with the SSA form of the program, and we have to solve a mini SSA problem
to find the variable value. This is always called twice, so it makes sense
to cache the value.

This gives a ~0.5% geomean compile-time-performance improvement on CTMark.

Differential Revision: https://reviews.llvm.org/D118455

(cherry picked from commit d556eb7e27c25ae20befb0811bc8a3423241431d)

  Commit: 762c17b7b6f24a55b4071382f822114128bb3af1
      https://github.com/llvm/llvm-project/commit/762c17b7b6f24a55b4071382f822114128bb3af1
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h

  Log Message:
  -----------
  [DebugInfo][InstrRef][NFC] Free resources at an earlier stage

This patch releases some memory from InstrRefBasedLDV earlier that it would
otherwise. The underlying problem is:
 * We store a big table of "live in values for each block",
 * We translate that into DBG_VALUE instructions in each block,

And both exist in memory at the same time, which needlessly doubles that
information. The most of what this patch does is: as we progressively
translate live-in information into DBG_VALUEs, we free the variable-value /
machine-value tracking information as we go, which significantly reduces
peak memory.

While I'm here, also add a clear method to wipe variable assignments that
have been accumulated into VLocTracker objects, and turn a DenseMap into
a SmallDenseMap to avoid an initial allocation.

Differential Revision: https://reviews.llvm.org/D118453

(cherry picked from commit a80181a81ea44215e49e5da1457614ec0bd44111)

  Commit: 89d7063d7ece761901f3d4c8313d29b21a846d85
      https://github.com/llvm/llvm-project/commit/89d7063d7ece761901f3d4c8313d29b21a846d85
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h

  Log Message:
  -----------
  [DebugInfo][InstrRef][NFC] Use depth-first scope search for variable locs

This patch aims to reduce max-rss from instruction referencing, by avoiding
keeping variable value information in memory for too long. Instead of
computing all the variable values then emitting them to DBG_VALUE
instructions, this patch tries to stream the information out through a
depth first search:
 * Make use of the fact LexicalScopes gives a depth-number to each lexical
   scope,
 * Produce a map that identifies the last lexical scope to make use of a
   block,
 * Enumerate each scope in LexicalScopes' DFS order, solving the variable
   value problem,
 * After each scope is processed, look for any blocks that won't be used by
   any other scope, and emit all the variable information to DBG_VALUE
   instructions.

Differential Revision: https://reviews.llvm.org/D118460

(cherry picked from commit 9fd9d56dc6bdeeddf8cf2af834c6c39d00cd7244)

  Commit: 87f0dd330eaa089ca4034dffc105a7f2eef6b90c
      https://github.com/llvm/llvm-project/commit/87f0dd330eaa089ca4034dffc105a7f2eef6b90c
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp

  Log Message:
  -----------
  Follow up to 9fd9d56dc6b, avoid a memory leak

Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.

As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.

(cherry picked from commit 206cafb680cea0741f8c7b276351db516ff27f81)

  Commit: 64adff8ec0c14d2184a4a7cfae4bc503ed41bcea
      https://github.com/llvm/llvm-project/commit/64adff8ec0c14d2184a4a7cfae4bc503ed41bcea
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/test/DebugInfo/MIR/InstrRef/single-assign-propagation.mir

  Log Message:
  -----------
  [DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877

This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are represented by a
DbgValue object with Kind "Undef", explicitly meaning "there is no value".
In D117877 I added a special-case to some assignment accounting faster,
without considering this scenario. It causes variables to be given the
value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The
DenseMap asserts, because EmptyValue is the tombstone key.

Fix this by handling the assign-undef scenario in the special case, to
match what happens in the general case: the variable has no value if it's
only ever assigned $noreg / undef.

Differential Revision: https://reviews.llvm.org/D118715

(cherry picked from commit 43de305704a50983bf134d8fb916f752a02eb076)

  Commit: a03ffad5d34c6d1df14e25df17f18ea2fa437c0c
      https://github.com/llvm/llvm-project/commit/a03ffad5d34c6d1df14e25df17f18ea2fa437c0c
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2022-02-07 (Mon, 07 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/LiveDebugValues/LiveDebugValues.cpp
    M llvm/test/DebugInfo/X86/instr-ref-flag.ll

  Log Message:
  -----------
  [DebugInfo] Re-enable instruction referencing for x86_64

After discussion in D116821 this was turned off in 74db5c8c95e,
14aaaa12366f7 applied to limit the maximum memory consumption in rare
conditions, plus some performance patches.

(cherry picked from commit 6e03a68b776dc06826dacbdab26d24a90bb2173b)

Compare: https://github.com/llvm/llvm-project/compare/592367ab7ea8...a03ffad5d34c