[llvm] [MachineSink] Drop debug info for instructions deleted by sink-and-fold (PR #71443)

[Jeremy Morse via llvm-commits]

jmorse wrote:

Hmmm, if I understand the optimisation correctly, the new SinkAndFold optimisation is both re-engineering how values are computed and moving around where those values are defined? By doing so, it exposes all the hard problems in debug-info at the same time unfortunately.

The biggest problem is that one dominating assignment to a vreg is being replaced with lots of localised computations. Inserting a new DBG_VALUE for each new computation works in the simple case, but it'll also re-order the appearance assignments in the complicated case, and as you're discovering it generates a lot of DBG_VALUEs. A perfect solution for this would have to do a dominance query for each existing DBG_VALUE to work out what the most-immediately dominating computation is and then update the DBG_VALUE operand to reference that, which would take up a lot of compile time. And as the outputs are all physregs, it would need a check to ensure it's not clobbered too.

Shameless plug: this is exactly why the instruction-referencing flavour of debug-info exists (https://www.youtube.com/watch?v=yxuwfNnp064 for me illustrating what it does), as it defers all of these problems until the end of compilation and then addresses them all at once. It doesn't immediately support this scenario but it'd be a very simple extension to support it. Alas it doesn't support ARM/aarch64 today, CC @felipepiovezan who was interested in that.

In the meantime, disabling this update to fix a compile-time regression seems fine. Presumably the instruction defining the vreg is deleted, so all the DBG_VALUEs will refer to a not-defined vreg, and will be undef'd at regalloc time in LiveDebugVariables? It might be clearer (and easier to test) to explicitly set the seen DBG_VALUEs to be $noreg as part of this patch.

An extension that would preserve /some/ variable locations is to examine the DBG_VALUEs that are in the same block as the sinking instruction, and examine whether sinking + updating those to the location of the new computations would re-order with other DBG_VALUEs for the same variable. Typically this would cover a good number of the variables that refer to that value. The rest of MachineSink attempts this to some extent, although it's imperfect (this was what convinced me instruction-referencing is the way to go)

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