package ocaml-base-compiler

You can search for identifiers within the package.

in-package search v0.2.0

Official 4.05.0 release

Install

Dune Dependency

ocaml.org Edit opam file Versions (66)

Authors

Maintainers

David Allsopp

Sources

4.05.0.tar.gz

sha256=e5d8a6f629020c580473d8afcfcb06c3966d01929f7b734f41dc0c737cd8ea3f

md5=7e0079162134336a24b9028349c756bb

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.