Allow Simple dominators in Flow Analysis (instead of just variables)

[Gbury]

This PR adds the ability for the data flow analysis to discover any Simple as a dominator, whereas previously only variables could be detected as dominators. In particular, that means that we can now detect (and add aliases) when a variable is aliased/dominated by a symbol or a constant.

Whenever we add such an alias to a constant, or a symbol (with a known type), we trigger a resimplification, since that opens up new opportunities for Simplify . This is in particular necessary for the example below to work.

This (finally) solves #2123 , so that in the following example:

[@@@ocaml.flambda_o3]

type 'a t = {
  mutable x : unit;
  get : int -> local_ 'a
}

let f j =
  let local_ t = { x = (); get = (fun x -> x) } in
  for i = 1 to j do
    Sys.opaque_identity ((t.get [@inlined hint]) i : int)
  done

The t.get function is indeed inlined inside of the loop. Unfortunately, this required three rounds of simplification (the first one does the mutable unboxing, the second one adds the alias to the symbol for the lifted function, and finally the third one can do the inlining). In the future, we could do it with only two passes if we ran a second alias analysis after the mutable unboxing (but that will require quite a bit of work).

It would be good if we could try and benchmark compilation times with this PR to checks whether the new code triggers too many resimplifications.

[chambart]

LGTM, only some wondering about the resimplification criteria

[Ekdohibs]

I'm wondering how safe this is w.r.t. mutable unboxing: if a mutable block ends up in a symbol, it must be marked as potentially escaping since the block could be modified by directly accessing its symbol.

[Gbury]

I'm wondering how safe this is w.r.t. mutable unboxing: if a mutable block ends up in a symbol, it must be marked as potentially escaping since the block could be modified by directly accessing its symbol.

I think we're safe because of the following reasons:

• mutable unboxing only triggers if the dominator is the mutable allocation
• symbols are lifted at top-level, so mutable unboxing involving a symbol can only trigger at top-level
• at top-level, we can effectively see all uses of the symbol, including if it's stored in the module block, so we should correctly compute whether it escapes or not

Note that if/when we try to not move symbol definitions at top-level (and instead tweak the let-binding in place to indicate it's now a symbol), this reasoning will not hold anymore.