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

[Jeremy Morse via llvm-commits]

https://github.com/jmorse approved this pull request.

I've got some nits inline, otherwise this looks good.

I suppose this works slightly differently to how I envisaged in past PRs, where the entry-value-ness of a variable location would be transformed into the value-numbers used to propagate variable-values around the function. I guess the differences are:
 * In my mental model, LiveDebugValues would always work out that a value is an entry-value from first principles and add DW_OP_entry_value, requiring us to produce an expression with DW_OP_entry_value _removed_ from it somewhere,
 * In this model, the variable value with entry-value expression gets propagated around the function. We then don't try to re-generate the entry-value-expression when the location gets clobbered, because it's already an entry value.

This is fine -- with the side-effect that I reckon entry-value variable locations will be re-stated in certain basic blocks with clobbers. Your adjustment to TransferTracker stops the variable location (with DW_OP_entry_value) from being tracked in the transfer tracker when an entry-value DBG_VALUE is encountered -- however at the start of each block `TransferTracker::loadInLocs` takes a collection of variable values and directly tracks them. You might need to filter out entry-value-expression variable values there too.

As an example, note line 73 in entry_value_gets_propagated.mir that I've marked. I reckon if you sink the clobber of 14 to that block:
 * You'll have an entry-value DBG_VALUE propagated to bb.1 as expected,
 * TransferTracker will track that variable as a normal live-location,
 * When r14 is clobbered in bb1, TransferTracker will try to recover the variable location, and emit another entry-value DBG_VALUE after the clobber.

This isn't incorrect, and I reckon it won't affect the variable location output at all, but you might want to tighten it up by putting a filter in `loadVarInLoc` or similar. (My confidence level on this: about 93%, I could be wrong). 

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