This pattern came up in PR36682 / D44390
https://bugs.llvm.org/show_bug.cgi?id=36682
https://reviews.llvm.org/D44390
https://godbolt.org/g/oKvT5H
Looking at the IR pattern in question, as per alive-nj, for all the type combinations i checked
(input: i16, i32, i64; intermediate: half/i16, float/i32, double/i64)
for the following icmp comparisons the uitofp+bitcast+icmp can be evaluated to a boolean:
- slt 0
- sgt -1
I did not check vectors, but i'm guessing it's the same there.
Thus all these cases are in the testcase (along with the vector variant with additional undef element in the middle).
There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized.
If the result of the fold is a constant, then the test (and the transform) can go in InstSimplify rather than InstCombine.
Also, as with my earlier comment, I appreciate the thorough testing, but I don't think we need 30+ tests of this fold. Some variation between data widths and vectors should give us enough coverage. There should be at least one vector test *without* undef in the zero constant because that shows a different result currently.