[llvm-dev] Jump Threading duplicates dbg.declare intrinsics for fragments, bug?

[Björn Steinbrink via llvm-dev]

Hi Mikael,

2017-09-19 15:33 GMT+02:00 Mikael Holmén <mikael.holmen at ericsson.com>:
> A similar fix as yours was made for duplicate non-fragment dbg.declares in
> r305244 and there is a bit of discussion about it in
> https://bugs.llvm.org//show_bug.cgi?id=33157
> Maybe you've seen that?

I saw the code, but not the bug report it originated from. Thanks!

My patch had the same idea of trying not to complicate other passes
to avoid duplicate declarations.

> I've run into a case where the inliner leaves two 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 assert in addFragmentOffset()
> blows. Who's at fault?

Sounds like the same issue just with a different pass triggering the problem.

> There is also an existing testcase that checks that there _are_ indeed two
> dbg.declares to a single alloca:
> Transforms/Inline/alloca-dbgdeclare-merge.ll

This is different. The test doesn't check for it, but the declarations actually
describe different vars in different scopes, so that is fine.

Cheers,
Björn