summaryrefslogtreecommitdiff
path: root/flang
diff options
context:
space:
mode:
authorFelipe de Azevedo Piovezan <fpiovezan@apple.com>2023-04-30 09:48:01 -0400
committerFelipe de Azevedo Piovezan <fpiovezan@apple.com>2023-05-11 07:29:57 -0400
commit3db7d0dffb9875e8e180567b079f7d8e3fc5843f (patch)
tree7d2db514a5fa04b11aff8c838070c317cce5b344 /flang
parent4d9c936a3e1a647356226c0355a194b94465ad2c (diff)
downloadllvm-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