When VectorLegalizer::LegalizeOp creates a new SDValue after iterating over its arguments, it will always select the result number 0 even if the SDValue originally referred to some other result of the node.
This apparently never caused any issues so far (maybe nodes involving vector types with multiple results are rare?), but now with strict floating-point nodes it appears much more frequently. I've noticed this in my own tests related to https://reviews.llvm.org/D45576, but it seems this is already visible with an in-tree test case that was recently checked in here: https://reviews.llvm.org/D48809
Looking at e.g. constrained_vector_fdiv_v4f64 in test/CodeGen/X86/vector-constrained-fp-intrinsics.ll, we get the following legalized DAG:
t0: ch = EntryToken t19: v2f64 = BUILD_VECTOR ConstantFP:f64<1.000000e+01>, ConstantFP:f64<1.000000e+01> t21: v2f64 = BUILD_VECTOR ConstantFP:f64<3.000000e+00>, ConstantFP:f64<4.000000e+00> t23: v2f64,ch = strict_fdiv t0, t21, t19 t20: v2f64 = BUILD_VECTOR ConstantFP:f64<1.000000e+00>, ConstantFP:f64<2.000000e+00> t22: v2f64,ch = strict_fdiv t0, t20, t19 t24: ch = TokenFactor t22, t23
This is incorrect; note how the TokenFactor in t24 refers to arguments that aren't even chain values. With this patch, we get instead the correct:
t24: ch = TokenFactor t22:1, t23:1