This is an archive of the discontinued LLVM Phabricator instance.

[LoopDeletion] Update debug values after loop deletion.
ClosedPublic

Authored by davide on Dec 4 2018, 2:58 PM.

Details

Summary

When loops are deleted, we don't keep track of variables modified inside the loops, so the DI will contain the wrong value for these.

e.g.

int b() {

int i;
for (i = 0; i < 2; i++)
  ;
patatino();
return a;

-> 6 patatino();

7   	  return a;
8   	}
9   	int main() { b(); }

(lldb) frame var i
(int) i = 0

We mark instead these values as unavailable inserting a @llvm.dbg.value(undef to make sure we don't end up printing an incorrect value in the debugger. We could consider doing something fancier, for, e.g. constants, in the future.

PR39868.
rdar://problem/46418795

Diff Detail

Repository
rL LLVM

Event Timeline

davide created this revision.Dec 4 2018, 2:58 PM
davide updated this revision to Diff 176719.Dec 4 2018, 2:59 PM

patch with context.

This looks like the right & safe thing to do.

llvm/lib/Transforms/Utils/LoopUtils.cpp
372 ↗(On Diff #176719)

I'd add:
// Since debug values in the loop have been deleted, inserting an undef dbg.value truncates the range of any dbg.value before the loop where the loop used to be. This is particularly important for constant values.

llvm/test/Transforms/LoopDeletion/diundef.ll
24 ↗(On Diff #176719)

we probably can strip all the TBAA info

38 ↗(On Diff #176719)

we can probably remove most of these attributes

64 ↗(On Diff #176719)

we can probably simplify the metadata by removing the column info

davide marked 3 inline comments as done.Dec 4 2018, 3:34 PM
davide added inline comments.
llvm/lib/Transforms/Utils/LoopUtils.cpp
376 ↗(On Diff #176719)

Here I wasn't sure whether substituting with void undef was correct (or if it mattered at all).

388–392 ↗(On Diff #176719)

Aside, I saw we only remove the loop if we have LoopInfo available. Shouldn't we do that unconditionally?

llvm/test/Transforms/LoopDeletion/diundef.ll
64 ↗(On Diff #176719)

I'll do the other twos, but this makes me a little nervous. It also doesn't really simplify that much, so I don't think it's really worth diverging.

davide updated this revision to Diff 176724.Dec 4 2018, 3:37 PM

Updated to address Adrian's comments.

aprantl added inline comments.Dec 4 2018, 3:55 PM
llvm/test/Transforms/LoopDeletion/diundef.ll
21 ↗(On Diff #176724)

Can you add a second CHECK(-NEXT) to make sure that this dbg.value is actually in the location we think it is (i.e., after the branch)?

aprantl added inline comments.Dec 4 2018, 3:58 PM
llvm/test/Transforms/LoopDeletion/diundef.ll
20 ↗(On Diff #176724)

And add:
// Test that after deleting the loop, the initializer value doesn't suddenly extend beyond the loop.

jmorse added a comment.EditedDec 5 2018, 5:37 AM

Looks good; one observation is that if we have N dbg.value's of a variable in the loop, we'll end up with N dbg.value(undef)'s of that variable in the exit block. Ideally we'd only emit one per variable.

[edited for clarity]

davide added a comment.Dec 5 2018, 5:52 PM

I'll switch this to be a DenseMap.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 12 2018, 3:38 PM
This revision was automatically updated to reflect the committed changes.
aprantl added inline comments.Dec 12 2018, 4:35 PM
llvm/trunk/lib/Transforms/Utils/LoopUtils.cpp
574

I suppose this could be just a set instead of a map now?