This is an archive of the discontinued LLVM Phabricator instance.

Refactor: Simplify boolean conditional return statements in llvm/lib/CodeGen/SelectionDAG
AbandonedPublic

Authored by LegalizeAdulthood on May 24 2015, 11:50 PM.

Details

Summary

Use clang-tidy to simplify boolean conditional return statements

Diff Detail

Event Timeline

LegalizeAdulthood retitled this revision from to Refactor: Simplify boolean conditional return statements in llvm/lib/CodeGen/SelectionDAG.
LegalizeAdulthood updated this object.
LegalizeAdulthood edited the test plan for this revision. (Show Details)
LegalizeAdulthood added a subscriber: Unknown Object (MLST).
craig.topper added inline comments.
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
9806–9807

Push the negate through and use an OR

9910

Use ==

lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
2317

Push the negate through

lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2701–2702

Push the negate through

lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
1364–1365

Push the negate through

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
9806–9807

Fixed.

9910

Fixed.

What's interesting here is that the tool already pushes through !(e1 != e2) to e1 == e2 when it is a simple == comparison. So I dug into this one to find out why it hadn't done that and it's because this is an operator== applied to an abstract data type. Because it is possible that operator!= has been overridden, but operator== has not been overridden, I didn't want to make the tool blindly push through on this kind of change. I'll need to figure out how to determine if operator== has been appropriately overridden before pushing through the simplification safely.

lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
2317

Fixed.

What's a good guideline for the tool here?

I was thinking that it should apply DeMorgan's Theorem for the cases !(!e1 && !e2 && ... && !en) and !(!e1 || !e2 || ... || !en). In that situation it seems like a "no brainer" because it's the classic double negative on every term in the expression.

Here though, we have one of the inner terms negated and one not negated, so there's no clear simplification.

Is it always desirable to push through the outer negate whenever any of the inner terms also has a negation? I can see this being a matter of preference and therefore perhaps tweakable through a configuration option for the tool.

lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2701–2702

Fixed.

lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
1364–1365

Fixed.

Update from comments, run clang-format on changes

filcab added inline comments.Jul 25 2015, 12:57 PM
lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
2338

Would something like

return (int)SPQ->getCurCycle() < Height ||
       SPQ->getHazardRec()->getHazardType(SU, 0) !=
           ScheduleHazardRecognizer::NoHazard;

Be more readable, here? There are only two conditions.

2573

Same comment as for BUHasStall

lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
2338

To be clear: I'm just running clang-tidy on the code and submitting the diffs. None of these changes were created by hand.

LegalizeAdulthood abandoned this revision.Feb 19 2016, 9:23 AM