[PATCH] D105025: [1/2][LiveDebugVariables] Avoid reduntant DBG_VALUEs after virtregrewrite

Mon Jun 28 07:35:30 PDT 2021

djtodoro added a comment.

In D105025#2844255 <https://reviews.llvm.org/D105025#2844255>, @jmorse wrote:

> This sounds great to me -- suppressing redundant DBG_VALUEs is a good aim. I'm slightly worried about performance however: in D94981 <https://reviews.llvm.org/D94981> a patch landed to cover a scenario where findInsertLocation was repeatedly stepping back over every debug instruction at the start of a block, effectively becoming quadratic-complexity. Wouldn't looking back over every DBG_VALUE already inserted, when inserting a new one, become quadratic too?
>
> Possibly the solution is to act like D94981 <https://reviews.llvm.org/D94981>, and build a temporary cache of "DBG_VALUEs already inserted at this SlotIdx".

Yes... I wanted to get a consensus this is needed, and definitely, I'll need to measure performance impact and optimize it eventually. I think some caching will be appreciated here in order to avoid (potential) performance regression.

================
Comment at: llvm/test/DebugInfo/X86/livedebugvars-avoid-duplicates.ll:4
+
+; RUN: llc -O2 %s -stop-before=livedebugvalues -o - | FileCheck %s
+
----------------
jmorse wrote:
> This is running quite a lot of llc, to then hit a fair specific scenario (DBG_VALUE then frame-setup), which makes me worry that it'll be fragile. Would it be sufficient to just check that there are two DBG_VALUEs in the output MIR, and that's it?
> 
> (Also, hard-coded metadata numbers)
yep, I'll need to fix it

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105025