Page MenuHomePhabricator

debug-infoProject
ActivePublic

Recent Activity

Today

aprantl added inline comments to D60716: [DwarfDebug] Dump call site debug info into DWARF.
Mon, Apr 22, 10:31 AM · debug-info
aprantl added inline comments to D58042: [LiveDebugValues] Emit parameter's entry value.
Mon, Apr 22, 10:10 AM · debug-info
aprantl added inline comments to D60715: [ISEL] Collect argument's forwarding regs when lowering calls.
Mon, Apr 22, 10:03 AM · debug-info
aprantl added a comment to D58033: Add option for emitting dbg info for call site parameters.

Is there some kind of testcase?

Mon, Apr 22, 9:48 AM · debug-info
djtodoro updated the diff for D60716: [DwarfDebug] Dump call site debug info into DWARF.

-Rebase

Mon, Apr 22, 4:53 AM · debug-info
djtodoro updated the diff for D58042: [LiveDebugValues] Emit parameter's entry value.

-Rebase

Mon, Apr 22, 4:53 AM · debug-info
djtodoro updated the diff for D60715: [ISEL] Collect argument's forwarding regs when lowering calls.

-Rebase

Mon, Apr 22, 4:53 AM · debug-info
djtodoro added a parent revision for D58034: [IR/DIVar] Add flag for params that have unchanged values: D60961: [TargetOption] Add option for enabling param entry val tracking dbg info.
Mon, Apr 22, 4:49 AM · debug-info
djtodoro added a child revision for D60961: [TargetOption] Add option for enabling param entry val tracking dbg info: D58034: [IR/DIVar] Add flag for params that have unchanged values.
Mon, Apr 22, 4:49 AM · debug-info
djtodoro edited child revisions for D58033: Add option for emitting dbg info for call site parameters, added: 1; removed: 1.
Mon, Apr 22, 4:49 AM · debug-info
djtodoro added a parent revision for D60961: [TargetOption] Add option for enabling param entry val tracking dbg info: D58033: Add option for emitting dbg info for call site parameters.
Mon, Apr 22, 4:49 AM · debug-info
djtodoro removed a parent revision for D58034: [IR/DIVar] Add flag for params that have unchanged values: D58033: Add option for emitting dbg info for call site parameters.
Mon, Apr 22, 4:49 AM · debug-info
djtodoro updated the diff for D58033: Add option for emitting dbg info for call site parameters.

-Add only cc1 option
-Set up back end

Mon, Apr 22, 4:47 AM · debug-info
djtodoro created D60961: [TargetOption] Add option for enabling param entry val tracking dbg info.
Mon, Apr 22, 4:45 AM · debug-info
djtodoro abandoned D58043: Add experimental options for call site related dbg info.
Mon, Apr 22, 4:39 AM · debug-info
djtodoro removed a child revision for D58043: Add experimental options for call site related dbg info: D60716: [DwarfDebug] Dump call site debug info into DWARF.
Mon, Apr 22, 4:37 AM · debug-info
djtodoro removed a parent revision for D60716: [DwarfDebug] Dump call site debug info into DWARF: D58043: Add experimental options for call site related dbg info.
Mon, Apr 22, 4:37 AM · debug-info
djtodoro edited child revisions for D58042: [LiveDebugValues] Emit parameter's entry value, added: 1; removed: 1.
Mon, Apr 22, 4:37 AM · debug-info
djtodoro removed a parent revision for D58043: Add experimental options for call site related dbg info: D58042: [LiveDebugValues] Emit parameter's entry value.
Mon, Apr 22, 4:37 AM · debug-info
djtodoro added a parent revision for D60716: [DwarfDebug] Dump call site debug info into DWARF: D58042: [LiveDebugValues] Emit parameter's entry value.
Mon, Apr 22, 4:37 AM · debug-info

Thu, Apr 18

jmellorcrummey added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

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.

Thu, Apr 18, 9:39 PM · debug-info, Restricted Project
aprantl added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

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.

I think we fundamentally disagree on what is good for profiling.

Thu, Apr 18, 9:17 PM · debug-info, Restricted Project
jmellorcrummey added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

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.

Thu, Apr 18, 7:55 PM · debug-info, Restricted Project
anemet added inline comments to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.
Thu, Apr 18, 6:18 PM · debug-info, Restricted Project
aprantl added a comment to D60866: [DWARF] Handle DW_OP_entry_value operand.

