package ocaml-base-compiler

You can search for identifiers within the package.

in-package search v0.2.0

Official 4.06.1 release

Install

Dune Dependency

ocaml.org Edit opam file Versions (66)

Authors

Maintainers

David Allsopp

Sources

4.06.1.tar.gz

sha256=fef12a65cab5f6d15ea22a72e328349530e179308f1005100e45e50a228d72c4

md5=d02eb67b828de22c3f97d94b3c46acba

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.