Improve unboxing during cmm for Flambda

[poechsel]

Cmm was able to unbox some values thanks to the value_kind put on let. However, only putting the value_kind on let is not enough and on some simple example the heuristic would fail.
For example, the following example:

let foo a =
  let b = if a >= 0.0 then a +. 1.0 else Float.nan in
  b *. b

Was compiling into:

 (let
   b/166
     (if (>=f (load float64 a/163) 0.)
       (alloc{../flambda-boxing/test.ml:2,27-35} 1277
         (+f (load float64 a/163) 1.))
       (load_mut val (+a "camlStdlib__Float" 56)))
   (alloc{../flambda-boxing/test.ml:3,2-8} 1277
     (*f (load float64 b/166) (load float64 b/166)))))

Instead of

 (let
   b/245
     (if (>=f (load float64 a/237) 0.) (+f (load float64 a/237) 1.)
       (load float64 (load_mut val (+a "camlStdlib__Float" 56))))
   (alloc{test.ml:3,2-8} 1277 (*f b/245 b/245))))

This PR adds a value_kind on all join points that is then used to decide if a value should be unboxed on some let statements.

[lthls]

Do we need all that machinery ? Your example gets unboxed as expected with Closure, so I would expect that the solution would be to add value_kind annotations on Flambda lets. Do you have other examples that benefit from the extra annotations, in particular with Closure ?

[lpw25]

(Disclaimer: I'm familiar with the idea of this PR, but haven't read the code yet)

lets really are just the wrong place to put this information. After this PR the value_kind information can be removed from lets, which should mean less machinery than before.

Trying to ensure that all lets have the kind information after transformations like the conversion to flambda can't really be done since not every expression that ends up as a let starts as one. You could try to just keep the information when it is available, but then it is hard to be sure that you keep it in all the situations where it might be needed. Here instead we attach the information to the semantic thing that needs it -- join points -- and thus it is trivial to maintain the information and to ensure that it is always available where it is needed.

I think it should be possible to produce some examples that don't unbox on closure without this PR. They aren't going to be common pieces of code though. Something like:

module Foo : sig
  type t
  val create : unit -> t 
  val add : t -> t -> t
end = struct
  type t = float
  let create () = 0.0
  let add = (+.)
end

type _ foo_or_float =
| Foo : Foo.t foo_or_float
| Float : float foo_or_float

let bar (type a) p (witness : a foo_or_float) (x : float) (y : float) : a =
  let z : a =
    match witness with
    | Foo -> Foo.create ()
    | Float ->
        if p then x +. y
        else y
  in
  match witness with
  | Foo -> Foo.add z z
  | Float -> z +. z

I would expect z to be unboxed with this PR but not previously.

[lthls]

I'm not completely convinced that it makes sense to spend time reviewing such a big patch when Flambda 2 already does the job correctly, but at least I understand why this patch is useful, thanks.

[lpw25]

Most of this looks good, but I think the changes in cmmgen.ml are much more invasive than they need to be.

[lpw25]

This is looking pretty good, just a few small things to address.

[lpw25]

Looks good to me.

[lpw25]

I've looked over the latest changes, and also noticed an issue based on a discussion with @Gbury.

[lthls]

Approving for the Flambda 2 parts.
The kinds in To_cmm_helpers are dubious, but they're never used and as noted in To_cmm, the Cmm terms generated here never return anything unless it's a function return anyway.