[PATCH] D11933: Extending debug ranges

Adrian Prantl via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 27 10:05:21 PDT 2015


aprantl added a comment.

In http://reviews.llvm.org/D11933#234164, @tvvikram wrote:

> In http://reviews.llvm.org/D11933#233887, @aprantl wrote:
>
> > Thanks so far. I added a bunch of more detailed comments inline.
>
>
> I will make the suggested changes and submit a new patch.
>
> I am not sure about the name for the new pass. Please suggest.
>  I have a couple of names though - **ImproveDebugValues.cpp**, **DebugValueDFA.cpp** (DFA: DataFlow Analysis). Please confirm.


To prevent you from having to rename the file and pass more than once, let's defer this decision until the very end.
Another possible name is "DebugValuePropagation", although "LiveDebugValues", or "DebugValueLiveness" would actually be the most fitting, because we are doing a Liveness analysis. This conflicts with the existing LiveDebugVariables pass that consumes all DBG_VALUEs that describe vregs, builds a side-table that is used during register allocation and writes out new DBG_VALUEs with real registers after regalloc is done. Perhaps we could rename the old LiveDebugVariables to "MaterializeDebugValues", or "RegallocDebugValues?

To recap, my vision is that:

- the old LiveDebugVariables becomes a simple and fast BB-local pass that emits the bare minimum of DBG_VALUEs and
- this new pass then performs the control-flow-aware liveness DFA that extends their range beyond BB boundaries by inserting enough DBG_VALUEs that
- the DWARF backend may again assume that DBG_VALUEs are BB-local (and only performs a very simple merging of adjacent ranges).

This way we will end up with small, understandable, and (via MIR) testable passes with a well-defined scope that do one task well.


http://reviews.llvm.org/D11933





More information about the llvm-commits mailing list