[llvm] [InstrRef] Skip clobbered EntryValue register recovery (PR #142478)

[Adrian Prantl via llvm-commits]

adrian-prantl wrote:

> I guess I can see how that works -- this is becoming complicated because we're trying to bridge a constant-like-location that lives outside of "value liveness" and similar concepts, with portions of the pass that really want to consider liveness. Hence there are several bits of code that stop working well together. I also suppose you might say I'm letting perfect be the enemy of good here, and it's better to have something that does work versus creating more complexity.
> 
> Part of the problem is that I can put my finger exactly on what "perfect" (to me) looks like -- instr-ref already supports describing entry values and recovering variable-locations at the appropriate time, what's abnormal here is that the variable-locations _entering_ LiveDebugValues already have DW_OP_LLVM_entry_value attached to them. I've cooked up a prototype here [0] that "decompiles" the entry-value flag out of the DIExpression and enters the entry-value-variable-location into the usual tracking processes. The result is here [1] (input file then output file), where the entry-value-location gets propagated around the block like any other variable. However, LiveDebugValues prefers to create references to the live value in a register if it's available, instead of everything being an entry-value location.

One thing that is important to point out here is that there are different kinds of entry value that may need different treatment.

1. The entry values that are incoming in LDV are produced by the LLVM CoroSplit pass and they are needed to recover variables in virtual coroutine **parent** frames (see https://llvm.org/devmtg/2023-10/slides/quicktalks/Prantl-DebugInfoForConcurrency.pdf). A debugger can only make use of them if they are entry values.

2. LDV itself should recover unavailable variables by introducing new entry values where applicable. Here entry entry values should be the last resort and be replaced by other locations where possible

I believe that (1) should be treated like a constant and just remain undisturbed by LDV. This doesn't prevent us from doing something more clever with (2).

> 
> Is having an entry-value expression in all the variable locations, right from the entry block, part of the requirements here? (I'm assuming this is something swift-specific as AFAIUI LLVM doesn't generate these expressions).
> 
> If we can't take the "let LiveDebugValues generate entry-values itself" route, I suppose it's cleanest to fall back on the "treat entry-values like a constant" and admit their register-locations to the operand store, rather than push the complexity into other bit sof code.
> 
> [0] [jmorse at 68635db](https://github.com/jmorse/llvm-project/commit/68635db547179597af8609de5e9d909c625104e4) [1] https://gist.github.com/jmorse/4e74f69f8cfa9b6a07d7c2972b3e4963



https://github.com/llvm/llvm-project/pull/142478