canWidenShuffleElements can do a better job if given a mask with ZeroableElements info. Apparently, ZeroableElements was being only used to identify AllZero candidates, but possibly we could plug it into more shuffle matchers.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 16869 Build 16869: arc lint + arc unit
Event Timeline
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
14851 | ISD::isBuildVectorAllZeros allows undef elements (as long as it isn't all undefs) - should we test for a splat build vector of zero and check that we have no undefs at all? |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
14851 | What would be the benefit of that? I mean, undefs can be zeroed if profitable. |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
14891 | Are there any cases where the zero entry came from V1 that could cause a problem? | |
14915 | APInt Undefs = APInt::getAllOnesValue(NewNumElts); | |
14917 | APInt::getNullValue(NewEltVT.getSizeInBits()) | |
14920 | i > NewNumElts can't ever be true? And anyway, we expect the zero to have come from V2. |
- Rebase
- Simplify the creation of the shuffle by only modifying the widened mask to take all zeros from the all-zero operand.
ISD::isBuildVectorAllZeros allows undef elements (as long as it isn't all undefs) - should we test for a splat build vector of zero and check that we have no undefs at all?