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

[Felipe de Azevedo Piovezan via llvm-commits]

felipepiovezan 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!)

Thank you for the ideas, I am working on trying this right now! Currently stuck because `defVar` wants a an `ArrayRef<DbgOpID>`, and not an `ArrayRef< ValueIDNum>`; I'm looking into how we can convert from one to the other.

By the way, since we are tackling separate problems here, I will likely merge this PR first and address the propagation issue separately!

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