Job of this pass to broadcast DBG_VALUES to the all successive blocks where its preserved location is valid. As a natural way it should emit replacements for clobbered parameters location.
Authors: @asowda, @NikolaPrica, @djtodoro, @ivanbaev
Differential D58042
[LiveDebugValues] Emit parameter's entry value djtodoro on Feb 11 2019, 3:50 AM. Authored by
Details
Job of this pass to broadcast DBG_VALUES to the all successive blocks where its preserved location is valid. As a natural way it should emit replacements for clobbered parameters location. Authors: @asowda, @NikolaPrica, @djtodoro, @ivanbaev
Diff Detail Event Timeline
Comment Actions -Use DW_OP_entry_value from DWARF 5
Comment Actions I cherry-picked the patches on top of r359425, and tried out some examples. Doing that, I encountered a case where entry values are not inserted with this patch. When compiling the following code: int global; int foo(int p, int q, int r) { global = p + 1; asm __volatile ("" : : : "edi", "esi", "edx"); return 123; } using the following clang invocation: clang -O1 -g -Xclang -femit-param-entry-values -mllvm -stop-after=livedebugvalues gives the following MIR: body: | bb.0.entry: liveins: $edi DBG_VALUE $edi, $noreg, !15, !DIExpression(), debug-location !18 DBG_VALUE $edi, $noreg, !15, !DIExpression(), debug-location !18 DBG_VALUE $esi, $noreg, !16, !DIExpression(), debug-location !19 DBG_VALUE $edx, $noreg, !17, !DIExpression(), debug-location !20 renamable $edi = nsw ADD32ri8 killed renamable $edi, 1, implicit-def dead $eflags, debug-location !21 DBG_VALUE $edi, $noreg, !15, !DIExpression(DW_OP_entry_value, 1), debug-location !18 MOV32mr $rip, 1, $noreg, @global, $noreg, killed renamable $edi, debug-location !22 :: (store 4 into @global, !tbaa !23) INLINEASM &"", 1, 12, implicit-def dead early-clobber $edi, 12, implicit-def dead early-clobber $esi, 12, implicit-def dead early-clobber $edx, 12, implicit-def dead early-clobber $df, 12, implicit-def dead early-clobber $fpsw, 12, implicit-def dead early-clobber $eflags, !28, debug-location !27 $eax = MOV32ri 123, debug-location !29 RETQ killed $eax, debug-location !29 As seen, there is an entry value location inserted for p after $edi is clobbered by the ADD32ri8 for p + q, but there are no entry value locations inserted for q and r after the inline assembly that clobbers their respective register. Is this perhaps due to some known limitation, or should this be considered a bug? Or have I overlooked something when testing this? If I comment out the line that assigns the value to global, then LiveDebugValues emits entry value locations after the inline assembly for all three parameters. Comment Actions I had a look at this. LiveDebugValues::ExtendRanges() stops adding debug value instructions to ParamEntryVals as soon as it encounters a debug value for a variable that has already been seen, as pointed out by the "Insert DEBUG_VALUE instructions that track parameters into ParamEntryVals." block comment. In this test case we are left with redundant DEBUG_VALUE instructions for p after LiveDebugVariables: # *** IR Dump After Virtual Register Rewriter ***: # Machine code for function foo: NoPHIs, TracksLiveness, NoVRegs, NoGlobalPredicates Function Live Ins: $edi 0B bb.0.entry: liveins: $edi DBG_VALUE $edi, $noreg, !"p", !DIExpression(), debug-location !18; kommentar.c:2:13 line no:2 DBG_VALUE $edi, $noreg, !"p", !DIExpression(), debug-location !18; kommentar.c:2:13 line no:2 DBG_VALUE $esi, $noreg, !"q", !DIExpression(), debug-location !19; kommentar.c:2:20 line no:2 DBG_VALUE $edx, $noreg, !"r", !DIExpression(), debug-location !20; kommentar.c:2:27 line no:2 so that seems to be why entry values are not emitted for q and r, unless I have misunderstood something. I don't know what it would take to stop LiveDebugVariables from emitting the redundant debug values in the first place. If it is not trivial, or there might perhaps be other cases where we can land in redundant entries, then perhaps this patch should be able to handle those entries?
Comment Actions -Address suggestions
Comment Actions -Use map instead of vector for storing debug entry values Comment Actions -Addressing comments TODO: Rebase this on top of NFC D62295 Comment Actions LGTM with an extra assertion
Comment Actions Have you measured what the effect the emission of entry value locations has on the "scope bytes covered" statistics? I guess that it can increase quite a bit (especially later on if we start describing non-parameter variables using parameter entry values)? If so, if the caller(s) do not have call site information, it will still not be able to print the variable. Would it make sense, and would it be possible, to introduce a "scope bytes covered without entry values" statistic, or some other statistic, which helps you assess how large part of the locations that rely on entry values? Comment Actions @dstenb Thanks for the comment! Yes, we are constantly measuring debug location statistics. It is possible (and it makes sense) to extend the existing location statistic reporting, within LLVM, by avoiding locations that are entry values (we are actually working on that). We will share the numbers. Comment Actions -Avoid a single location represented as an entry value (+ add a test for that) Comment Actions Due to very latest patches we came up with situations when we need to avoid single location represented as an entry value.
Comment Actions
@aprantl Sure. Thanks for the comment!
@dstenb Thanks for your attention and comments. Sure, that is the plan. This is initial set of patches that covers just non-modified function parameters. Even the initial patch within the GCC was handling just this situation. The ways for improving this (using benefits of the debug entry values) are extending the support for modified parameters (if its modification could be described as an expression over its entry value), supporting local variables, etc.
Yes, it can be extended. In addition, I did not forget about sharing the info about the debug location statistic measuring. :) Comment Actions Okay, thanks for the clarification! Would it perhaps make sense to add a small sentence about that in those TODOs? Comment Actions
@dstenb Sure! Thanks! Comment Actions -Add support for entry values that are complex variables address (that avoids entry value not be safe for a single locations) Comment Actions That seems like a useful tool! Did you consider what should be done with llvm-dwarfdump's "scope bytes covered" statistics?
Comment Actions
Thanks a lot for taking a look!
I think that it sounds reasonable to add an additional field there, something like "non-entry-val scope bytes covered".
Comment Actions Just to clarify, as the emission of entry values is behind a non-driver flag I'm not opposed to landing these patches without changing llvm-dwarfdump, so please don't let me stand in the way. I think that a "non-entry-val scope bytes covered" field would be helpful, but someone with more say in the debug info area than me should decide that. Comment Actions
@dstenb We could land this right now, and the patch for the 'llvm-dwarfdump' stats could be a separate patch. Do you agree? Comment Actions Yes, that sounds good to me!
Comment Actions -Remove redundant code |
This looks dangerous.. are entry values somehow implicitly also register values? Iguess besed on the other patches the answer is yes, but that also means that we must assert((!EntryValueKind || RegNo) && "entry values must be register locations")