This might be the start of tracking all vector element constants generally if we take it to its logical conclusion, but I thought I'd better stop here and see if there's support for the general direction.
The affected tests require a convoluted path before they get simplified currently because we don't call SimplifyDemandedVectorElts() from binops directly and don't modify the binop operands directly in SimplifyDemandedVectorElts().
That's why the tests all have a trailing shuffle to induce a chain reaction of transforms. So something like this is happening:
- Improve the knowledge of undefs in the binop via a SimplifyDemandedVectorElts() call that originates from a shuffle.
- Transfer that undef knowledge back to the shuffle mask user as more undef lanes.
- Combine the modified shuffle by calling SimplifyDemandedVectorElts() again.
- Translate the improved shuffle mask as undemanded lanes of build vector constants causing those to become full undef constants.
- Simplify the binop now that it has a full undef operand.
As we can see from the unchanged 'and' and 'or' tests, tracking undefs alone isn't a full solution. We would need to track zero and all-ones constants to improve those opcodes. We'd probably need to track NaN for FP ops too (assuming we don't have fast-math-flags set).
What's the policy on creating nodes on the fly like this?