As discussed in D52304 / IRC, we now have pattern matching for
'bit extract' in two places - tablegen and X86DAGToDAGISel.
There are 4 patterns.
And we will have a problem with x & (-1 >> (32 - y)) pattern.
- If the mask is one-use, then it is always unfolded into x << (32 - y) >> (32 - y) first. Thus, the existing test coverage is already broken.
- If it is not one-use, then it is not unfolded, and is matched as BZHI.
- If it is not one-use, we will not match it as BEXTR. And if it is one-use, it will have been unfolded already.
So we will either not handle that pattern for BEXTR, or not have test coverage for it.
This is bad.
As discussed with @craig.topper, let's unify this matching, and do everything in X86DAGToDAGISel.
Then we will not have code duplication, and will have proper test coverage.
This indeed does not affect any tests, and this is great.
It means that for these two patterns, the X86DAGToDAGISel is identical to the tablegen version.
Please review carefully, i'm not fully sure about that intrinsic change, and introduction of the new X86ISD opcode.
return CanHaveExtraUses || Op.hasOneUse();