This is an archive of the discontinued LLVM Phabricator instance.

Move logic for calculating DBG_VALUE history map into separate file/class.
ClosedPublic

Authored by samsonov on Apr 30 2014, 10:48 AM.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 8984.Apr 30 2014, 10:48 AM
samsonov updated this revision to Diff 8985.
samsonov retitled this revision from to Move logic for calculating DBG_VALUE history map into separate file/class..
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).

Remove accidentally commited temp files.

dblaikie edited edge metadata.Apr 30 2014, 11:16 AM

Any particular motivation for this change? Is it a precursor to other work?

But yeah, putting this rather monolithic complexity in its own space is probably not a bad idea, I'd just like to understand the motivation/design a bit better.

lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h
26

Immediate gut reaction is that this object has no state (presumably it doesn't mutate the MachineFunction or the TargetRegisterInfo - it just uses those to perform some computation) so it should be a free function.

Arguably it could still be in its own source file - it's certainly a lot of code - but I have an aversion to classes that are just containers for functions (we have namespaces for that).

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1449–1450

Unneeded braces on single-statement block. But I know some people prefer an "all or nothing" brace approach (if the 'if' has braces, then put braces on the 'else' too) - so that's up to you.

I like that it makes quite a bit of the code in DwarfDebug.cpp more compact, but it mostly just moves the complexity to another file. Is there a reason for the move or is it just an attempt at some nice cleanup? i.e. motivation?

Sorry for the lack of context.

I'm preparing the ground for reviving http://reviews.llvm.org/D2658, which attempts to heavily refactor history calculation. It's probably a good idea to factor this logic out of beginFunction() anyway, as it doesn't require any knowledge of DwarfDebug contents.

lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h
26

For now, when the class doesn't yet have a state, I can turn certainly turn it into a function for simplicity.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1449–1450

I'd prefer to leave braces here - else-block occupies multiple lines, has a comment etc.

dblaikie added inline comments.Apr 30 2014, 11:46 AM
lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h
26

Yep - if you could just make this a function for now, that'd be great.

It helps me to see the different design requirements motivating design changes rather than having a design that, itself, lacks the justification/requirements.

samsonov updated this revision to Diff 8990.Apr 30 2014, 1:38 PM
samsonov edited edge metadata.

Use plain function instead of a stateless class.

lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h
26

Done.

dblaikie added inline comments.Apr 30 2014, 1:54 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1445–1447

This seems like a slightly strange block.

Could you explain what the distinction between a variable not being in the DbgValues map, and it being in the map, but empty?

Also - "DbgValues[Var].clear()" is a little unclear - since the 'clear()' is actually not used - the condition above shows that the map didn't have the key until this point, so when it's created by op[] it should be empty anyway.

If this is the right semantic (see first question in this comment) I'd probably write it as:

auto IterBool = DbgValues.insert(std::make_pair(Var, SmallVector<...>()));
if (IterPair.second)

UserVariables.push_back(Var);

(I wouldn't even mind rolling it into the if:

if (DbgValues.insert(std::make_pair(Var, SmallVector<...>())).second)

UserVariables.push_back(Var);

)

Could add a comment // ensure the Var is in the DbgValues map (using some more domain-specific wording, I haven't stared at this code long enough to understand why it needs to be in the map or what that means, etc)

1452

This could just be "else if", but might be better as a separate commit to keep this blame simple. (and it is simple - thank you for that, it's very easy to follow that the code has just been moved)

1468–1474

I'd probably remove this local and just write: "DIVariable DV(I.first)"

1474

I'd probably write History.front() (rather than History[0]), but reasonable people may disagree - just a thought.

echristo added inline comments.Apr 30 2014, 1:59 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1474

No objections, not necessarily for it either, but I like to think I'm reasonable and I don't disagree :)

samsonov updated this revision to Diff 8992.Apr 30 2014, 2:13 PM

Address comments by David.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1445–1447

Done.

1452

Sure, will do in a follow-up commit.

1468–1474

Done.

1474

Done.

dblaikie added inline comments.Apr 30 2014, 2:15 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1445–1447

Sorry, perhaps it got lost in the length of my original comment, but I still don't fully understand the need for this code. Could you explain it to me?

To quote my original comment:

"Could you explain what the distinction between a variable not being in the DbgValues map, and it being in the map, but empty?"

samsonov added inline comments.Apr 30 2014, 2:22 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1443

See the updated // comment here. We need to store both DbgValues map (MDNode->History) and a set of MDNodes in UserVariables in the order of appearance. There's no difference in missing MDNode and MDNode with an empty history, but we use the latter for constructing UserVariables (it will be constructed later anyway).

We could either fix a DbgValues map to ensure the order on keys, or introduce a temporary map we would use when constructing UserVariables here, or leave the code as is - I have no strong opinion about it.

dblaikie accepted this revision.Apr 30 2014, 2:31 PM
dblaikie edited edge metadata.

Thanks for your patience, Alexey.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1443

Oh, sorry I missed the comment. Thanks for the details.

OK, that's a pity, though not your fault/relevant to this patch. (I may've perpetrated this oddity to address weird parameter reordering shenanigans - I'm not sure)

As a follow-up patch it'd be good to change DbgValues to a MapVector. Then we wouldn't have to pay the cost of lookup in collectVariableInfo where we loop over the UserVariables then look them up in DbgValues - we could just iterate directly.

And this code would become a little less weird - though it'd still need the comment about insertion order being important.

This revision is now accepted and ready to land.Apr 30 2014, 2:31 PM

Thanks for the review!

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1443

Yep, I like the idea of using MapVector here. Will do in a following changes.

samsonov closed this revision.Apr 30 2014, 2:41 PM