[PATCH] D106053: [CodeGen] Remove pending AssertZext AssertSext in promoting FP_TO_INT

[Eli Friedman via Phabricator via llvm-commits]

efriedma added reviewers: nlopes, aqjune, nikic.
efriedma added a comment.

If I'm understanding correctly, the testcase reduces to something like this:

  define <16 x i8> @src(<4 x float> %arg1) {
    %f = fptoui <4 x float> %arg1 to <4 x i8>
    %s = shufflevector <4 x i8> %f, <4 x i8> undef, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
    %ss = shufflevector <16 x i8> %s, <16 x i8> zeroinitializer, <16 x i32> <i32 0, i32 17, i32 18, i32 19, i32 1, i32 21, i32 22, i32 23, i32 2, i32 25, i32 26, i32 27, i32 3, i32 29, i32 30, i32 31>
    ret <16 x i8> %ss
  }
  
  define <16 x i8> @tgt(<4 x float> %arg1) {
    %f = fptosi <4 x float> %arg1 to <4 x i32>
    %ss = bitcast <4 x i32> %f to <16 x i8>
    ret <16 x i8> %ss
  }

llc compiles both of these to a single cvttps2dq; alive2 says these are not equivalent.  So apparently there's some disagreement within SelectionDAG about what AssertZext actually means.

I'd consider this a bug in the x86 shuffle code. Changing fptoui legalization would basically imply that poison doesn't exist in SelectionDAG, which is not the direction we want to go, I think.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106053/new/

https://reviews.llvm.org/D106053