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

[Hsiangkai Wang via Phabricator via llvm-commits]

HsiangKai added a comment.

In https://reviews.llvm.org/D50621#1215946, @bjope wrote:

> 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.


If there is only -run-pass=livedebugvars in the llc command, it will trigger following assertion.

lib/CodeGen/LiveDebugVariables.cpp:391: void {anonymous}::LDVImpl::clear(): Assertion `(!ModifiedMF || EmitDone) && "Dbg values are not emitted in LDV"' failed.

After tracing the source code, I found that if the MF is modified in livedebugvars, it will check `EmitDone` to ensure the modification is emitted. In addition, virtregrewriter is the only one pass to emit these modifications. So, if the MF is modified in livedebugvars, it must run virtregrewriter pass.

I think we could add -run-pass=virtregrewriter in the llc command. It will bring three additional passes after livedebugvars pass as follow.

Live Stack Slot Analysis
Virtual Register Map
Virtual Register Rewriter

What do you think?


Repository:
  rL LLVM

https://reviews.llvm.org/D50621