[PATCH] D83047: [LiveDebugValues] 2/4 Add instruction-referencing LiveDebugValues implementation

[Jeremy Morse via Phabricator via llvm-commits]

jmorse marked 2 inline comments as done.
jmorse added a comment.

On the topic of entry values, I believe the value based tracking should make identifying entry values trivial -- all entry value numbers will be identifiable (as a ValueIDNum) with "BlockNo=0" and "InstNo="0", indicating a value defined before the first instruction of the first block. Ideally, the logic would be after machine-value-numbers and variable-values are propagated, when final locations are picked, and would look like this:

- This variables value is an entry value (BlockNo=0,InstNo=0),
- That value isn't available in any machine location right now
- I will emit a DBG_VALUE containing a DW_OP_LLVM_entry_value expression.

Right now I've got some extra work on this (InstrRefBasedLDV) patch to be done, more on that shortly, and a patch series adding some initial DBG_INSTR_REF support to upload. I should be able to prod the entry-value situation after that.



================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:132
+///   Overlapping fragments
+///   Entry values
+///   Add back DEBUG statements for debugging this
----------------
djtodoro wrote:
> From the RFC [0]:
> 
> >The new implementation has enough information to solve this, as it tracks all
> >values in all machine locations. Unfortunately it doesn't make much difference
> >to the location statistics for clang RelWithDebInfo builds. An additional
> >benefit is that we would be better placed to produce saner locations lists [4].
> 
> Have you disabled the Debug Entry Values feature (in the original LideDebugValues) when comparing new and old implementations?
> It adds a lot of extra inputs with location lists, so it may be interesting to see the comparison without it.
> 
> [0] http://lists.llvm.org/pipermail/llvm-dev/2020-June/142368.html
I disabled entry-values for the comparison, as it wasn't going to be an apples-to-apples comparison otherwise.

I think there might be scope for more recovered variable locations once entry-value propagation is implemented as it's likely to be more precise. Right now it's just a hunch though.


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:1648
+  // Copy MTracker info, including subregs if available.
+  InstrRefBasedLDV::performCopy(SrcReg, DestReg);
+
----------------
djtodoro wrote:
> This will help us to get rid of [0]?
> 
> [0] https://github.com/llvm/llvm-project/blob/f24ac13aaae63d92317dac839ce57857a7b444dc/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp#L587
Entirely I hope!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83047/new/

https://reviews.llvm.org/D83047