Currently, ScheduleDAGInstrs have simple algorithm for re-insertion of DBG_VALUE instructions. DBG_VALUEs are attached to the nearest top MI and will be re-inserted bottom from this MI after scheduling. But is is a problem for some cases like:
r0 = Instr0 ...
r1 = Instr1 ...
r2 = Instr2 ...
DBG_VALUE var0 => r0
DBG_VALUE var1 => r1
DBG_VALUE var2 => r2
DBG_VALUEs are attached to Instr2, but the scheduler may reorder Instr0 and Instr1 after Instr2:
r2 = Instr2 ...
DBG_VALUE var0 => r0 >>> Start of var0 debug-loc liverange.
DBG_VALUE var1 => r1 >>> Start of var1 debug-loc liverange.
DBG_VALUE var2 => r2
r0 = Instr0 ... >>> End of var0 debug-loc liverange (because of r0 clobbering def).
r1 = Instr1 ... >>> End of var1 debug-loc liverange (because of r1 clobbering def).
So, the re-inserted DBG_VALUEs for var0 (register r0) and var1 (register r1) will be placed before actual def instruction for their corresponding registers. Providing cutted debug-loc liveranges for such variables.
This patch adds reattachment of DBG_VALUE to the nearest clobbering MI (other DBG_VALUE with the same variable or clobbering register def of any mayStore instruction).
Constant-defined DBG_VALUES will not be reattached.
Is there value in keeping this hidden under a flag? What is the risk of just doing this by default?