[llvm-dev] Stripping Debug Locations on cross BB moves, part 2 (PR31891)

[Adrian Prantl via llvm-dev]

> On Feb 8, 2017, at 9:25 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> So Reid came across a case where the current strategy (dropping locations when they move across basic blocks) proves to be at odds with another precept we have: inlinable calls must have locations, so that if/when they are inlined the location can be accurately described (due to the nature of our IR representation of inlining, a location must be given for the call site so that the DIEs for the inlined subroutine can be described)
> 
> Any ideas on how we should approach this?
> 
> We could have a bit in DebugLoc (or other choice of representation) for the non-line location. For the line table this would work the same as absent DebugLoc - for calls it would cause call_file/line/discriminator (do we have a call_discriminator? We probably should, don't know if we do) to be omitted which is something the LLVM IR representation currently can't express.

Even if the function calls are not inlined it could be preferable to keep a debug location. It's a very odd debugging experience to be stopped at a breakpoint and then do "up" (or just "bt") to look at the parent frame and not have a location for the call in the parent frame.

Is the stripping in this case motivated by correctness for profiling or just to smooth the line table to improve the stepping experience?

If its about correctness for profiling, we should consider having a separate profiling location or a skip-for-profiling bit as David suggests, that honored when the CU has the new tune-for-profiling flag set.

If it is about a better stepping experience, we just shouldn't do this for call sites.

Other thoughts?
-- adrian