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

[Jeremy Morse via llvm-commits]

jmorse wrote:

> If we move the clobber to the second basic block in the example MIR test case shown. We get to the end of loadVarInLoc and track the location before we see the clobber, which then takes the recoverAsEntryValue path. How would the filtering work in that case? What is the condition to guard against the insertion into loadVarInLoc? We only want to do it in the case there is a clobber in the basic block right, but that is detected later. Unless, the idea is to remove the entry in ActiveVLocs once the clobber is detected.

For this I believe we can make use of the differences between LDV and how `DbgEntityHistoryCalculator` in the asm-printing phase works. `DbgEntityHistoryCalculator` only sees DBG_* instructions, LDV is effectively communicating with it through the creation of DBG_* instructions, with the internal state of `TransferTracker` helping to decide what DBG_* instructions to produce. We know several things about locations with entry-value-expressions at the start of a block:
 *  The "Value" that they correspond to isn't really loaded into a stack/register location, the register is effectively a dummy,
 * `DbgEntityHistoryCalculator` will ignore any clobbers of registers for a variable-location that's an entry value

Thus, there's actually no difference in DBG_* instructions we want created for entry-value locations in a block, regardless of whether there's a clobber or not. Looking closely at that block, without a clobber:

```
  bb.1.if.then:
    successors: %bb.3(0x80000000)
    liveins: $edi, $r13
    CALL64pcrel32 @foo, csr_64, implicit $rsp, implicit $ssp, implicit $edi, implicit-def $eax, debug-location !23
    JMP_1 %bb.3, debug-location !25
```

If we start this block with an entry value, we'll create something like `DBG_VALUE $r14, $noreg, !9, !DIExpression(DW_OP_LLVM_entry_value, 1),` to tell `DbgEntityHistoryCalculator` about it, and there's no further need to consider r14 in the block. If we have a clobber in the block,

```
  bb.1.if.then:
    successors: %bb.3(0x80000000)
    liveins: $edi, $r13
    CALL64pcrel32 @foo, csr_64, implicit $rsp, implicit $ssp, implicit $edi, implicit-def $eax,  debug-location !15
    $r14 = MOV64ri 0,  debug-location !DILocation(line: 7, column: 7, scope: !17)
    JMP_1 %bb.3,  debug-location !18
```

Then we'll start the block by creating the same DBG_VALUE with an entry-value expression. And when we get to the clobber of $r14, we know that `DbgEntityHistoryCalculator` will ignore the clobbering of r14 for any entry-value expressions at that location. Thus there's no need to produce any different DBG_* instructions in that block even though there's a clobber. Finally if we consider a scenario where the variable location is modified in the block:

```
  bb.1.if.then:
    successors: %bb.3(0x80000000)
    liveins: $edi, $r13
    CALL64pcrel32 @foo, csr_64, implicit $rsp, implicit $ssp, implicit $edi, implicit-def $eax,  debug-location !15
    DBG_INSTR_REF !9, !DIExpression(), [other args?]
    $r14 = MOV64ri 0,  debug-location !DILocation(line: 7, column: 7, scope: !17)
    JMP_1 %bb.3,  debug-location !18
```

The first thing TransferTracker will do on encountering the DBG_INSTR_REF is remove the previous location of the variable from its tracking maps. Regardless of whether the DBG_INSTR_REF is before or after the clobber.

Thus: I think the only thing we need to do for an entry-value location at the start of the block is produce the initial DBG_VALUE for it, there's no need to enter it into the value tracking maps through the block.

> The VarID that has been filtered from ActiveVLocs will still exist in ActiveMLocs and therefore cause a crash. I think we need to do more than just filter it from ActiveVLocs

Ah, right you are, we would need to not enter the information into both ActiveVLocs and ActiveMLocs. I think both those things are handled at the end of `loadVarInloc`, we'd just need to emit the DBG_VALUE first and then early-exit if it's an entry-value location?

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