Displaying 4 results from an estimated 4 matches for "dbgdeclare".
Did you mean:
dbg_declare
2016 May 29
1
How to find variable names from LLVM IR?
...)
name = V->getName();
else
{
const DILocalVariable* Var = NULL;
for (const_inst_iterator Iter = inst_begin(Func), End =
inst_end(Func); Iter != End; ++Iter)
{
if (const DbgDeclareInst* DbgDeclare =
dyn_cast<DbgDeclareInst>(&*Iter))
{
if (DbgDeclare->getAddress() == V) Var =
DbgDeclare->getVariable();
}
else if (const DbgValueInst* DbgValue =
dyn_cast<DbgValueInst>(&*It...
2017 Sep 19
0
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
...clares (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 a...
2017 Sep 19
3
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
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
2017 Sep 19
2
Jump Threading duplicates dbg.declare intrinsics for fragments, bug?
...s (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.dec...