This adds infrastructure to support simplify demanded bits for target nodes and then uses it to support X86ISD::CMOV. This is step towards being able to promote 16-bit CMOVs to 32-bits.
Diff Detail
Event Timeline
A few comments but nice to see this being pursued - not sure if this will need breaking down into incremental changes at commit time.
Also, rather random question - why is SimplifyDemandedBits inside TargetLowering instead of in SelectionDAG with KnownBits/SignBits handling? Was the original intention for targets to override SimplifyDemandedBits directly?
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27268 | Do we have test cases for all of these? | |
27293 | bracket indentation? | |
27312 | Any easy way to remove this code duplication for Op0 and Op1? | |
27322 | For the other 'ForTargetNode' style calls we don't do a 'drop through' to the base class - should we match that approach here? |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27268 | My primary interest was in the constant simplification. It looks like we may not have any real tests for the two recursive calls. Maybe I'll remove those for now and add a fixme. | |
27322 | The default implementation was less trivial than the other 2 cases so I wasn't sure if we wanted to replicate that code. |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27322 | If you drop the early break after the SimplifyDemandedBitsForTargetNode call in TargetLowering::SimplifyDemandedBits then you should be able to remove this and the extra code in TargetLowering::SimplifyDemandedBitsForTargetNode? |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27322 | But doesn't that mean we'd effectively compute the known bits and do the recursion twice when it doesn't simplify? |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27322 | Does it? I thought it'd just mean that we go through computeKnownBits to rediscover that its a target node instead of directly to computeKnownBitsForTargetNode. |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
27322 | But SimplifyDemandedBitsForTarget node would have recursed and calculated known bits regardless of whether it returned true or false. If it returned false we already have the known its. If I remove the early break we'll throw that information away and recurse again through computeKnownBits right? |
Remove the recursive calls on the cmov operands. Stick to cmov with constant inputs for now.
I don't know that we really have the test coverage to justify this approach. I have a simpler cmov patch I'm going to post.
Do we have test cases for all of these?