search for: replacedbgdeclareforalloca

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 of differ...

.... 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 passes... Th...

...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 and the as...

> 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.

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

...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 and...

...Int::get(Int32Ty, -StaticOffset)); + Value *NewAI = IRB.CreateBitCast(Off, AI->getType(), AI->getName()); + if (AI->hasName() && isa<Instruction>(NewAI)) + cast<Instruction>(NewAI)->takeName(AI); + + // Replace alloc with the new location + replaceDbgDeclareForAlloca(AI, NewAI, DIB); + AI->replaceAllUsesWith(NewAI); + AI->eraseFromParent(); + } + + // Re-align BasePointer so that our callees would see it aligned as expected + // FIXME: no need to update BasePointer in leaf functions + StaticOffset = (StaticOffset + StackAlignment - 1...