[PATCH] D50621: [DebugInfo] Fix bug in LiveDebugVariables.

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

In https://reviews.llvm.org/D50621#1215318, @HsiangKai wrote:

> Thanks @bjope for providing a good test case for the patch.
>  It will trigger another assertion due to no emitDebugValues() after livedebugvars.
>  I found it depends on VirtRegRewriter. So, I will change -run-pass to -stop-after.
>  Besides this, the test case works after applying the patch.


Not sure I understand the above. My suggestion was to only run the livedebugvars pass (making the test case specific to that pass).
Now you changed the -run-pass to -stop-after, but in which pass does it start then? Don't you need a start-before/-start-after as well to indicate where to start?
AFAIK "-run-pass=livedebugvars" is the same as "-start-before=livedebugvars -stop-after=livedebugvars", so we do not run VirtRegRewriter when using a single -run-pass like that.

Note that a problem with running these register allocation passes standalone is that handwritten input could be abnormal. Lot's of DBG_VALUE instructions are normally removed before we get to livedebugvars, and then they are added back to the IR by VirtRegRewriter. And we do not include information about the cached DBG_VALUE instructions in the MIR-format.

So the test case I provided does not necessarily imitate a normal situation when we get to livedebugvars (I just made up something to trigger the problem). Perhaps DBG_VALUE instructions referring to physical registers are among the cached DBG_VALUE instructions that will be reinserted by virtregrewriter. Do you know what the DBG_VALUE instructions looked like in your original TR? Was it perhaps DBG_VALUE instructions where the first operand was a constant value, I think such DBG_VALUE instructions stay in the IR during register allocation.

I don't know if it really is important how we model the DBG_VALUE instructions here, as long as they expose the problem. It is of course better to have the test case as realistic as possible.


Repository:
  rL LLVM

https://reviews.llvm.org/D50621