Open vouillon opened 7 years ago
:+1: Open question: should we share this format with bucklescript https://github.com/bloomberg/bucklescript/blob/master/jscomp/core/js_cmj_format.mli
There is no reason to share the same format, as the generated codes are not compatible.
@vouillon, any idea on how to distinguish immutable (module) block from other possibly mutable ones? We could limit the optimisation to "compilation unit" modules and ignore sub-module but it would be a bit sad
One can get some type information from the debugging events.
I took a look at debug events. I think there are not enough.
We can recover some module info when the module appears on the ce_stack
and the corresponding Env_module
appears in the env summary but
ce_stack
I would be convenient to retrieve information about Immutable blocks. I wonder if we can store that information inside debug events or it we need some other mechanism.
We can get some information from the cmi files. But I'm not sure we want to go this way. (One may have to expand some module types, and thus load cmi files corresponding to other toplevel modules.)
The information in ce_stack
could still be useful internally to improve our analyses.
Maybe the module Bytegen
could emit some information about block mutability, in a way similar to how debug events are produced. There is some more information in the lambda code which is lost when generating the bytecode. It might make sense to preserve it as well. For instance, int32/in64 comparisons are translated into generic comparisons. Or we loose any information on the kind and layout of bigarrays.
@gasche, I'm pointing your here to give you an early notice of what we might want to contribute upstream at some point. I don't have time to work on a PoC or RFC right now. In short, there are information in lambda that are not propagate to byte-code. Jsoo would most likely benefit from such information. In particular, it would be useful to know that a block is immutable. We could maybe store additional information in the debug section, after debug events. Or even create a new section.
@hhugo See ocaml/ocaml#13438
We could greatly improve the code generated when compiling
cmo
files if we knew the arity of the functions exported by each module. This information could be stored in a separate file for each module compiled when the--dynlink
option is used, or when compilingcmo
andcma
files.