This looks mostly good, IMO what's missing is

Thu, Apr 18, 5:13 PM · debug-info
aprantl added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.
In D60831#1472518, @vsk wrote:

As the lead of a project building profiling tools, I am strongly against having any instructions map to line 0.

This is probably not what you meant, but for completeness I feel like I should point out that there are many legitimate situations where LLVM generates a line 0 location. The most prominent example is instruction merging: Since both LLVM IR and DWARF currently require each PC address to map to exactly one source location, LLVM's will insert a line 0 location when it merges two instructions with distinct source locations. I can't speak for profiling, but at least on the debugger side, the consensus is that potentially misleading information is worse than no information, because if there is no way to distinguish "always correct" from "maybe correct" information, the user can't trust any information.

When merging happens, I don't see why mapping to 0 is better than attributing it to one of a set of locations that a fused operation came from. I see that as representative of reality.

I would prefer a rule stating that if two operations are merged, always pick the lexicographically least (file, line number) pair. In the case of mappings for merged instructions, I see either mapping as "correct".

I don't see things this way. Arbitrarily picking a location can result in a false execution history being presented to the user. Line 0 works a lot better imo, because it a) doesn't actively mislead and b) preserves inline scope.

FWIW, the motivating case for the introduction of getMergedLocation, which generally handles the insertion of line 0 locations in this case was to improve the performance of profile-guided optimized code when using a sampling profiler tool (see http://llvm.org/devmtg/2017-03//assets/slides/delivering_sample_based_pgo_for_playstation_r_4.pdf ).

I looked at the slides. The PGO is nice work. The slide about getMergedLocation describes the rationale for mapping to line 0 rather than another line mapping if the line mappings don't agree. I don't see it wrong to simply choose one.

Thu, Apr 18, 4:59 PM · debug-info, Restricted Project
vsk added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

As the lead of a project building profiling tools, I am strongly against having any instructions map to line 0.

This is probably not what you meant, but for completeness I feel like I should point out that there are many legitimate situations where LLVM generates a line 0 location. The most prominent example is instruction merging: Since both LLVM IR and DWARF currently require each PC address to map to exactly one source location, LLVM's will insert a line 0 location when it merges two instructions with distinct source locations. I can't speak for profiling, but at least on the debugger side, the consensus is that potentially misleading information is worse than no information, because if there is no way to distinguish "always correct" from "maybe correct" information, the user can't trust any information.

When merging happens, I don't see why mapping to 0 is better than attributing it to one of a set of locations that a fused operation came from. I see that as representative of reality.

I would prefer a rule stating that if two operations are merged, always pick the lexicographically least (file, line number) pair. In the case of mappings for merged instructions, I see either mapping as "correct".

Thu, Apr 18, 4:46 PM · debug-info, Restricted Project
jmellorcrummey added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

As the lead of a project building profiling tools, I am strongly against having any instructions map to line 0.

This is probably not what you meant, but for completeness I feel like I should point out that there are many legitimate situations where LLVM generates a line 0 location. The most prominent example is instruction merging: Since both LLVM IR and DWARF currently require each PC address to map to exactly one source location, LLVM's will insert a line 0 location when it merges two instructions with distinct source locations. I can't speak for profiling, but at least on the debugger side, the consensus is that potentially misleading information is worse than no information, because if there is no way to distinguish "always correct" from "maybe correct" information, the user can't trust any information.

Thu, Apr 18, 4:39 PM · debug-info, Restricted Project
gbedwell added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

As the lead of a project building profiling tools, I am strongly against having any instructions map to line 0.

This is probably not what you meant, but for completeness I feel like I should point out that there are many legitimate situations where LLVM generates a line 0 location. The most prominent example is instruction merging: Since both LLVM IR and DWARF currently require each PC address to map to exactly one source location, LLVM's will insert a line 0 location when it merges two instructions with distinct source locations. I can't speak for profiling, but at least on the debugger side, the consensus is that potentially misleading information is worse than no information, because if there is no way to distinguish "always correct" from "maybe correct" information, the user can't trust any information.

Thu, Apr 18, 2:57 PM · debug-info, Restricted Project
aprantl added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.
Thu, Apr 18, 2:48 PM · debug-info, Restricted Project
jmellorcrummey added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

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?

I brought this up in some offline discussions which all concluded that the impact on profilers would be small and the trade off for better debugging is worth it. The impact on profilers seems like it would be small because the middle block is only visited once after running through the vectorized loop.

I am glad you asked because this concern gives rise to an argument for giving the middle block instructions line 0 instead, and i am interested in hearing other's opinions.

Interesting. The middle block just has the check for whether or not we need to run the remainder loop, right? I can definitely see this as kind of latch-like.

@jmellorcrummey , do you have an opinion on this?

Thu, Apr 18, 2:28 PM · debug-info, Restricted Project
aprantl added a reviewer for D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion: anemet.
Thu, Apr 18, 10:04 AM · debug-info, Restricted Project
aprantl added inline comments to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.
Thu, Apr 18, 10:04 AM · debug-info, Restricted Project
aprantl added a comment to D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size.

Having a bit of hard time minimizing the Chromium failure to something useful.

Thu, Apr 18, 9:57 AM · Restricted Project, debug-info
probinson added a comment to D58033: Add option for emitting dbg info for call site parameters.

@probinson @aprantl Thanks a lot for your comments!

Let's clarify some things. I'm sorry about the confusion.

Initial patch for the functionality can be restricted by this option (like we pushed here), since LLDB doesn't read this type of debug info (yet).
The plan is, when LLDB has all necessary info and we are sure that everything works fine during using this info in debugging sessions, we can turn it to ON by default.

Does that make sense ? :)

