Revert "nir/algebraic: Convert some f2u to f2i"

Per https://gitlab.freedesktop.org/mesa/mesa/-/issues/5178#note_1019666,
the assumption fundamental to this optimization is false.  Section
2.4.1 (Float to Integer) of Ivy Bridge PRMs describes the situation.
The wording of the section is somewhat confusing (because it doesn't
clearly delineate between signed and unsigned integers), but the last
two rows of the table make it clear that F->UD conversion clamps
negative float values to 0.

All other hardware mentioned in that thread seems to behave the same
way.

The real problem is that, with hardware that behaves in this ways,
converting f2u(2147483648.0) to f2i(2147483648.0) changes the bit pattern
that would be produced from 0x80000000 to 0x7fffffff.

This reverts commit ad05920258.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12297>

src/compiler/nir/nir_opt_algebraic.py

@@ -1162,19 +1162,6 @@ optimizations.extend([
    (('iabs', 'a(is_not_negative)'), a),
    (('fsat', 'a(is_not_positive)'), 0.0),
 
-   # Section 5.4.1 (Conversion and Scalar Constructors) of the GLSL 4.60 spec
-   # says:
-   #
-   #    It is undefined to convert a negative floating-point value to an
-   #    uint.
-   #
-   # Assuming that (uint)some_float behaves like (uint)(int)some_float allows
-   # some optimizations in the i965 backend to proceed.
-   (('ige', ('f2u', a), b), ('ige', ('f2i', a), b)),
-   (('ige', b, ('f2u', a)), ('ige', b, ('f2i', a))),
-   (('ilt', ('f2u', a), b), ('ilt', ('f2i', a), b)),
-   (('ilt', b, ('f2u', a)), ('ilt', b, ('f2i', a))),
-
    (('~fmin', 'a(is_not_negative)', 1.0), ('fsat', a), '!options->lower_fsat'),
 
    # The result of the multiply must be in [-1, 0], so the result of the ffma