Propagate arity between compilation units

[hhugo]

PoC for #550

• Store immutability property of blocks
• Try to recover some immutability info from debug events. (currently assuming modules are immutable, need to check what happens with recursive modules
• Use this info to compute an approximated shape for registered globals.
• Use shape info to compute function arity across compilation units (this is currently only done when compiling cma files as we know the shape of previously compiled units inside the library)

TODOs/Questions:

• check the behavior with recursive modules
• fix with effects
• update global_flow ?
• better mechanism for shape propagation ?-
• store shape in a different file ? yes
• should the "shape" file be given jsoo on the command line or should it look for it on the file system ? both
• update dune rules with additional deps (WIP Jsoo shapes ocaml/dune#10767)

[hhugo]

@vouillon, feel free to comment, review and even commit the branch.

[hhugo]

@vouillon, I think we could merge this before we have the support merged inside dune.
Would you want to give it another round of review ?

[hhugo]

It increases to the time to build the toplevel in whole program compilation by ~10%. But we don't benefit from shapes in such case.

[vouillon]

The following command spends a lot of time in Flow.the_shape_of (called from Specialize.function_arity).

js_of_ocaml `which ocamlc.byte` 

[Copilot]

Copilot reviewed 10 out of 29 changed files in this pull request and generated no comments.

Files not reviewed (19)

• compiler/bin-js_of_ocaml/build_fs.ml: Language not supported
• compiler/bin-js_of_ocaml/cmd_arg.ml: Language not supported
• compiler/bin-js_of_ocaml/cmd_arg.mli: Language not supported
• compiler/bin-js_of_ocaml/compile.ml: Language not supported
• compiler/lib/code.ml: Language not supported
• compiler/lib/code.mli: Language not supported
• compiler/lib/config.ml: Language not supported
• compiler/lib/config.mli: Language not supported
• compiler/lib/driver.ml: Language not supported
• compiler/lib/driver.mli: Language not supported
• compiler/lib/flow.ml: Language not supported
• compiler/lib/flow.mli: Language not supported
• compiler/lib/global_flow.ml: Language not supported
• compiler/lib/ocaml_compiler.ml: Language not supported
• compiler/lib/ocaml_compiler.mli: Language not supported
• compiler/lib/parse_bytecode.ml: Language not supported
• compiler/lib/pure_fun.ml: Language not supported
• compiler/lib/shape.ml: Language not supported
• compiler/lib/shape.mli: Language not supported

[hhugo]

@vouillon, I've rebased and updated the PR.

The compilation time of partial-render-table increases by 20% because it no longer stabilizes after 7 rounds, it needs 13 but stops after 10 (because of --opt 2). Additional rounds are a sequence of optcall and inline optimizations. I haven't looked at it more than that.

I think the PR is ready for another round of review.

[TyOverby]

@hhugo is this only for whole-program compilation?

[hhugo]

@hhugo is this only for whole-program compilation?

This is mostly for separate compilation but it improves whole_program compilation as well it seems.

[hhugo]

The regression for partial-render-table is now fixed

[hhugo]

@TyOverby, @rickyvetter, Would you mind testing this PR as well ?