package ocaml-base-compiler

You can search for identifiers within the package.

in-package search v0.2.0

Official 4.06.0 release

Install

Dune Dependency

ocaml.org Edit opam file Versions (66)

Authors

Maintainers

David Allsopp

Sources

4.06.0.tar.gz

sha256=011879c913e8f988ecdac020b205e2baa4023052efed25013bdb9a6b0d5c6a80

md5=4f3906e581181c5435078ffe3e485e3f

doc/ocamloptcomp/Closure_offsets/index.html

Module `Closure_offsets`

Assign numerical offsets, within closure blocks, for code pointers and environment entries.

type result = private {

function_offsets : int Closure_id.Map.t;
free_variable_offsets : int Var_within_closure.Map.t;

}

val compute : Flambda.program -> result

val compute_reexported_offsets : 
  Flambda.program ->
  current_unit_offset_fun:int Closure_id.Map.t ->
  current_unit_offset_fv:int Var_within_closure.Map.t ->
  imported_units_offset_fun:int Closure_id.Map.t ->
  imported_units_offset_fv:int Var_within_closure.Map.t ->
  int Closure_id.Map.t * int Var_within_closure.Map.t

If compilation unit C references B, which contains functions inlined from another compilation unit A, then we may need to know the layout of closures inside (or constructed by code inside) a.cmx in order to compile c.cmx. Unfortunately a.cmx is permitted to be absent during such compilation; c.cmx will be compiled using just b.cmx. As such, when building the .cmx export information for a given compilation unit, we also include information about the layout of any closures that it depends on from other compilation units. This means that when situations as just describe arise, we always have access to the necessary closure offsets.