[all-commits] [llvm/llvm-project] 3db7d0: [MachineFunction][DebugInfo][nfc] Introduce EntryV...

[Felipe de Azevedo Piovezan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3db7d0dffb9875e8e180567b079f7d8e3fc5843f
      https://github.com/llvm/llvm-project/commit/3db7d0dffb9875e8e180567b079f7d8e3fc5843f
  Author: Felipe de Azevedo Piovezan <fpiovezan at apple.com>
  Date:   2023-05-11 (Thu, 11 May 2023)

  Changed paths:
    M llvm/include/llvm/CodeGen/MachineFunction.h
    M llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
    M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
    M llvm/lib/CodeGen/MIRPrinter.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    M llvm/lib/CodeGen/StackColoring.cpp
    M llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

  Log Message:
  -----------
  [MachineFunction][DebugInfo][nfc] Introduce EntryValue variable kind

MachineFunction keeps a table of variables whose addresses never change
throughout the function. Today, the only kinds of locations it can
handle are stack slots.

However, we could expand this for variables whose address is derived
from the value a register had upon function entry. One case where this
happens is with variables alive across coroutine funclets: these can
be placed in a coroutine frame object whose pointer is placed in a
register that is an argument to coroutine funclets.

```
define @foo(ptr %frame_ptr) {
  dbg.declare(%frame_ptr, !some_var,
              !DIExpression(EntryValue, <ptr_arithmetic>))
```

This is a patch in a series that aims to improve the debug information
generated by the CoroSplit pass in the context of `swiftasync`
arguments. Variables stored in the coroutine frame _must_ be described
the entry_value of the ABI-defined register containing a pointer to the
coroutine frame. Since these variables have a single location throughout
their lifetime, they are candidates for being stored in the
MachineFunction table.

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