Remove useless interface

[xclerc]

When ocamlcfg was imported, all files were copied, but
ocamlcfg.ml{,i} is essentially useless: in the "standalone"
ocamlcfg, it acts as the interface exposed to users (because
the other modules are declared private), but it is not the case
here.

I am not entirely sure it is a good idea, as we could also decide
to re-instate a proper interface (that would need to be slightly
extended, though), but I thought it would be useful to discuss it.

[gretay-js]

The purpose of this interface was to limit the ways in which the underlying Cfg can be mutated (to make it easier to reason about correctness of block reordering performed by ocamlfdo). I think this is a valuable property to keep, even if it is not enforced by the build system. The rest of the backend should use the modules in the cfg directory via Ocamlcfg interface only. Maybe we can also have a separate cfg library in compiler-libs.

What interface extensions did you have in mind?

[xclerc]

What interface extensions did you have in mind?

Well, with the current interface, I think the only way to get a
graph is from a Linear.fundecl value. So, we would need
to be able to build/modify a graph.

[gretay-js]

What interface extensions did you have in mind?

Well, with the current interface, I think the only way to get a
graph is from a Linear.fundecl value. So, we would need
to be able to build/modify a graph.

[gretay-js]

I clicked closed by mistake, sorry.

Yes, it would be fine to add Mach_to_cfg to Ocamlcfg interface.

[xclerc]

Yes, it would be fine to add Mach_to_cfg to Ocamlcfg interface.

I guess this is a matter of taste; I was picturing Ocamlcfg as a
general data structure that could be used for various purposes
rather than a set of translators from/to linear, mach, etc.

[gretay-js]

The interface can have a generic data flow analysis and transformation framework, similarly to what is recently merged upstream.

@mshinwell @lpw25 : do you think we should remove the interface?

[lpw25]

Having an kind of library level interface for the rest of the compiler seems fine. For example, middle_end/flambda/flambda_middle_end.mli provides a similar thing for the flambda phases of the compiler. But I would expect that to be a high-level interface, not suitable to be used by e.g. FDO. I would expect the CFG-based passes themselves to access the CFG with a separate lower-level interface.

It seems like the invariant you are trying to maintain with the current interface is very specific to FDO and would not be suitable for any of the other passes that manipulate the CFG. So I think I would expect that specific interface to be part of FDO itself -- it's own personal wrapper around CFG to ensure that it doesn't make unexpected transformations.

[gretay-js]

So I think I would expect that specific interface to be part of FDO itself -- it's own personal wrapper around CFG to ensure that it doesn't make unexpected transformations.

good point! I'll add Ocamlcfg to ocamlfdo.