This is an archive of the discontinued LLVM Phabricator instance.

Change representation of instruction ranges where variable is accessible.
ClosedPublic

Authored by samsonov on May 21 2014, 2:44 PM.

Details

Reviewers
dblaikie
Summary

Use more straightforward way to represent the set of instruction
ranges where the location of a user variable is defined - vector of pairs
of instructions (defining start/end of each range),
instead of a flattened vector of instructions where some instructions
are supposed to start the range, and the rest are supposed to "clobber" it.

Simplify the code which generates actual .debug_loc entries.

No functionality change.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 9665.May 21 2014, 2:44 PM
samsonov retitled this revision from to Change representation of instruction ranges where variable is accessible..
samsonov updated this object.
samsonov edited the test plan for this revision. (Show Details)
samsonov added a reviewer: dblaikie.
samsonov added a subscriber: Unknown Object (MLST).
samsonov updated this revision to Diff 9674.May 21 2014, 6:19 PM

Rebase to trunk (and test the email change).

dblaikie edited edge metadata.May 21 2014, 6:29 PM

Coming through loud & clear!

dblaikie added inline comments.May 21 2014, 6:47 PM
lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.cpp
117

Sorry, but I forget/don't understand why/how this code was no longer necessary.

Could you explain why it was necessary before your patch and how your patch makes it unnecessary?

Hmm, I think I see - it moved into startInstrRange, did it?

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1190

You can drop this initialization, since the 3 cases below ensure the variable is initialized (this way, msan can catch bugs if that is ever violated)

1191

This if/else if chain could be done without braces, if you like (seems to be the way of things in the LLVM codebase).

1380–1381

I'd probably drop the braces from all these - might be worth refactoring into a simple utility function to make this larger function more readable/simpler.

1389

Did the need for this ahead-of-time initialization of the MapVector go away in your change? How?

1398

I assume the case where the start of a range is non-null and the end of the range is null occurs for whole-function ranges? (we don't record the termination)

In that case, would it make sense to just record the location as an unbounded range (null for both start/end? No range? (I guess that'd be ambiguous with "variable is totally optimized away", though))

samsonov added inline comments.May 22 2014, 11:00 AM
lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.cpp
117

Not sure what logic you refer to. dropRegDescribedVar/addRegDescribedVar pair moved to calculateDbgValueHistory, so that now we have:

  • mark that the variable is no longer described by old register (if it has been).
  • start the new location range for a variable
  • mark that the variable is described by a new register (if necessary).
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1190

Done

1191

Done

1380–1381

Done (and moved this function call closer to the place where PrologEndLoc is used for the first time).

1389

Yes, it went away. Need for ahead-of-time initialization is somewhat ugly, this really should be responsibility of calculateDbgValueHistory().

calculateDbgValueHistory() traverses all machine instructions in function, and the first time we see a DBG_VALUE for a new variable, it will
be added to map by the call to "startInstrRange()".

1398

Not necessarily, see description of what a range is in DbgValueHistoryCalculator.h: if we have

DBG_VALUE %r1 %noreg !"v"
...
DBG_VALUE %r2 %noreg !"v"

the range for this first DBG_VALUE will not be explicitly terminated - we assume it's valid until the next range begins.

samsonov updated this revision to Diff 9711.May 22 2014, 11:00 AM
samsonov edited edge metadata.

Address comments.

Any more comments on this?

dblaikie accepted this revision.May 27 2014, 3:04 PM
dblaikie edited edge metadata.
dblaikie added inline comments.
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1389

Was there a reason this wasn't possible previously? (I seem to recall this was kept around in the previous commit to provide stability to the output? - why is the "on first use" order stable now?)

It might've been helpful to pull this out as a separate commit if it's an isolated piece of cleanup (if it's not isolated I wouldn't mind unedrstanding what is it about the rest of your change that changed things here so that this was no longer needed)

This revision is now accepted and ready to land.May 27 2014, 3:04 PM

Thanks for the review!

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1389

Good point, looks like it's possible with current code as well (apparently, it became possible as code evolved during the review).
I will put this into a separate commit.

samsonov closed this revision.May 27 2014, 4:17 PM

Landed as r209698.