search for: replacedbgdeclar

Vedant, Jeremy, Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some extremely quick and dirty changes I made (with no tests!), and a link to a Gist with the LLVM IR and DWARF produced, https://gist.github.com/modocache/6f29093ba2827946011b422ed3bd2903. There's onl...

I haven't fully parsed this thread (sorry!), 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...

...dbg.declares (with different locations since they origin from two different inlined call sites) connected to a single alloca after alloca-merging. Then the inliner moves (what it thinks is) the one and only dbg.declare to the alloca (and thus leaves the other one in a loop). The help methods replaceDbgDeclareForAlloca()/replaceDbgDeclare()/FindAllocaDbgDeclare() all seems to think there is only one dbg.declare connected to one alloca. At least they all ignore all except the first one found. Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares...

Hi, I'm hitting an assertion "overlapping or duplicate fragments" in the DWARF codegen in addFragmentOffset(). This originates from a duplicated dbg.declare intrinsic, declaring the same fragment twice. The duplicated call was generated by the jump threading pass. I have a patch (see below) that removes simply such duplicates, but I'm not sure whether that is the right

.... On 09/19/2017 05:44 PM, Reid Kleckner wrote: > I think it's a bug in both places: the backend should tolerate > identical, duplicate dbg.declares, and the loop unroller probably > shouldn't duplicate dbg.declare, since there is no point. I also think it's weird that the replaceDbgDeclareForAlloca/replaceDbgDeclare/FindAllocaDbgDeclare methods return as soon as they've handled one found dbg.declare, so if there are several, one is moved next to the alloca, but the other ones are left somewhere. So maybe a fault there too? These methods are used from a bunch of different pas...

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.

On Wed, Sep 20, 2017 at 1:43 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > I also think it's weird that the replaceDbgDeclareForAlloca/rep > laceDbgDeclare/FindAllocaDbgDeclare methods return as soon as they've > handled one found dbg.declare, so if there are several, one is moved next > to the alloca, but the other ones are left somewhere. So maybe a fault > there too? These methods are used from a bunch...

...declares (with different locations since they origin from two different inlined call sites) connected to a single alloca after alloca-merging. > > Then the inliner moves (what it thinks is) the one and only dbg.declare to the alloca (and thus leaves the other one in a loop). The help methods replaceDbgDeclareForAlloca()/replaceDbgDeclare()/FindAllocaDbgDeclare() all seems to think there is only one dbg.declare connected to one alloca. At least they all ignore all except the first one found. > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.de...

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