diff options
author | Felipe de Azevedo Piovezan <fpiovezan@apple.com> | 2023-04-30 09:48:01 -0400 |
---|---|---|
committer | Felipe de Azevedo Piovezan <fpiovezan@apple.com> | 2023-05-11 07:29:57 -0400 |
commit | 3db7d0dffb9875e8e180567b079f7d8e3fc5843f (patch) | |
tree | 7d2db514a5fa04b11aff8c838070c317cce5b344 /flang | |
parent | 4d9c936a3e1a647356226c0355a194b94465ad2c (diff) | |
download | llvm-3db7d0dffb9875e8e180567b079f7d8e3fc5843f.tar.gz |
[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
Diffstat (limited to 'flang')
0 files changed, 0 insertions, 0 deletions