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

[Jeremy Morse via llvm-commits]

jmorse wrote:

> Yup, there is some work to do to get that second test to work with the clobbering line uncommented. Sadly I haven't been able to figure out how, but it feels like it should be possible

Shooting from the hip -- I reckon you could interpret entry-value DBG_VALUEs into being a ValueIDNum value-number when they're observed by transferDebugValue. The middle segment of InstrRefBasedLDV all works on a basis of effectively-SSA values identified with ValueIDNums, propagating those values doesn't consider registers or liveness, only the values. So it shooouuulllddd (confidence: 90%) be possible to write in transferDebugValue something like:

    if (is-an-entry-value-expr) {
      LocIdx L = MTracker->getRegMLoc(MI.getOperand(0));
      ValueIDNum TheValue(0, 0, L);
      VTracker->defVar(MI, Props, {TheValue});
      return;
    }

Or something like that. This works because we know entry-value DBG_VALUEs always refer to the live-in value at the entry block, the block-number and instruction-number of which are well-known as zero. Thus we effectively "know the name" of the value and can pretend it's like a normal DBG_INSTR_REF or DBG_VALUE that can refer to a non-live value. It might need the entry-value parts of the expression stripping out of the expression. Another way of thinking about it is like a DBG_INSTR_REF referring to well-known pre-determined instruction/operand numbers defined for entry values.

I think (confidence: 97%) that will just flow through the SSA parts as normal, then pop out the far end as a variable that's assigned a non-live value, which Should (TM) then be described using an entry value expression again.

That's some non-trivial jumping through hoops, but on the other hand it means variable assignments using DW_OP_entry_value earlier in the compiler will compose seamlessly with variable assignments that co-incidentally lose their liveness and need expressing as an entry value.

(It does seem incredibly dirty to use some constant magic values when constructing the ValueIDNum, we could probably make named-constants to make it read better. Alas, Jeremy is secretly a C programmer who's happiest when dealing with massive arrays of integers!)

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