[PATCH] D44610: [SelectionDAG] Support multiple dangling debug info for one value

[Reid Kleckner via Phabricator via llvm-commits]

rnk added inline comments.


================
Comment at: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h:120
+  /// DanglingDebugInfoVector - Helper type for DanglingDebugInfoMap.
+  typedef SmallVector<DanglingDebugInfo, 4> DanglingDebugInfoVector;
+
----------------
bjope wrote:
> rnk wrote:
> > Embedding SmallVector in DenseMap is usually an efficiency trap. DenseMap stores keys and values in the table, not in separate allocations, so the value of every unfilled hashtable entry is wasted. Even then, filled slots typically have one dbg.value.
> > 
> > TinyPtrVector was created for this use case, but it looks like the elements are not pointers so it will not work.
> > 
> > I guess I'd suggest using std::vector or `SmallVector<DangingDebugInfo, 0>` to minimize wasted inline storage.
> Thanks a lot for the feedback. I was a little bit worried about this part. I haven't spent any time on optimizing it really, and this first draft was aiming at getting it working in some simple way.
> 
> Now when I got the feedback that this patch is on track regarding the functionality I will go on doing some tests regarding impact on compile speed/memory consumption. After all, these problems were seen when analysing https://bugs.llvm.org/show_bug.cgi?id=36417, so it would be a pity if we end up with bad compilation performance again when solving this problem.
That's always possible, but I suspect any perf degradation will come from the extra DBG_VALUE MachineInstrs inserted after this pass, and not this data structure. Anyway, SmallVector 0 is three pointers big, and DanglingDbgInfo is three, so in the common case, there's not much change.

One way to build confidence that this isn't introducing a major regression is to measure the time to compile the optimized sqlite3.c amalgamation with debug info before and after your change. You can use `perf -r 5` on Linux to get error bars to get a sense of how precise your comparison is, and whether it's in the noise or not.


Repository:
  rL LLVM

https://reviews.llvm.org/D44610