numbl 0.2.0 → 0.3.0

package/dist-lib/numbl-core/jit/c/hybrid.d.ts

@@ -1,42 +0,0 @@
-/**
- * Hybrid JS/C-JIT compilation: when the outer body falls back to JS-JIT,
- * still try C-JIT at narrower scopes and splice the native handles in.
- * Two shapes:
- *
- *   - `compileHybridCallees`: walks `generatedIRBodies` (one entry per
- *     user-function specialization reached by the outer) and tries
- *     C-JIT on each standalone. Successes get installed on
- *     `rt.jitHelpers[$cjit_<jitName>]` and their cached JS source is
- *     rewritten to `var <jitName> = $h.$cjit_<jitName>;` so the outer
- *     JS transparently calls native code at the callee boundary.
- *
- *   - `compileHybridLoops`: walks the outer's top-level JitStmt body,
- *     finds `For`/`While` stmts whose body is C-feasible, extracts each
- *     as a synthetic specialization (live-in vars → params, live-out
- *     vars → outputs), compiles it to native, and replaces the loop
- *     stmt in the outer's IR with a `UserCallWriteback` that invokes
- *     the handle and writes back outputs into the outer's locals.
- *
- * Preconditions at call time:
- *   - `interp.optimization >= 2`
- *   - `interp.rt.jitHelpers` is populated (i.e. past executeCode init)
- *   - the shared `generatedFns` / `generatedIRBodies` maps come from the
- *     outer specialization's `LoweringResult`
- *
- * Calling convention matches: `$h.callUser($rt, name, fn, ...args)`
- * invokes `fn(...args)`, and the args are the JIT's emitted JS forms —
- * raw JS numbers for scalars, RuntimeTensor for tensors, etc. — same
- * shape the C-JIT wrapper expects since it was compiled with matching
- * `argTypes`.
- */
-import type { Interpreter } from "../../interpreter/interpreter.js";
-import type { GeneratedFn } from "../jitLower.js";
-import type { JitStmt } from "../jitTypes.js";
-import type { TypeEnv } from "../jitLowerTypes.js";
-export declare function compileHybridCallees(interp: Interpreter, generatedIRBodies: Map<string, GeneratedFn>, generatedFns: Map<string, string>): void;
-/**
- * Extract top-level For/While loops from the outer's IR and try to
- * compile each to native. On success the loop is replaced in-place by a
- * `UserCallWriteback` stmt.
- */
-export declare function compileHybridLoops(interp: Interpreter, outerBody: JitStmt[], outerEndEnv: TypeEnv, outerOutputNames: string[], generatedIRBodies: Map<string, GeneratedFn>, generatedFns: Map<string, string>): void;

package/dist-lib/numbl-core/jit/c/install.d.ts

@@ -1,15 +0,0 @@
-/**
- * Installs the C-JIT backend (koffi path). Side-effect import only.
- *
- * Must be imported exactly once from a Node-only entry point (currently
- * src/cli.ts). The browser bundle never reaches this file, so the
- * Node-only dependencies stay out of the web build.
- *
- * The JS wrapper handles:
- *   - Extracting .data (Float64Array) and .data.length from RuntimeTensor args
- *   - Pre-allocating output buffers (Float64Array for tensor outputs,
- *     Float64Array(1) for scalar out-pointers)
- *   - Buffer reuse for tensor outputs (same logic as jitHelpersTensor.ts)
- *   - Wrapping results back into RuntimeTensor objects
- */
-export {};

package/dist-lib/numbl-core/jit/c/parityError.d.ts

@@ -1,26 +0,0 @@
-/**
- * Thrown under `--check-c-jit-parity` when the C-JIT declines to compile
- * a function/loop whose IR the JS-JIT would have accepted. The message
- * names the construct (from the feasibility checker) and the call site,
- * giving us an actionable punch list of features to implement in the
- * C-JIT so parity with JS-JIT holds.
- */
-export declare class CJitParityError extends Error {
-    readonly reason: string;
-    readonly kind: "infeasible" | "env";
-    constructor(message: string, reason: string, kind: "infeasible" | "env");
-}
-/**
- * Build a one-line parity-error message with the offending construct,
- * the call site (function/loop name + file:line), and the arg-type
- * signature that triggered the specialization.
- */
-export declare function formatCJitParityMessage(opts: {
-    kind: "infeasible" | "env";
-    reason: string;
-    reasonLine?: number;
-    siteLabel: string;
-    file: string;
-    callSiteLine: number;
-    argsDesc: string;
-}): string;

package/dist-lib/numbl-core/jit/c/registry.d.ts

@@ -1,51 +0,0 @@
-/**
- * Registrable hook for the C-JIT backend.
- *
- * The C-JIT's implementation pulls in Node-only modules (`child_process`,
- * `fs`, `path`, ...) that would pollute the browser bundle if imported
- * statically from [jit/index.ts](./index.ts). This module defines a
- * thin interface + a module-level slot; the real backend is installed
- * from the CLI entry point via [install.ts](./install.ts),
- * which is only pulled into the Node-targeted build.
- *
- * When no backend is registered (e.g. browser, or someone running the
- * library API directly) `getCJitBackend()` returns null and
- * `tryJitCall` silently falls through to JS-JIT.
- */
-import type { Interpreter } from "../../interpreter/interpreter.js";
-import type { FunctionDef } from "../../interpreter/types.js";
-import type { JitStmt, JitType } from "../jitTypes.js";
-import type { GeneratedFn } from "../jitLower.js";
-/**
- * Outcome of a C-JIT compile attempt.
- *
- * - `ok: true`: compilation succeeded; `fn` is callable.
- * - `ok: false, kind: "infeasible"`: the lowered IR contains a construct
- *   the C-JIT doesn't handle (JS-JIT probably would). Carries a `reason`
- *   and optional `line` from the feasibility checker; `--check-c-jit-parity`
- *   treats this as a hard error.
- * - `ok: false, kind: "env"`: the environment couldn't support C-JIT
- *   (no C compiler, compile/link failed, header missing, etc.). Also a
- *   hard error under `--check-c-jit-parity` because the user explicitly
- *   asked for C-JIT.
- */
-export type CJitCompileResult = {
-    ok: true;
-    fn: (...args: unknown[]) => unknown;
-} | {
-    ok: false;
-    kind: "infeasible" | "env";
-    reason: string;
-    line?: number;
-};
-export interface CJitBackend {
-    /**
-     * Attempt to emit + compile + load a C specialization for the given
-     * lowered IR. Returns a structured result: callers distinguish
-     * `infeasible` (parity gap with JS-JIT) from `env` (missing compiler)
-     * when `--check-c-jit-parity` is on.
-     */
-    tryCompile(interp: Interpreter, fn: FunctionDef, body: JitStmt[], outputNames: string[], localVars: Set<string>, outputType: JitType | null, outputTypes: JitType[], argTypes: JitType[], nargout: number, generatedIRBodies: Map<string, GeneratedFn>): CJitCompileResult;
-}
-export declare function registerCJitBackend(b: CJitBackend): void;
-export declare function getCJitBackend(): CJitBackend | null;