[PATCH] D147134: [RFC][Debugify] Remove false positve debug location losses

Thu Apr 6 05:59:47 PDT 2023

ntesic added a comment.

Hi, thanks for your comments!

@Orlando 
I haven't done any advanced performance measurements, but for the simple build time & size checking, I didn't detect any increase in time nor size.
Regarding bugs detection, in this patch I was focused on removing results from debugify reports that can lead to a dead-end investigation of debug-location drops.
According to how-to-update-debug-info document <https://llvm.org/docs/HowToUpdateDebugInfo.html> , the `dropLocation()` should be used whereever we want to explicitly remove debug-location. However, in most places
we still use `setDebugLoc()` with `nullptr` or empty `DebugLoc` parameter. It would take a lot of time to update all of these to use `dropLocation()`.
Using spare bits in some of the existing bit vectors is definitely a better idea, I will investigate that further.

@myhsu 
I think we are on the same page. There are situations where empty debug-loc is not intentionally dropped, so we need to detect the intentional drop in some way.
The (0,0) debug-loc is already a special kind of DILocation, representing an unknown source location, but doesn't imply that the location is implicitly or explicitly dropped.
Thanks for the idea.

Based on that, I am thinking about using (0,1) debug location if it is intentionally dropped, but I am not sure if some other parts of the debug-info infrastructure expect to see exactly (0,0) debug-loc.
What are the reviewers’ opinions about this idea?

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

https://reviews.llvm.org/D147134