One of CodeGenPrepare's optimisations is to duplicate address calculations into basic blocks, so that as much information as possible can be folded into memory addressing operands. This is great -- but the dbg.value variable location intrinsics are not updated in the same way. This can lead to dbg.values referring to address computations in other blocks that will never be encoded into the DAG, while duplicate address computations are performed locally that could be used by the dbg.value. Some of these (such as non-constant-offset GEPs) can't be salvaged past.
Fix this by, whenever we duplicate an address computation into a block, looking for dbg.value users of the original memory address in the same block, and redirecting those to the local computation.
What happens if there is an earlier dbg-use of Repl (before MemoryInst) in this BB. Is there a risk that we introduce a dbguse-before-def scenario here? Maybe we need to check if MemoryInst dominates User here? Or is such input IR unlikely in reality?
There seems to be lots of cases above (for example reusing an earlier computation for SunkAddr), so maybe the important check is that SunkAddr dominates User. But as you understand from the question marks above, I haven't figured out if that always is guaranteed here.
Notice that I do not think about scenarios when the input IR already is "broken" (dgb-use before def) here. Just some worrying that we might introduce dbg-use-before-def here.
Actually the test case that you added has the dbg.value before the load in the BB that we sink the address computation into (the scenario I'm talking about). Isn't the address computation added just before the load? Is perhaps the test case working due to placeDbgValues moving the dbg.value?