We don't have any vXi8 shift instructions (other than on XOP which is handled separately), so replace the shl(x,1) ->add(x,x) fold with shl(x,1) ->add(freeze(x),freeze(x)) to avoid the undef issues identified in PR50468.
Sorry, I don't quite understand the background. My question is why don't we check the oprand is a undef?
It’s not enough to check for undef at the time of the fold. You need to know that no future DAGCombine can make the input undef.
(shl X, 1) must produce an even number even if X is undef. computeKnownBits will look at the shift amount and tell downstream code that the lsb is 0 without looking at the left hand side. And the value may not be undef at the time computeKnownBits is called but could be simplified to undef later.
(add undef, undef) does not produce an even number. Register allocation is free to pick different registers for undef.
The freeze forces register allocation to use the same register.
Undef reasoning is complicated, and the explanation here is great. How about enshrining it as a code comment? :)
// R may be undef at run-time, but (shl R, 1) must be an even number (LSB must be 0). // (add undef, undef) however can be any value. To make this safe, we must freeze R // to ensure that register allocation uses the same register for an undefined value. // This ensures that the result will still be even and preserves the original semantics.