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

Jeremy Morse via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 19 07:50:19 PDT 2025


jmorse 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.

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] https://github.com/jmorse/llvm-project/commit/68635db547179597af8609de5e9d909c625104e4
[1] https://gist.github.com/jmorse/4e74f69f8cfa9b6a07d7c2972b3e4963

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


More information about the llvm-commits mailing list