[all-commits] [llvm/llvm-project] 956f5c: [lldb] Use SmallVector for handling register data

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 956f5c5f6de88af7d0c9844ab40979bb45a51ad4
      https://github.com/llvm/llvm-project/commit/956f5c5f6de88af7d0c9844ab40979bb45a51ad4
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2023-06-27 (Tue, 27 Jun 2023)

  Changed paths:
    M lldb/include/lldb/Utility/RegisterValue.h
    M lldb/source/Host/common/NativeRegisterContext.cpp
    M lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
    M lldb/source/Plugins/ABI/AArch64/ABISysV_arm64.cpp
    M lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
    M lldb/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
    M lldb/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
    M lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
    M lldb/source/Target/RegisterContext.cpp
    M lldb/source/Utility/RegisterValue.cpp

  Log Message:
  -----------
  [lldb] Use SmallVector for handling register data

Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.

This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.

With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.

https://developer.arm.com/documentation/ddi0616/latest/

"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."

"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."

99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.

Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).

The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.

I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.

Reviewed By: JDevlieghere

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