[all-commits] [llvm/llvm-project] 54a836: Follow up to 6e03a68b776dc, squelch another leak

Tue Feb 8 10:29:49 PST 2022

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

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

  Log Message:
  -----------
  Follow up to 6e03a68b776dc, squelch another leak

This patch is a sticking-paster until D118774 solves the situation with
unique_ptrs. I'm certainly wishing I'd focused on that first X_X.

(cherry picked from commit 4654fa89eacca375ff860203697982b873bbd7c8)

  Commit: bf60baea583e624ca02766e605018e3be9680a42
      https://github.com/llvm/llvm-project/commit/bf60baea583e624ca02766e605018e3be9680a42
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/test/CodeGen/X86/2011-12-26-extractelement-duplicate-load.ll
    M llvm/test/CodeGen/X86/avx512-cvt.ll
    M llvm/test/CodeGen/X86/bitcast-vector-bool.ll
    M llvm/test/CodeGen/X86/extractelement-load.ll
    M llvm/test/CodeGen/X86/oddsubvector.ll
    M llvm/test/CodeGen/X86/pr45378.ll
    M llvm/test/CodeGen/X86/scalar_widen_div.ll
    M llvm/test/CodeGen/X86/shrink_vmul.ll
    M llvm/test/CodeGen/X86/vec_cast.ll
    M llvm/test/CodeGen/X86/vec_int_to_fp.ll

  Log Message:
  -----------
  Revert "[x86] try harder to scalarize a vector load with extracted integer op uses"

This reverts commit b4b97ec813a02585000f30ac7d532dda74e8bfda.

As discussed in post-commit feedback at:
https://reviews.llvm.org/D118376
...there's a stage 2 failure on a Mac running a clang-refactor tool test.

(cherry picked from commit 7b03725097872fbd3369a7213c1d98b372aa2d78)

  Commit: dbf2f560947fcf8e7460fea3bfde443fef0eddf7
      https://github.com/llvm/llvm-project/commit/dbf2f560947fcf8e7460fea3bfde443fef0eddf7
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M lldb/include/lldb/Core/RichManglingContext.h
    M lldb/source/Core/Mangled.cpp
    M lldb/source/Core/RichManglingContext.cpp
    M lldb/source/Symbol/Symtab.cpp
    M lldb/unittests/Core/RichManglingContextTest.cpp

  Log Message:
  -----------
  [lldb] Improve RichManglingContext ergonomics (NFC)

Have the different ::Parse.* methods return the demangled string
directly instead of having to go through ::GetBufferRef.

Differential revision: https://reviews.llvm.org/D118953

(cherry picked from commit fa52788b7a6da1eab9fec0f2db5f74a8db555196)

  Commit: bee0279abedae908e344d740d5e95f4bc5e5557e
      https://github.com/llvm/llvm-project/commit/bee0279abedae908e344d740d5e95f4bc5e5557e
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M lldb/source/Core/Mangled.cpp
    M lldb/source/Symbol/Symtab.cpp
    M lldb/test/API/macosx/dyld-trie-symbols/TestDyldTrieSymbols.py

  Log Message:
  -----------
  [lldb] Don't construct the demangled strings while indexing the symbol table

The symbol table needs to demangle all symbol names when building its
index. However, this doesn't require the full mangled name: we only need
the base name and the function declaration context. Currently, we always
construct the demangled string during indexing and cache it in the
string pool as a way to speed up future lookups.

Constructing the demangled string is by far the most expensive step of
the demangling process, because the output string can be exponentially
larger than the input and unless you're dumping the symbol table, many
of those demangled names will not be needed again.

This patch avoids constructing the full demangled string when we can
partially demangle. This speeds up indexing and reduces memory usage.

I gathered some numbers by attaching to Slack:

Before
------

  Memory usage: 280MB
  Benchmark 1: ./bin/lldb -n Slack -o quit
    Time (mean ± σ):      4.829 s ±  0.518 s    [User: 4.012 s, System: 0.208 s]
    Range (min … max):    4.624 s …  6.294 s    10 runs

After
-----

  Memory usage: 189MB
  Benchmark 1: ./bin/lldb -n Slack -o quit
    Time (mean ± σ):      4.182 s ±  0.025 s    [User: 3.536 s, System: 0.192 s]
    Range (min … max):    4.152 s …  4.233 s    10 runs

Differential revision: https://reviews.llvm.org/D118814

(cherry picked from commit aed965d55d460ebcc2b442b9d799b4c1ab929157)

  Commit: 39b1d3d27ae3d0355e3b10789d63bf1e645b3d1d
      https://github.com/llvm/llvm-project/commit/39b1d3d27ae3d0355e3b10789d63bf1e645b3d1d
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M lldb/include/lldb/Core/Mangled.h
    M lldb/source/Core/Mangled.cpp
    M lldb/source/Symbol/Symtab.cpp

  Log Message:
  -----------
  [lldb] Rename DemangleWithRichManglingInfo to GetRichManglingInfo (NFC)

This addresses Pavel's comment from D118814.

(cherry picked from commit edbb0f6df76b04100357c7c9438f3b5b978e0200)

  Commit: 47ea1e198cec19da30fd3e63b4452147696fb388
      https://github.com/llvm/llvm-project/commit/47ea1e198cec19da30fd3e63b4452147696fb388
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp

  Log Message:
  -----------
  [lldb] Use mangled symbol name to look for __asan::AsanDie()

After aed965d we no longer demangle full symbol names while indexing the
symbol table which means we have to use the mangled name instead of the
demangled name to find the symbol for __asan::AsanDie().

This fixes the following two tests:

  lldb-api :: functionalities/asan/TestMemoryHistory.py
  lldb-api :: functionalities/asan/TestReportData.py

(cherry picked from commit ef3fade14b32c20e0a35b8fca30e7d2f20e0c983)

  Commit: 39e9a64cf5847935c2ba0099f4bf39945d8ee19b
      https://github.com/llvm/llvm-project/commit/39e9a64cf5847935c2ba0099f4bf39945d8ee19b
  Author: ksyx <18738953+ksyx at users.noreply.github.com>
  Date:   2022-02-08 (Tue, 08 Feb 2022)

  Changed paths:
    M clang/lib/Format/DefinitionBlockSeparator.cpp
    M clang/unittests/Format/DefinitionBlockSeparatorTest.cpp

  Log Message:
  -----------
  [clang-format] Fix DefSeparator empty line issues

- Add or remove empty lines surrounding union blocks.
- Fixes https://github.com/llvm/llvm-project/issues/53229, in which
  keywords like class and struct in a line ending with left brace or
  whose next line is left brace only, will be falsely recognized as
  definition line, causing extra empty lines inserted surrounding blocks
  with no need to be formatted.

Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D119067

(cherry picked from commit a70549ae43dfa551f3eacdfa7a7f2c0df073be8e)

Compare: https://github.com/llvm/llvm-project/compare/56dcb10a9942...39e9a64cf584