No functionality change.
Details
Diff Detail
Event Timeline
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. |
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. |
Use plain function instead of a stateless class.
lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h | ||
---|---|---|
26 | Done. |
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<...>())); 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. |
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 :) |
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?" |
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. |
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. |
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. |
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).