Thu, Apr 18, 7:36 AM · debug-info
djtodoro updated the diff for D60716: [DwarfDebug] Dump call site debug info into DWARF.

-Rebase
-Update tests

Thu, Apr 18, 6:24 AM · debug-info
djtodoro added a child revision for D58042: [LiveDebugValues] Emit parameter's entry value: D58043: Add experimental options for call site related dbg info.
Thu, Apr 18, 6:23 AM · debug-info
djtodoro added a parent revision for D58043: Add experimental options for call site related dbg info: D58042: [LiveDebugValues] Emit parameter's entry value.
Thu, Apr 18, 6:23 AM · debug-info
djtodoro added a parent revision for D58042: [LiveDebugValues] Emit parameter's entry value: D60866: [DWARF] Handle DW_OP_entry_value operand.
Thu, Apr 18, 6:23 AM · debug-info
djtodoro added a child revision for D60866: [DWARF] Handle DW_OP_entry_value operand: D58042: [LiveDebugValues] Emit parameter's entry value.
Thu, Apr 18, 6:23 AM · debug-info
djtodoro removed a parent revision for D60866: [DWARF] Handle DW_OP_entry_value operand: D58042: [LiveDebugValues] Emit parameter's entry value.
Thu, Apr 18, 6:21 AM · debug-info
djtodoro removed a child revision for D58042: [LiveDebugValues] Emit parameter's entry value: D60866: [DWARF] Handle DW_OP_entry_value operand.
Thu, Apr 18, 6:21 AM · debug-info
djtodoro edited child revisions for D60715: [ISEL] Collect argument's forwarding regs when lowering calls, added: 1; removed: 1.
Thu, Apr 18, 6:20 AM · debug-info
djtodoro removed a parent revision for D58042: [LiveDebugValues] Emit parameter's entry value: D60715: [ISEL] Collect argument's forwarding regs when lowering calls.
Thu, Apr 18, 6:20 AM · debug-info
djtodoro added a parent revision for D60866: [DWARF] Handle DW_OP_entry_value operand: D60715: [ISEL] Collect argument's forwarding regs when lowering calls.
Thu, Apr 18, 6:20 AM · debug-info
djtodoro edited child revisions for D58042: [LiveDebugValues] Emit parameter's entry value, added: 1; removed: 1.
Thu, Apr 18, 6:16 AM · debug-info
djtodoro added a parent revision for D60866: [DWARF] Handle DW_OP_entry_value operand: D58042: [LiveDebugValues] Emit parameter's entry value.
Thu, Apr 18, 6:16 AM · debug-info
djtodoro removed a parent revision for D58043: Add experimental options for call site related dbg info: D58042: [LiveDebugValues] Emit parameter's entry value.
Thu, Apr 18, 6:16 AM · debug-info
djtodoro created D60866: [DWARF] Handle DW_OP_entry_value operand.
Thu, Apr 18, 6:15 AM · debug-info
djtodoro updated the diff for D58042: [LiveDebugValues] Emit parameter's entry value.

-Use DW_OP_entry_value from DWARF 5
-Split up introduction and production of entry values

Thu, Apr 18, 6:15 AM · debug-info