Adding AssertZext AssertSext in promoting FP_TO_INT is not safe.
for example:
t3: v8i8 = fp_to_uint t2 --promote to--> t4: v8i16 = fp_to_sint t2 + t5: v8i16 = AssertZext t86, ValueType:ch:i8
will let following optimization see the "high 8-bits of each element of t5" == 0. (but it is not, it may be undef, when there is overflow in fp_to_uint )
So some setting t5's "high 8-bits of each element" action will be optimized out.
And finally cause calculation error.
Related commit: https://reviews.llvm.org/D40591
Related optimization: https://reviews.llvm.org/rG2a419a0b9957ebac9e11e4b43bc9fbe42a9207df
tests in llvm/test/CodeGen/X86/tmp is just for discussion, I will remove it at last.
The codegen diff is awful - what happens if you replace this with a SIGN_EXTEND_INREG / ZERO_EXTEND_INREG (AND) pattern?