Blambdablambda is designed to be a lambda-like expression language where every primitive is also a bytecode primitive. This allows us to separate the bytecode backend into two stages:
Diffing_with_keysWhen diffing lists where each element has a distinct key, we can refine the diffing patch by introducing two composite edit moves: swaps and moves.
Jkind_typesYou should use the types defined in Jkind (which redefines the types in this file) rather than using this file directly, unless you are in Types or Primitive.
Language_extensionLanguage extensions provided by the Jane Street version of the OCaml compiler.
Language_extension_kernelLanguage extensions provided by the Jane Street version of the OCaml compiler. These are the parts of Language_extension that are required by Profile_counters_functions. Forward declaring these allow us to avoid a mutual dependency between files in utils/ and parsing/. Such a dependency prevents Merlin from compiling.
Local_storeThis module provides some facilities for creating references (and hash tables) which can easily be snapshoted and restored to an arbitrary version.
LocationSource code locations (ranges of positions), used in parsetree.
Mixed_product_bytesCounts the number of bytes belonging to values and flat (non-value) of a mixed block element, for the purpose of compiling block indices
ScalarThis module defines: The scalar types intrinsic to the OCaml compiler, and all of the primitive operations defined on them.
ShapeShapes are an abstract representation of modules' implementations which allow the tracking of definitions through functor applications and other module-level operations.
Typedecl_separabilityThe OCaml runtime assumes for type-directed optimizations that all types are "separable". A type is "separable" if either all its inhabitants (the values of this type) are floating-point numbers, or none of them are.
Vicuna_value_shapesThis file defines a representation of the runtime shapes of OCaml values. These shapes are different from (and unrelated to) the shapes defined in typing/shape.mli.
Available_ranges_varsGiven a variable x and a function, an "available subrange" is in the normal case a contiguous subset of that function's code paired with a register r, such that at all times during the block's execution the value of x is available in r. (r may end up being a hard register or a location on the stack.)
Backend_varVariables used in the backend, optionally equipped with "provenance" information, used for the emission of debugging information.
Cmm_invariantsCheck a number of continuation-related invariants
Cmm_peephole_engineThis module provides an engine for performing peephole optimisations on Cmm terms. A peephole optimisation is given as a rewriting rule, with a pattern on the left-hand side and a rewriting function on the right-hand side. The rewriting function takes as parameter an environment from which the sub-expressions that were matched to pattern variables can be retrieved.
Compute_rangesCoalescing of per-instruction information into possibly-discontiguous regions of code delimited by labels. This is used for collating register availability and lexical block scoping information into a concise form.
Compute_ranges_intfThis file defines types that are used to specify the interface of Compute_ranges. The description of Compute_ranges is:
DissectorDissector pass for analyzing ELF object files.
IpltIntermediate PLT (Procedure Linkage Table) for the dissector.
Is_parameterWhether a variable is a local or a function parameter.
Jit_backendJIT backend dispatch - architecture-independent interface for JIT. This module allows jit.ml to register a callback without knowing about architecture-specific emitters.
Oxcaml_argsThis module follows the structure of driver/main_args.ml and driver/main_args.mli. It provides a way to (a) share argument implementations between different installable tools and (b) override default implementations of arguments.
Reg_with_debug_infoRegisters equipped with information used for generating debugging information.
Regalloc_affinityThis module implements a basic variant of affinity: we compute the numbers of moves between temporaries and physical registers, and use this information in register allocators to try to assign a temporary to a physical register with high affinity.