Thu, Apr 18
Precisely to that point I was hoping to provide a few compelling counterexamples to demonstrate why potentially wrong information is actually worse than no information.
But I guess what this really boils down to is that all debug information in LLVM IR is (at the moment) "must" information that is supposed to be either 100% reliable or omitted. It sounds like for the kinds of analysis that you are doing, you would also benefit from a second category of "may" information that may or may not be valid. That's a legitimate ask, but if we wanted to include this in LLVM IR, we would need to qualify it as not reliable, so it doesn't, for example, leak into debug info that software developers rely on.
A good example for why arbitrarily picking one location during merging is when the two locations are coming from different inlined instances of different functions (or perhaps even worse: two inlined instances of the same function). I would assume that even in profiling a wrong backtrace would invalidate or render untrustworthy large parts of any analysis being done one this data.
This looks mostly good, IMO what's missing is
-Use DW_OP_entry_value from DWARF 5
-Split up introduction and production of entry values
Sorry, I missed a couple of failing tests. I've fixed them and updated the diff.
! In D59687#1468571, @probinson wrote:
It sounds like you're trying to do this with aggregate types, and that won't work. Only base types (for DWARF 5) or address-like types (for DWARF <= 4) should end up on the stack.
Wed, Apr 17
How will this appear to profiling tools using PC sampling and using debug info to map the PC samples back to line numbers in the code?
-Remove CC1 def
Looks generally good. But...
Tue, Apr 16
And if we plan to enable it by default, too, perhaps not adding a driver option (CC1 only) is preferable, since we need to maintain compatibility with driver options indefinitely.
Only a few superficial comments inline, I'll need to read this more carefully.