Remove integer comparison involving nonconstant polymorphic variants

[lthls]

This hopefully means that we will be able to revert #729.

[mshinwell]

For context, this relates to examples like the following:

type simple = [ `Black | `Blue | `Red | `Green | `Yellow ]

let[@inline never] compare_simple s1 s2 = Sys.opaque_identity 0

type t = [ simple | `RGB of int ]

let compare t1 t2 =
  match t1, t2 with
  | #simple as s1, #simple as s2 -> compare_simple s1 s2
  | `RGB i1, `RGB i2 -> Int.compare i1 i2
  | x, y -> compare x y

let example = `RGB 12345

let compare_spec t = (compare [@inlined]) t example

where currently the pattern matching compiler is generating integer ordered comparisons between pointers and integers, which we wish to disallow:

(let
  (compare_simple/262 = (function s1/264 s2/265 never_inline : int (opaque 0))
   compare/335 =
     (function t1/336 t2/337 : int
       (catch
         (catch
           (if (isint t1/336)
             (if (>= t1/336 82908052) (if (!= t1/336 737308346) (if (!= t1/336 756711075) (if (>= t1/336 82908053) (exit 1) (exit 2)) (exit 2)) (exit 2))
               (if (!= t1/336 -937474657) (if (!= t1/336 4100401) (exit 1) (exit 2)) (exit 2)))
             (if (!= (field 0 t1/336) 4093677) (exit 1) (if (isint t2/337) (exit 1) (if (!= (field 0 t2/337) 4093677) (exit 1) (apply (field 8 (global Stdlib__Int!)) (field 1 t1/336) (field 1 t2/337))))))
          with (2)
           (catch
(* --> *)      (if (>= t2/337 82908052) (if (!= t2/337 737308346) (if (!= t2/337 756711075) (if (>= t2/337 82908053) (exit 1) (exit 3)) (exit 3)) (exit 3))
               (if (!= t2/337 -937474657) (if (!= t2/337 4100401) (exit 1) (exit 3)) (exit 3)))
            with (3) (apply compare_simple/262 t1/336 (makeblock 0 t1/336 t2/337))))
        with (1) (caml_compare t1/336 t2/337)))
   example/371 = [0: 4093677 12345]
   compare_spec/372 = (function t/374 : int (apply compare/335 t/374 example/371 always_inline)))
  (makeblock 0 compare_simple/262 compare/335 example/371 compare_spec/372))

[lthls]

I think this also fixes a bug.
Looking at the generated lambda:

(if (>= t1/336 82908052) ... (if (>= t1/336 82908053) ...

The last test checks whether t1/336 is equal to 82908052. It assumes the there is no valid input between 82908052 and 82908053. But after taking tagging into account, these become tests against 165816105 and 165816107 respectively. So there could be a pointer represented as 165816106 hiding in between (in this particular case, alignment forbids it, but it could happen for different hashes).
For this reason, I think we could upstream the fix.

[mshinwell]

Wow that is very subtle. We should upstream this.

[lthls]

I've created a PR upstream (ocaml/ocaml#11587).

[mshinwell]

I'm going to approve this based on the upstream approval.