[PATCH] D38229: [DebugInfo] Insert DEBUG_VALUEs after each register redefinition

[Karl-Johan Karlsson via Phabricator via llvm-commits]

Ka-Ka added a comment.

In https://reviews.llvm.org/D38229#880149, @rnk wrote:

> One concern I have about this is that it may lead to inaccurate debug info when the value is computed long before its (dead) assignment. Consider this kind of program (untested, yet):
>
>   int v1 = getval();
>   int v2 = getval();
>   usevals(v1, v2);
>   v1 = v2;
>   if (v1) { /* empty after inlining, making v2 dead */ }
>
>
> After optimization, v1 will probably use a CSR and v2 will use a volatile register clobbered by the usevals call. So, the dead `v1 = v2` assignment will produce a DBG_VALUE of a physical register that has been clobbered. It would be innacurate to hoist the DBG_VALUE across the `usevals` call, since the value should still be the result of the first `getval` call, not the second.
>
> One way to address this would be to avoid moving DBG_VALUEs across instructions with different DebugLoc lines.
>
> Even if we decide that this issue is unimportant, we should probably write tests for it.


I agree that we need to be careful not to introduce faulty debug info, but I don't really see how this patch could introduce inaccurate debug info at least not for the testcase you specified. The patch will only reinsert DBG_VALUES when redefining the vreg within the vregs liverange (indicated by the slot indexes). Note that the patch only try to reinsert all values that was originally found in the input before they were removed by the "Live DEBUG_VALUE analysis" pass. No hoisting of DBG_VALUEs are done. As the liverange of the physical registers are changed to not be extended in the patch in https://reviews.llvm.org/D38140 (a prerequisite to this patch) no extra DEBUG_VALUEs will be inserted for physical registers.

When I tried your test program above I found that faulty hoisting of a DBG_VALUE across the call to `usevals` seems to be done by the CodeGenPrepare pass (before instruction selection). This must be a bug. If you want I can convert code above into a testcase but it will contain this faulty hoisted DBG_VALUE from the CodeGenPrepare pass. This patch will not impact that testcase.


https://reviews.llvm.org/D38229