This is an archive of the discontinued LLVM Phabricator instance.

[Local] Do not move around dbg.declares during replaceDbgDeclare
ClosedPublic

Authored by vsk on Feb 12 2020, 4:56 PM.

Details

Summary

replaceDbgDeclare is used to update the descriptions of stack variables
when they are moved (e.g. by ASan or SafeStack). A side effect of
replaceDbgDeclare is that it moves dbg.declares around in the
instruction stream (typically by hoisting them into the entry block).
This behavior was introduced in llvm/r227544 to fix an assertion failure
(llvm.org/PR22386), but no longer appears to be necessary.

Hoisting a dbg.declare generally does not create problems. Usually,
dbg.declare either describes an argument or an alloca in the entry
block, and backends have special handling to emit locations for these.
In optimized builds, LowerDbgDeclare places dbg.values in the right
spots regardless of where the dbg.declare is. And no one uses
replaceDbgDeclare to handle things like VLAs.

However, there doesn't seem to be a positive case for moving
dbg.declares around anymore, and this reordering can get in the way of
understanding other bugs. I propose getting rid of it.

Testing: stage2 RelWithDebInfo sanitized build, check-llvm

rdar://59397340

Diff Detail

Event Timeline

vsk created this revision.Feb 12 2020, 4:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2020, 4:56 PM
Herald added a subscriber: hiraditya. · View Herald Transcript

I think the point of moving dbg.declare was to make sure it is dominated by the new expression. Ex. in ASan we place it immediately after the base pointer definition.
If you are sure this condition holds in all call sites, then LGTM.

aprantl accepted this revision.Feb 13 2020, 10:07 AM

This looks reasonable with @eugenis caveat taken care of.

This revision is now accepted and ready to land.Feb 13 2020, 10:07 AM
vsk added a comment.Feb 13 2020, 10:57 AM

I think the point of moving dbg.declare was to make sure it is dominated by the new expression. Ex. in ASan we place it immediately after the base pointer definition.
If you are sure this condition holds in all call sites, then LGTM.

@eugenis IIUC, post-ASan, each dbg.declare(<alloca>) should be dominated by <alloca>, even if none of the dbg.declares are hoisted. I added the following assert to test this while building a stage2 llc:

   // Replace Alloca instructions with base+offset.
+  DominatorTree DT(F);
   for (const auto &Desc : SVD) {
     AllocaInst *AI = Desc.AI;
+    assert(DT.dominates(cast<Instruction>(LocalStackBaseAllocaPtr), AI));
     replaceDbgDeclare(AI, LocalStackBaseAllocaPtr, DIB, DIExprFlags,
                       Desc.Offset);

If the input IR has no debug use-before-def, the post-ASan IR should look good as well, because ASan either does not move AI or it hoists it (from StaticAllocasToMoveUp). Does that answer your question?

eugenis accepted this revision.Feb 13 2020, 1:10 PM

OK, sounds good.

This revision was automatically updated to reflect the committed changes.