search for: debug_value

> 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 of vregX and insert an DEBUG_VALUE in all the MachineBasicBlocks where vregX is used. (pre regalloc) &gt...

> 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 single virtual register. > BTW, my goal is to...

...5:14 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com <mailto: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 single virtual register. >> BTW, my...

...eOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE: # @_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE .Lfunc_begin4: .loc 2 126 0 # ../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0 .cfi_startproc # BB#0: # %entry #DEBUG_VALUE: xfuncx:MO <- %RDI #DEBUG_VALUE: xfuncx:TRI <- %RSI #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX #DEBUG_VALUE: isReg:this <- %RDI .loc 2 127 18 prologue_end # ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18 movl $16777471, %eax # imm = 0x10000FF andl (%rdi), %eax .Ltm...

...; ... > Successors according to CFG: BB#3 > > BB#3: > Live Ins: %R5 > Predecessors according to CFG: BB#2 > ... > Successors according to CFG: BB#1 > > BB#4: > Predecessors according to CFG: BB#1 > > > Its obvious to me that the DEBUG_VALUE %R5, %noreg, !"argc" should be propagated to BB#1, BB#2 and BB#3. > > LiveDebugValue will currently not handle this case. The propagation will not be done for BB#1 because one of its predecessor BB3# doesn't have a DEBUG_VALUE %R5. But R5 is still guaranteed to correspond to...

...OperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE >> >> >> .Lfunc_begin4: >> .loc 2 126 0 # >> ../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0 >> .cfi_startproc >> # BB#0: # %entry >> #DEBUG_VALUE: xfuncx:MO <- %RDI >> #DEBUG_VALUE: xfuncx:TRI <- %RSI >> #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX >> #DEBUG_VALUE: isReg:this <- %RDI >> .loc 2 127 18 prologue_end # >> ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18 >>...

Hi all, An early implementation of extending debug ranges and providing multiple location support is done here: http://reviews.llvm.org/D11933 Design document: https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing On Jun 24, 2015, at 12:12 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: Hi Adrian, You might want to take a look at abandoned

...= 6, y = 8}, but the result obtained is $1 = {x = 2, y = 3}. This is related to debug information generated, as normally the overloading is occuring. eg: A1 three = one + two results {x = 6, y = 8}. On checking the assembly, a suspicious entry is found which may be related for the failure: #DEBUG_VALUE: operator+:this <- undef #DEBUG_VALUE: operator+:second <- undef -- Thanx & Regards *Mayur Pandey * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121129/75068cf8/attachment.html>

...#39;s my copy-paste at fault). At .Ltmp29 we call bad_ioapic_register() and then when returns zero (it does) we je to .LBB0_10 aka .Ltmp34. At which point we happily stomp on the value of 12(%esp) by spilling something *else* over it: .LBB0_10:                               # %if.end28 .Ltmp34: #DEBUG_VALUE: mp_register_ioapic:address <- $esi #DEBUG_VALUE: mp_register_ioapic:cfg <- [DW_OP_plus_uconst 8] [$ebp+0] .loc 2 0 1 is_stmt 0         # arch/x86/kernel/apic/io_apic_b.c:0:1 movl %ebx, 12(%esp)          # 4-byte Spill movl %edi, 20(%esp)          # 4-byte Spill Compare with the noretpol...

On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > > Did you get anywhere with the function attribute? Having isolated the > next boot failure to "it goes away if I compile io_apic.c without > retpoline", bisecting it per-function would help to further delay the > bit where I actually have to start *thinking*... It's mp_register_ioapic(), and only when

...also avoid the silly > labels that we still create when producing cfi. > Pseudo instructions are problematic. That means every function pass that iterates over the instructions has to explicitly check for them to make sure they don't affect optimization. We already have to do that for debug_value instructions, and it's really unpleasant and error prone. -Jim

...# a.c:12:0 # BB#0: pushl %ebp .Ltmp4: .cfi_def_cfa_offset 8 .Ltmp5: .cfi_offset %ebp, -8 movl %esp, %ebp .Ltmp6: .cfi_def_cfa_register %ebp pushl %ebx subl $12, %esp .Ltmp7: .cfi_offset %ebx, -12 calll .L0$pb .L0$pb: popl %ebx .Ltmp8: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp8-.L0$pb), %ebx #DEBUG_VALUE: moo:x <- ESP+4294967295 movl 8(%ebp), %eax .loc 1 13 2 prologue_end # a.c:13:2 .Ltmp9: movl %eax, 4(%esp) leal .L.str at GOTOFF(%ebx), %eax movl %eax, (%esp) calll printf at PLT .loc 1 14 1 # a.c:14:1 addl $12, %esp popl %ebx popl %ebp ret .Ltmp10: .Ltmp11: .siz...

...x = 2, y = 3}. > > This is related to debug information generated, as normally the overloading is > occuring. > eg: A1 three = one + two results {x = 6, y = 8}. > > > On checking the assembly, a suspicious entry is found which may be related for > the failure: > > #DEBUG_VALUE: operator+:this <- undef > #DEBUG_VALUE: operator+:second <- undef > > > > -- > Thanx & Regards > *Mayur Pandey * > > > > > > -- Thanx & Regards *Mayur Pandey * -------------- next part -------------- An HTML attachment was scrubbed... URL...

On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with

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. Thanks, Sejong From: jdevlieghere at apple.com <jdevlieghere at apple.com> Sent: Wednesday, March 14, 2018 4:07 AM To: Se Jong Oh...

...= 6, y = 8}, but the result obtained is $1 = {x = 2, y = 3}. This is related to debug information generated, as normally the overloading is occuring. eg: A1 three = one + two results {x = 6, y = 8}. On checking the assembly, a suspicious entry is found which may be related for the failure: #DEBUG_VALUE: operator+:this <- undef #DEBUG_VALUE: operator+:second <- undef -- Thanx & Regards Mayur Pandey -- Thanx & Regards Mayur Pandey

> 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 you plan on creating a patch for this upstream? > > Thanks, > Sejong > > From: jdevlieghere at...

...Ltmp29 we call bad_ioapic_register() and then when returns zero (it > does) we je to .LBB0_10 aka .Ltmp34. At which point we happily stomp on > the value of 12(%esp) by spilling something *else* over it: > > .LBB0_10: # %if.end28 > .Ltmp34: > #DEBUG_VALUE: mp_register_ioapic:address <- $esi > #DEBUG_VALUE: mp_register_ioapic:cfg <- [DW_OP_plus_uconst 8] > [$ebp+0] > .loc 2 0 1 is_stmt 0 # arch/x86/kernel/apic/io_apic_ > b.c:0:1 > movl %ebx, 12(%esp) # 4-byte Spill > movl...

...18 at gmail.com Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred > 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 you plan on creating a patch for this upstream? > > Thanks, > Sejong > > From: jdevlieghere at...

Hi, we at Arm have noticed that assembly can differ when compiling for AArch64 depending on whether debug information is generated or not. The issue is reproducible for the following small example compiled with `-O1` for `aarch64-arm-linux-gnu`: a() { b(a); for (;;) c("", b); } The reason for the difference is that AArch64 frame lowering emits CFI