This is an archive of the discontinued LLVM Phabricator instance.

Don't add DBG_VALUE instructions for static allocas in dbg.declare
ClosedPublic

Authored by rnk on May 5 2017, 12:57 PM.

Details

Summary

An llvm.dbg.declare of a static alloca is always added to the
MachineFunction dbg variable map, so these values are entirely
redundant. They survive all the way through codegen to be ignored by
DWARF emission.

Effectively revert r113967

Two bugpoint-reduced test cases from 2012 broke as a result of this
change. Despite my best efforts, I haven't been able to rewrite the test
case using dbg.value. I'm not too concerned about the lost coverage
because these were reduced from the test-suite, which we still run.

Event Timeline

rnk created this revision.May 5 2017, 12:57 PM
aprantl edited edge metadata.May 5 2017, 2:33 PM

An llvm.dbg.declare of a static alloca is always added to the
MachineFunction dbg variable map, so these values are entirely
redundant.

Makes sense so far.

They survive all the way through codegen to be ignored by DWARF emission.

Why are they ignored? Shouldn't they turn the variable location into a location list that has the FI from the MMI side table *and* the DEBUG_VALUE?

rnk added a comment.May 5 2017, 3:12 PM

They survive all the way through codegen to be ignored by DWARF emission.

Why are they ignored? Shouldn't they turn the variable location into a location list that has the FI from the MMI side table *and* the DEBUG_VALUE?

It doesn't really make sense to build a location list for a variable that lives in a static alloca described with dbg.declare. There's only ever one location in memory where the variable lives. Extra instructions describing the location are kind of superfluous.

The commit message for rL113967 actually acknowledges that this code shouldn't do anything. I think it's just that whatever Devang wanted to do with this code never came to pass: "Right now, this has no material impact because varible info also collected using offset table maintained in machine module info."

I totally understand that it doesn't need to be tracked in the MMI table and in a DEBUG_VALUE, my question was that it sounded to my like you implied that the DWARF backend actively ignores DEBUG_VALUEs pointing to static allocas which I found really surprising (as there are legitimate reasons for allocas to be described by a DEBUG_VALUE) .

For example:

void f(int i) {
  int x = i;
   if (x == 0)
     // DEBUG_VALUE x, const 0
     return bar();
   // DEBUG_VALUE x, FI-1
   baz(&x);
}
aprantl accepted this revision.May 5 2017, 4:01 PM

This does not really have anything to do with the code in this patch though. I just really want to understand it.

This revision is now accepted and ready to land.May 5 2017, 4:01 PM
rnk added a comment.May 8 2017, 8:57 AM

I totally understand that it doesn't need to be tracked in the MMI table and in a DEBUG_VALUE, my question was that it sounded to my like you implied that the DWARF backend actively ignores DEBUG_VALUEs pointing to static allocas which I found really surprising (as there are legitimate reasons for allocas to be described by a DEBUG_VALUE) .

The backend doesn't ignore DEBUG_VALUEs pointing to static allocas, it ignores DEBUG_VALUEs when there is an entry for the same variable in the dbg.declare side table. It's this code:

void DwarfDebug::collectVariableInfo(DwarfCompileUnit &TheCU,
                                     const DISubprogram *SP,
                                     DenseSet<InlinedVariable> &Processed) {
  // Grab the variable info that was squirreled away in the MMI side-table.
  collectVariableInfoFromMFTable(Processed);

  for (const auto &I : DbgValues) {
    InlinedVariable IV = I.first;
    if (Processed.count(IV))
      continue;

Interesting, right!

  • adrian
This revision was automatically updated to reflect the committed changes.
llvm/test/CodeGen/X86/2012-11-30-misched-dbg.ll