gccjit 0.3.2 (latest) · OCaml Package

Lifetime-management

val create : unit -> context

Creates a new context instance, which is independent of any others that may be present within this process.

val release : context -> unit

Releases all resources associated with the given context. Both the context itself and all of its object instances are cleared up. It should be called exactly once on a given context.

It is invalid to use the context or any of its contextual objects after calling this.

val create_child : context -> context

Given an existing JIT context, create a child context.

The child inherits a copy of all option-settings from the parent.
The child can reference objects created within the parent, but not vice-versa.
The lifetime of the child context must be bounded by that of the parent: you should release a child context before releasing the parent context.

If you use a function from a parent context within a child context, you have to compile the parent context before you can compile the child context, and the result of the parent context must outlive the result of the child context.

This allows caching of shared initializations. For example, you could create types and declarations of global functions in a parent context once within a process, and then create child contexts whenever a function or loop becomes hot. Each such child context can be used for JIT-compiling just one function or loop, but can reference types and helper functions created within the parent context.

Contexts can be arbitrarily nested, provided the above rules are followed, but it's probably not worth going above 2 or 3 levels, and there will likely be a performance hit for such nesting.

Thread-safety

Instances of context created via create are independent from each other: only one thread may use a given context at once, but multiple threads could each have their own contexts without needing locks.

Contexts created via create_child are related to their parent context. They can be partitioned by their ultimate ancestor into independent "family trees". Only one thread within a process may use a given "family tree" of such contexts at once, and if you're using multiple threads you should provide your own locking around entire such context partitions.

Debugging

val dump_to_file : context -> ?update_locs:bool -> string -> unit

Dump a C-like representation to the given path, describing what's been set up on the context. If ~update_locs true, then also set up location information throughout the context, pointing at the dump file as if it were a source file. This may be of use in conjunction with Debuginfo to allow stepping through the code in a debugger.

val set_logfile : context -> Unix.file_descr option -> unit

set_logfile ctx logfile enable ongoing logging of the context ctx's activity to the given file descriptor logfile. Examples of information logged include:

API calls
the various steps involved within compilation
activity on any result instances created by the context
activity within any child contexts
An example of a log can be seen here, though the precise format and kinds of information logged is subject to change.

The caller remains responsible for closing logfile, and it must not be closed until all users are released. In particular, note that child contexts and result instances created by the context will use logfile.

There may a performance cost for logging.

You can turn off logging on ctx by passing None for logfile. Doing so only affects the context; it does not affect child contexts or result instances already created by the context.

val dump_reproducer_to_file : context -> string -> unit

Write C source code into path that can be compiled into a self-contained executable (i.e. with libgccjit as the only dependency). The generated code will attempt to replay the API calls that have been made into the given context.

This may be useful when debugging the library or client code, for reducing a complicated recipe for reproducing a bug into a simpler form. For example, consider client code that parses some source file into some internal representation, and then walks this IR, calling into libgccjit. If this encounters a bug, a call to dump_reproducer_to_file will write out C code for a much simpler executable that performs the equivalent calls into libgccjit, without needing the client code and its data.

Typically you need to supply "-Wno-unused-variable" when compiling the generated file (since the result of each API call is assigned to a unique variable within the generated C source, and not all are necessarily then used).

Context Options

type _ context_option =

| Progname : string context_option
(*
The name of the program, for used as a prefix when printing error messages to stderr. If not set, "libgccjit.so" is used.
*)
| Optimization_level : int context_option
(*
How much to optimize the code. Valid values are 0-3, corresponding to GCC's command-line options -O0 through -O3.
The default value is 0 (unoptimized).
*)
| Debuginfo : bool context_option
(*
If true, Context.compile will attempt to do the right thing so that if you attach a debugger to the process, it will be able to inspect variables and step through your code. Note that you can't step through code unless you set up source location information for the code (by creating and passing in location instances).
*)
| Dump_initial_tree : bool context_option
(*
If true, Context.compile will dump its initial "tree" representation of your code to stderr (before any optimizations).
*)
| Dump_initial_gimple : bool context_option
(*
If true, Context.compile will dump the "gimple" representation of your code to stderr, before any optimizations are performed. The dump resembles C code.
*)
| Dump_generated_code : bool context_option
(*
If true, Context.compile will dump the final generated code to stderr, in the form of assembly language.
*)
| Dump_summary : bool context_option
(*
If true, Context.compile will print information to stderr on the actions it is performing, followed by a profile showing the time taken and memory usage of each phase.
*)
| Dump_everything : bool context_option
(*
If true, Context.compile will dump copious amount of information on what it's doing to various files within a temporary directory. Use Keep_intermediates (see below) to see the results. The files are intended to be human-readable, but the exact files and their formats are subject to change.
*)
| Selfcheck_gc : bool context_option
(*
If true, libgccjit will aggressively run its garbage collector, to shake out bugs (greatly slowing down the compile). This is likely to only be of interest to developers *of* the library. It is used when running the selftest suite.
*)
| Keep_intermediates : bool context_option
(*
If true, Context.release will not clean up intermediate files written to the filesystem, and will display their location on stderr.
*)

val set_option : context -> 'a context_option -> 'a -> unit

set_option ctx opt v sets the Context.context_option opt of ctx to v.

Compilation

Once populated, a context can be compiled to machine code, either in-memory via compile or to disk via compile_to_file.

You can compile a context multiple times (using either form of compilation), although any errors that occur on the context will prevent any future compilation of that context.

val compile : context -> result

This calls into GCC and builds the code, returning a result. See In-memory compilation.

type output_kind =

| Assembler
(*
Compile the context to an assembly file.
*)
| Object_file
(*
Compile the context to an object file.
*)
| Dynamic_library
(*
Compile the context to a dynamic library.
*)
| Executable
(*
Compile the context to an executable.
*)

Kinds of ahead-of-time compilation, for use with compile_to_file.

val compile_to_file : context -> output_kind -> string -> unit

Compile the context to a file of the given kind. This can be called more that once on a given context, although any errors that occur will block further compilation.

package gccjit

Lifetime-management

Thread-safety

Debugging

Context Options

Compilation