search for: lowerdbgdeclare

Hi All,   Due to 'LowerDbgDeclare' call ( as part of 'instruction combining' optimization), a local variable gets declared and initialized inside the basic blocks it is used in. Is there anyway I can avoid this ?   This is with reference with my previous question. http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/...

...kaj   ________________________________ From: Eric Christopher <echristo at gmail.com> To: Pankaj Gode <godepankaj at yahoo.com>; Adrian Prantl <aprantl at apple.com> Cc: llvm Developers <llvmdev at cs.uiuc.edu> Sent: Monday, April 29, 2013 12:24 PM Subject: Re: [LLVMdev] LowerDbgDeclare results in redeclaration of local variable There was a patch committed the other day that should, at least, work around some of the behavior you describe. Optimized debug info is an area that's being worked on in ToT and previous releases are particularly bad. I'd use that. -eric On Mon...

...rk around some of the behavior you describe. Optimized debug info is an area that's being worked on in ToT and previous releases are particularly bad. I'd use that. -eric On Mon, Apr 29, 2013 at 7:02 AM, Pankaj Gode <godepankaj at yahoo.com> wrote: > Hi All, > > Due to 'LowerDbgDeclare' call ( as part of 'instruction combining' > optimization), a local variable gets declared and initialized inside the > basic blocks it is used in. > Is there anyway I can avoid this ? > > This is with reference with my previous question. > http://lists.cs.uiuc.edu/pip...

...d_sn && dv_sn){ r = -r;}   else if (d_sn) { d = -d; r = -r; }   else if (dv_sn) { d = -d; };     if (rm) { *rm = (signed int)r; }   return (signed int)d; } My observations for the generated .ll are (I am using llvm3.1): 1. Due to 'instruction combining' optimization which does 'LowerDbgDeclare' call, I get a lot of 'llvm.dbg.value' instruction for r inserted, which converts 'load with llvm.dbg.declare' to addition of llvm.dbg.value.  Is it ok to get such a behavior or I am wrong in my analysis? Please correct me.   2. I referred a link below, which talks of a patch pr...

...ariable. I think the JumpThreading pass should lower all llvm.dbg.declare() into llvm.dbg.value() the same way as the instcombine pass do (see InstructionCombining.cpp): // Lower dbg.declare intrinsics otherwise their value may be clobbered // by instcombiner. bool DbgDeclaresChanged = LowerDbgDeclare(F); Do you agree? Ok to commit? Regards / Karl-Johan Karlsson

...!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new stack. After that, llvm presumably runs LowerDbgDeclare (usually via InstCombine), but all the inserted dbg.values have useful locations relative to the new stack. It could be worth investigating whether replaceDbgDeclare is a good fit for the coro-split pass. vedant > On Feb 26, 2020, at 1:32 PM, Brian Gesiak via llvm-dev <llvm-dev at lists.ll...

...!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new stack. After that, llvm presumably runs LowerDbgDeclare (usually via InstCombine), but all the inserted dbg.values have useful locations relative to the new stack. > > > > It could be worth investigating whether replaceDbgDeclare is a good fit for the coro-split pass. > > > > vedant > > > > On Feb 26, 2020, at 1:32 PM...

...irst place ? The documentation describes our intention and reality often lags behind. I think that we should fix the code to convert the dbg.declare into a dbg.value (or dbg.addr?) that points into the alloca as well. I'm guessing that it will not be easy to do this (we can call Local.cpp's LowerDbgDeclare functionality beforehand, but that may actually make SROA's job harder because it needs to find and update more values that may be difficult to associate in reverse...), but having the verifier should help in the process. -- adrian > > Adding this to the Verifier sounds like a good idea...

Hi Brian, On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak <modocache at gmail.com> wrote: > In other words, the value of %i is stored on the frame object, on the > heap, at an offset of 7 into the frame. I'm beginning to think a > fundamental fix for this issue would be to stop replacing > llvm.dbg.declare with llvm.dbg.value, and instead replace the > llvm.dbg.declare with

...ca with the corresponding local variable for the alloca. This allows passes that delete stores other than mem2reg (DSE, Instcombine, GVN, anything using MemorySSA) to not worry about producing dbg.values because they already exist: the frontend has provided them. This was the fundamental reason why lowerDbgDeclare is called in Instcombine, so we can remove that, keep the dbg.declare instructions or something equivalent, and greatly expand the range over which the variable is known to live in stack memory. Variables which never participate in dead store elimination (hopefully many) are more likely to be entir...

...[r312970](http://reviews.llvm.org/rL312970). * LoopAcessAnalysis gained support for generating run-time alias checks in more cases. [r313012](http://reviews.llvm.org/rL313012). * The BPF backend now has an ASMParser. [r313055](http://reviews.llvm.org/rL313055). * A new flag was added to disable LowerDbgDeclare. This improved optimized debug info for address-taken variables, but may reduce accuracy of debug info in some cases. This is a temporary measure until a more long-term resolution can be implemented. [r313108](http://reviews.llvm.org/rL313108). ## Clang commits * An initial version of the clang-...

> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > My understanding is that this isn't correct: dbg.declare specifies the >> memory address of a variable for the whole lifetime of the function, >> whereas dbg.value (and dbg.addr) specify the value/address until the >> next debug intrinsic. Mixing these two kinds

Apologies for the slow response here Jeremy. Your reply has been incredibly helpful so far, I just need to try adding 'llvm.dbg.addr' myself to confirm that works. Thank you! - Brian Gesiak On Thu, Feb 6, 2020 at 11:04 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > Hi Brian, > > Thanks for working on coroutines, the debugging experience, and in > particular

...The DBG_VALUE MachineInstr actually already has a way to indicate that the computed value is an address, so I can accept that the backend design is logically consistent with some bugs. The middle-end, though, needs a new design for optimized debug info for variables that live in memory. Right now LowerDbgDeclare creates dbg.value instructions that use the *address* of a variable, rather than its value, when it encounters a call that directly uses the variable's alloca. This is inconsistent, and we need a way to say "address" not "value". I would like whatever we do between the back...

On Wed, Sep 6, 2017 at 5:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Sep 6, 2017 at 2:01 PM Reid Kleckner <rnk at google.com> wrote: > >> On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I guess you described this already, but talking it through for >>> myself/maybe others will