search for: dbgvaluehistorycalcul

Here is a proposal for improving DbgValueHistoryCalculator and the overall quality of debug locations. Focus: This is about lowering the DBG_VALUE machine instructions to DWARF location lists. Non-focus: This is not about (typical -O0) variables that permanently reside at a frame index and are described with dbg.declare intrinsics in the IR. These va...

...=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=M2Zg7H-gbv_tNUdRj7CBGjONnJqWE6I4H4MPu8YCxS8&s=7reEDqWf8_HRQoLhVbC4yfuU3vREoye6EczLjLAb_dU&e=>, where I tried to implement something similar. Looks like we're now at the point where we *do* require complicated solution and analysis in DbgValueHistoryCalculator... On Tue, Jun 23, 2015 at 4:41 PM, Adrian Prantl <aprantl at apple.com> wrote: > Here is a proposal for improving DbgValueHistoryCalculator and the > overall quality of debug locations. > > Focus: This is about lowering the DBG_VALUE machine instructions to > DWARF locat...

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses

> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Good point. > > Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x" > > My fix would be to propagate the DEBUG_VALUE only if "x" is associated with only a

The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! thanks, Adrian > On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > In retrospect I totally agree with you. I am looking at LiveDebugValue again to see

...*cpt--; > return 0x55; > } > } > > return 0x55; > } > > @paul: Yes you are right, I have investigated the backend and it all > starts at *IfConversionPass*. *r4* is clobbered by *poplt*, and there's > no logic to handle conditional instruction in *DbgValueHistoryCalculator*, > thus the issue at the binary level. > > Son Tuan Vu > > On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com> wrote: > >> As Adrian said, we'd need to see the source of foo() to assess what the >> location-list for bar ought to be. >> &gt...

...*cpt = 3; return 0xAA; } else { *cpt--; return 0x55; } } return 0x55; } @paul: Yes you are right, I have investigated the backend and it all starts at *IfConversionPass*. *r4* is clobbered by *poplt*, and there's no logic to handle conditional instruction in *DbgValueHistoryCalculator*, thus the issue at the binary level. Son Tuan Vu On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com> wrote: > As Adrian said, we'd need to see the source of foo() to assess what the > location-list for bar ought to be. > > Without actually going to look, I wou...

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors

...correct in some cases, they can't rely on any of the debug info to be correct. -- adrian If the conditional instruction poplt was addlt r4, r0, 3 for example, what should be the correct location list of bar? For now, my only idea is to check if the clobbering MI is a conditional return in DbgValueHistoryCalculator which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. Looking forward to hearing your thoughts on this, Thank you for reading this, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...else { > *cpt--; > return 0x55; > } > } > > return 0x55; > } > > @paul: Yes you are right, I have investigated the backend and it all starts at IfConversionPass. r4 is clobbered by poplt, and there's no logic to handle conditional instruction in DbgValueHistoryCalculator, thus the issue at the binary level. > > Son Tuan Vu > > On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com <mailto:paul.robinson at sony.com>> wrote: > As Adrian said, we'd need to see the source of foo() to assess what the location-list for bar ought...

..., I'd expect to read the value of *bar* from *r4* in the remaining of the function. If the conditional instruction *poplt *was *addlt r4, r0, 3* for example, what should be the correct location list of *bar*? For now, my only idea is to check if the clobbering MI is a *conditional return* in *DbgValueHistoryCalculator* which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. Looking forward to hearing your thoughts on this, Thank you for reading this, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...ses, they can't rely on any of the debug info to be correct. -- adrian > > If the conditional instruction poplt was addlt r4, r0, 3 for example, what should be the correct location list of bar? > > For now, my only idea is to check if the clobbering MI is a conditional return in DbgValueHistoryCalculator which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. > > Looking forward to hearing your thoughts on this, > > Thank you for reading this, > > Son Tuan Vu -------------- next part -------------- An HTML attachment...

I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct

...elease+Asserts build llvm[3]: Compiling X86MachineFunctionInfo.cpp for Release+Asserts build llvm[3]: Compiling LoopInstSimplify.cpp for Release+Asserts build llvm[3]: Compiling IPA.cpp for Release+Asserts build llvm[3]: Compiling X86PadShortFunction.cpp for Release+Asserts build llvm[3]: Compiling DbgValueHistoryCalculator.cpp for Release+Asserts build llvm[3]: Compiling InlineCost.cpp for Release+Asserts build llvm[3]: Compiling LoopInterchange.cpp for Release+Asserts build llvm[3]: Compiling DebugLocStream.cpp for Release+Asserts build llvm[3]: Compiling X86RegisterInfo.cpp for Release+Asserts build llvm[3]: Co...