search for: salvagedebuginfo

> On Apr 30, 2018, at 2:57 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with constant. You can look at llvm::salvageDebugInfo() for examples on how to handle other situations. -- adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/44cf4c7c/attac...

For cast instructions, llvm::salvageDebugInfo() simply makes dbg.value point to the source of the cast. Since SelectionDAG already has transferDbgValues which can move dbgvalue to the cast source, I think that we can just call it where the truncate is optimized away. Thanks, Sejong From: aprantl at apple.com <aprantl at apple.com> Sent...

> On Apr 30, 2018, at 3:16 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > For cast instructions, llvm::salvageDebugInfo() simply makes dbg.value point to the source of the cast. Since SelectionDAG already has transferDbgValues which can move dbgvalue to the cast source, I think that we can just call it where the truncate is optimized away. That sounds reasonable, yes. Casts are effectively transparent for debug inf...

Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with constant. Sejong From: aprantl at apple.com <aprantl at apple.com> Sent: Monday, April 30, 2018 1:53 PM To: Se Jong Oh <sejooh at microsoft.com> Cc: jdevlieghere at apple.com; Vedant Kumar <vsk at apple.com>; llvm-dev at lists.llvm.org; pidgeot18 at gm...

...the default concise dbg.value with a single argument and empty DIExpression, but salvaging becomes more brittle. If we rely on elements being on the stack in their declared order, then we need to guarantee that nothing modifies those stack elements. The cleanest implementation of this would be for SalvageDebugInfo to salvage expressions normally when the last register is salvaged, and switch to using DW_OP_pick for every register whenever any other register is salvaged: %c = add %a, 5 %e = div %c, %d ; x = %b * ((%a + 5) / %d) dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_mul), %b, %e) ; Sa...

...he call. > > Lowering the third call constructs any_extend(t21) for the 32-bit register type but optimizes out the truncate node by the following code, and it seems that the DbgValue node on the truncate is also lost. Without having looked at this in more detail: there is a facility called salvageDebugInfo that is supposed to be called on instructions and SDag nodes right before they are deleted and it attempts to attach the debug info of the dying node to another node in situations where this is possible and correct. -- adrian > > SelectionDAG::getNode(...) > ... > // (ext (trunx x...

...post-LSR setting these dbg.value are now referring to undef so the debug-info for 'p' is effectively lost. It is interesting to note that after LSR one dbg.value has its DIExpression adjusted to add the value three but it is still referring to undef. As I understand it this is the work of salvageDebugInfo. When LSR has created the new induction variable expression and starts deleting the old one salvaging will kick in. When %add.ptr is deleted it will adjust the dbg.value use of that to use the value %p.addr.05, and by doing so it must accordingly adjust the DIExpression. This all works fine until t...

...ession > >If we do it this way and allow 0-n SSA values then I'm in support of the push-first scheme. This seems like as good a case as any to go with the push-first approach, since it solves a meaningful problem that the alternative does not. >As a side note, updating dbg.values in salvageDebugInfo when we allow multiple SSA values per dbg.value will be interesting, but possible. We'll need to put the value we need to update at the top of the stack, prepend the salvage expression and then restore the order of arguments on the stack that the rest of the expression expects. The difficulty...

...ossible. There are also potential follow-up tasks, such as allowing the salvaging of conditional values, that would further improve debug variable availability. The following table gives, for several of the multi-source application projects in the test suite, the number of successful invocations of SalvageDebugInfo, and the number of failed salvages for each type of unsalvageable instruction: Success Variadic Binops Variadic GEPs Cmp Insts Select Insts Load Insts Phi Nodes Alloca Insts Call Insts ALAC 261 29...

...way: there is some value in the distinction between the intrinsics, the addresses do not use constant values (and so avoid the ambiguity described in [2]), and there are few (possibly no) cases where dbg.addr or dbg.declare intrinsics that use more than one IR value would actually be produced: only salvageDebugInfo can produce multi-value debug intrinsics, and debug address intrinsics usually use a non-salvageable alloca as the location (I am currently unsure as to whether non-alloca address intrinsics can or should be produced anywhere). Described here are the differences in the IR intrinsics: Old: @llvm.d...

On Fri, Oct 9, 2020 at 9:38 AM Cazalet-Hyams, Orlando < orlando.hyams at sony.com> wrote: > Hi Reid, > > > > Thanks for sharing this. I plan to work on improving debug-info for > variables > > living in memory as my next "project" so I am very interested to hear with > what > > others have to say about "Idea 1". > > > > There

Hi David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

Hi Jonas, I have another case that DBG_VALUE is not produced. I would appreciate it if you could take a quick look at the testcase below. test code: llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll ; Function Attrs: nounwind ssp uwtable define void @f() #0 !dbg !4 { entry: tail call void @h(i16 0) #2, !dbg !14 %call = tail call i16 (...) @g() #2, !dbg !15 tail call void

...way: there is some value in the distinction between the intrinsics, the addresses do not use constant values (and so avoid the ambiguity described in [2]), and there are few (possibly no) cases where dbg.addr or dbg.declare intrinsics that use more than one IR value would actually be produced: only salvageDebugInfo can produce multi-value debug intrinsics, and debug address intrinsics usually use a non-salvageable alloca as the location (I am currently unsure as to whether non-alloca address intrinsics can or should be produced anywhere). > > Described here are the differences in the IR intrinsics: >...

> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do