This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking Analysis][2/*] Remove redundant location definitions
ClosedPublic

Authored by Orlando on Oct 20 2022, 1:34 AM.

Details

Summary

Implement the removeRedundantDbgInstrs cleanup from lib/Transforms/Utils/BasicBlockUtils.cpp for FunctionVarLocBuilder's variable location definitions.

Removing redundant entries has the obvious benefits of reducing peak memory when using the results of the analysis and reducing the final number of MIR debug instructions.

It also has a less obvious benefit. This patch is not an NFC change because SelectionDAG has a habit of doing Bad Things with variable locations - removing the number of location definitions tends to reduce the number of Bad Things.

Two examples I have seen:

  1. Argument SDDbgValues hoisted above undef `SDDbgValues.
  2. undef SDDbgValues in a block of contiguous SDDbgValues spuriously changing order.

Tests coming in a later patch.

Diff Detail

Event Timeline

Orlando created this revision.Oct 20 2022, 1:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 1:34 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
Orlando requested review of this revision.Oct 20 2022, 1:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 1:34 AM
StephenTozer accepted this revision.Nov 2 2022, 8:20 AM
StephenTozer added a subscriber: StephenTozer.

Minor comments, otherwise LGTM.

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1501

YMMV so just a suggestion, but could the entry block stuff be moved into a separate function? As-is there's a DenseMap in this function, which is reasonably large even when unused (and possibly can't be optimized out by the compiler since it's dependent on the return value of BB->isEntryBlock()?), and in terms of behaviour it seems like two fairly distinct behaviours bundled into one function. I can also see how it may make sense to have them together in a single forward-scanning function though, so your call on whether to split it or not.

1547
This revision is now accepted and ready to land.Nov 2 2022, 8:20 AM
jmorse accepted this revision.Nov 22 2022, 4:30 AM
jmorse added a subscriber: jmorse.

This is all fine and well; are redundant variable locations a common case and which should we optimise for? IIUC every instruction with debug-info results in a SmallVector copy right now, which isn't necessary if that specific position hasn't had debug-info change. IMO, adding a "ChangedPosition" flag that's used to skip setWedge if it isn't true would be beneficial.

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1469

Ideally Key would be a reference to avoid any un-necessary copying, I think doing that hinges on feedback in the parent patch.

1514

One extra malloc per block seems like quite a bit, use SmallDenseMap?

Orlando updated this revision to Diff 477462.Nov 23 2022, 4:46 AM
Orlando marked 4 inline comments as done.

Factored out removeUndefDbgLocsFromEntryBlock and addressed other comments.

Orlando added a comment.EditedNov 23 2022, 4:46 AM

This is all fine and well; are redundant variable locations a common case and which should we optimise for? IIUC every instruction with debug-info results in a SmallVector copy right now, which isn't necessary if that specific position hasn't had debug-info change. IMO, adding a "ChangedPosition" flag that's used to skip setWedge if it isn't true would be beneficial.

In the previous patch I changed setWedge to take an r-value reference. I don't have a good feeling as to whether grow, move, reset in a loop (growing from the start each time) is more or less performant than grow, copy, clear (which is something we could do instead by moving the vector out of the loops). I tried profiling this but on my test case the difference is lost in the noise. I've gone with the grow, move, reset version for now to avoid adding a setWedge overload but this can always be changed if we find a pathological case. I've added some statistics so we can get a better feel for this "in the wild" and adjust later. The anecdotal results I got for a compiling a single file were about 1% of wedges get modified, which may support the case for grow, copy, clear.