computeKnownBitsForTargetNode was not defined for Lanai which resulted in additional AND's with 0x1 for the output of SETCC instructions.
Details
Diff Detail
- Build Status
Buildable 6020 Build 6020: arc lint + arc unit
Event Timeline
Hmm, this is the sort of thing I'd expect SelectionDAG to "just do"... Do other backends achieve the same end by similar means?
I'd expect this logic to zap away such an AND: https://github.com/llvm-mirror/llvm/blob/fb21e4d6fc9ff15b231354be4068c3f732deee02/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L560
Yes, PPC does it in PPCTargetLowering::DAGCombineTruncBoolExt (https://github.com/llvm-mirror/llvm/blob/fb21e4d6fc9ff15b231354be4068c3f732deee02/lib/Target/PowerPC/PPCISelLowering.cpp#L9979) but in retrospect they were doing it as they have 2 different ways of setting conditional flags. For Lanai this was not needed.
I'd expect this logic to zap away such an AND: https://github.com/llvm-mirror/llvm/blob/fb21e4d6fc9ff15b231354be4068c3f732deee02/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L560
This was good suggestion: it let me to seeing that computeKnownBitsForTargetNode was not defined for Lanai and so this combination would not happen. So the resulting change is much simpler and covers more cases.