CLI Reference

The scriptc command has six subcommands: build, run, coverage, types, cache warm, and merge-profiles. scriptc --help prints this summary and the options below, and scriptc --version prints the installed version.

$ scriptc --help
scriptc — TypeScript/JavaScript to native and WebAssembly executables (experimental)

Usage:
  scriptc build <file.ts|.js> [options]     compile to an executable or source artifact
  scriptc run <file.ts|.js> [options]       compile and run
  scriptc coverage <file.ts|.js>            how much compiles statically, and why not
  scriptc coverage <file.ts|.js> --external-types <specifier=file.d.ts>
                                            type-resolve an embedder-provided module for analysis
  scriptc build --lib --profile <p.json>    library mode: compile the profile's entry
                                            module to a linkable static archive
                                            (<name>.lib.a), or a Wasm reactor
                                            (<name>.wasm) on wasm32-wasi,
                                            exporting the profile symbols; a profile
                                            with a sidecar section also gets the
                                            contract sidecar JSON beside the archive
  scriptc types patch <package> <selector> <type> [--range <r>] [--dry-run]
                                            fix a wrong declaration of an installed
                                            package: shows what the selector
                                            matches and adds the type patch to
                                            package.json ("| undefined" widens)
  scriptc types list                        the project's type patches and what
                                            they match
  scriptc cache warm [runtime|tls…] verify and load precompiled runtime families
                                            for the current compiler/SDK/target
  scriptc merge-profiles -o <out.profdata> [--sparse] <profile…>
                                            merge the raw profiles that
                                            --profile-generate runs wrote (or
                                            earlier merged profiles) into one
                                            profile for --profile-use;
                                            --sparse leaves out functions
                                            that never ran (a smaller file)

scriptc build

Compiles a TypeScript or JavaScript entry file. By default it writes a native executable, or a WebAssembly module when the target is wasm32-wasi. The program is type-checked first by the TypeScript compiler, honoring the nearest tsconfig.json. Anything that can't compile is an error with an SC-prefixed code, a code frame, and usually a rewrite hint.

$ scriptc build fib.ts -o fib >/dev/null
$ ./fib
832040

build prints the path of the file it writes. Without -o, the file goes in .scriptc/ next to the input. Use --emit to stop at an earlier stage of compilation:

$ scriptc build fib.ts --emit=ir >/dev/null
$ ls .scriptc/
fib.ir.json
$ scriptc build fib.ts --emit=llvm >/dev/null
$ ls .scriptc/
fib.ir.json
fib.ll
$ scriptc build fib.ts --emit=asm >/dev/null
$ ls .scriptc/
fib.ir.json
fib.ll
fib.s
$ scriptc build fib.ts --emit=obj >/dev/null
$ ls .scriptc/
fib.ir.json
fib.ll
fib.o
fib.s

Different output kinds accumulate in .scriptc/; rebuilding a kind updates its file.

--emit=exe is the default. Assembly and object output use the LLVM helper installed with scriptc and need no external compiler, linker, or SDK. An object is a relocatable program object that leaves scriptc's runtime functions undefined; it is not a standalone library. Linking objects yourself is experimental and requires the exact runtime pack reported by --print=native-link-info; see Native Program Objects.

Library mode

scriptc build --lib --profile <profile.json> compiles the entry module named in a library profile into a static archive (<name>.lib.a) that a host application links, or into a Wasm reactor (<name>.wasm) on wasm32-wasi. The profile declares the exported functions and their symbols. Library builds take no input file and don't accept --emit, --print, --optimization, --strip, --ffi, or --npm-static; the profile controls emission and optimization. See WebAssembly Modules for a complete profile and iOS and Android for mobile targets.

scriptc run

Builds the program, then runs it with stdio inherited. For wasm32-wasi, it runs the module with Node.js's WASI Preview 1 implementation, makes the current working directory available as /, and maps the host's temporary directory to /tmp.

$ scriptc run fib.ts
832040

run does not pass extra command-line arguments to the program. To pass arguments, build an executable and run it directly.

scriptc coverage

Analyzes the program without building it and reports what compiles and what blocks the rest. See Coverage Reports.

scriptc types

Writes and lists type patches, the project's fixes for wrong declarations of npm packages.

scriptc types patch <package> <selector> <type>

Finds the package installed for the working directory, prints every declaration the selector matches in its declaration files, its JSDoc and its @types/ package with the type before and after, and adds the patch to the nearest package.json. The patch joins an entry whose range covers the installed version, or gets the range ^<installed version>. Nothing is written when the selector matches nothing. --range <range> chooses the range, and --dry-run only prints.

scriptc types list

Prints each type patch in the nearest package.json, whether it applies to the installed version, and what it matches.

$ scriptc types list
commander@^15.0.0
  HelpContext.helpWidth: | undefined
    node_modules/commander/lib/command.js:2481  number  ->  number | undefined

scriptc cache warm

Verifies and loads the installed precompiled runtime objects and vendored libraries, and prints the cache directory. Pass runtime, tls, or both to select which to warm. Ordinary builds don't need this step. With --sanitize, it builds the instrumented runtime objects using a C toolchain.

scriptc merge-profiles

Merges the raw profiles that runs of a --profile-generate executable wrote, and any earlier merged profiles, into one profile for --profile-use. See Profile-guided optimization.

$ scriptc merge-profiles -o app.profdata profiles/*.profraw

With --sparse, the profile leaves out the functions the runs never reached. The file is smaller, typically by about two thirds, and those functions are optimized as without a profile instead of as cold code.

Options

-o, --out <path>

Primary artifact path. An explicit path is exact. Defaults are .scriptc/<name>.ir.json, .ll, .s, .o, or the platform executable name.

--emit <ir|llvm|asm|obj|exe>

Select the primary artifact: serialized typed IR (ir), textual LLVM IR (llvm), assembly (asm), a relocatable object (obj), or an executable (exe, the default). Every kind except exe is produced without an external compiler, linker, or SDK. Assembly and object output is compiled as one module; only executables are divided into partitions that compile in parallel (see Build parallelism).

--print <native-link-info|diagnostics>

native-link-info: build an object (equivalent to --emit=obj) and print its machine-readable external link recipe as JSON instead of printing the artifact path. The document names the exact installed precompiled runtime pack and all link inputs, but does not invoke a linker. diagnostics: for build and coverage, print the versioned JSON diagnostics document described in Coverage Reports instead of the human output.

--fail-on <blockers|divergences|dynamic|dynamic-slots>

Coverage only. Exit with status 1 when the entry has blockers that would fail a build, with divergences, also when it has Node divergence warnings, with dynamic, also when it has the SC6101 warning for untyped code that likely runs often, or with dynamic-slots, also when it has dynamic slots (SC6104). See Gating builds and CI.

--ffi <file>

Bind signature-only TypeScript declarations to native C ABI symbols and link the manifest's archive, object, and system-library inputs. See Native FFI.

--backend <llvm>

The code generator. llvm is the only backend and the default.

--strip

Remove symbol and debug payload when linking an executable, including cross-compiled targets. This flag preserves code optimization.

--static

On Linux, link the C library and the other system libraries into the executable. The executable starts without the dynamic loader, which shortens its startup, and doesn't depend on the run host's glibc version. glibc executables link as static PIE, are about 1 MB larger, and need glibc's static libraries on the build machine (libc6-dev on Debian and Ubuntu, glibc-static on Fedora); they link only for the build machine's own glibc target. A program whose executable includes host, user, or group name lookups, which dns.lookup, net and http connections, fetch, and os.userInfo() use, is refused with SC3002: a static glibc executable loads the NSS modules for those lookups from the run host, which glibc supports only for the glibc version it was linked with. Build such a program without --static, or for an <arch>-linux-musl target. musl executables are always linked statically, and accept the flag. Valid only for executable builds.

--optimization <release|dev|speed>

Select native optimization for executable, assembly, or object output. The default is release (-O2), which emits string retains and the retains and releases of dynamic values inline. dev uses -O0 and emits source locations for TypeScript and JavaScript breakpoints and stack frames. LLVM builds include source variable names and native storage descriptions; see Native debugging for the supported representations. macOS executable builds also produce an adjacent .dSYM bundle. speed is -O2 plus optimizations that trade binary size and build time for run-time speed: it emits the remaining reference counting inline and, on x86-64, starts every runtime function on a cache-line boundary. Expect larger executables and longer cold builds than release; how much faster a program runs depends on how much of its time is spent in the runtime. Where a runtime pack has no speed runtime, speed links the release runtime and keeps inline reference counting. Selecting speed never changes what release builds produce, and the two never share cached artifacts. Library profiles accept "optimization": "speed" for inline reference counting. In executables large enough to be divided into partitions, dev compiles each partition on its own, and release and speed add a step that lets partitions import small functions from each other; see Build parallelism.

--windows-subsystem <console|gui>

Select the subsystem of a Windows executable. console is the default; gui prevents Windows from opening a console window for the app. Valid only for executable builds targeting Windows.

--detached-exit

On Linux, when the program calls process.exit(), hand the release of its memory to a helper process so the parent sees the exit sooner. The kernel otherwise frees the whole address space before the exit is reported, which takes tens of milliseconds per gigabyte. Opt in only where the trade-offs are acceptable: for up to about 100 ms after the exit, the helper keeps the executable mapped (overwriting the binary in place fails with "text file busy"), its memory stays charged to the cgroup, and the teardown CPU time no longer appears in the parent's resource usage. Valid only for executable builds; it has no effect on other platforms.

--large-pages

On Linux, when the program starts, move its code onto 2 MiB transparent huge pages, as Node's --use-largepages=silent does. A large program's code then takes a few instruction TLB entries instead of hundreds, and runs faster. The move applies only when the system grants huge pages to memory that asks for them (/sys/kernel/mm/transparent_hugepage/enabled is always or madvise), and only to the code between the first and the last 2 MiB boundary of the executable, so small programs keep their code as it is. Opt in only where the trade-offs are acceptable: the move takes about 3 ms per 10 MiB of code at every start, all of the moved code stays resident and is not shared with other processes running the same executable, and profilers that read symbols from the executable file report the moved code as anonymous memory. If a step of the move fails, the program runs with its code where it was. Valid only for executable builds; it has no effect on other platforms.

--exceptions <common|rare>

On Linux, say how often the program throws. With the default, common, recursive functions and functions up to three calls above a throw report exceptions to their callers with a status check after each call, which costs a few nanoseconds per call and next to nothing when an exception passes. With rare, those functions also propagate exceptions by unwinding the native stack: their calls need no check, which makes programs such as type checkers, whose work is deep recursion that seldom throws, a few percent faster. An exception that crosses those functions then costs a native unwind, about 2 µs plus 0.1 to 0.7 µs per frame it crosses, so programs that throw in loops or use exceptions for control flow can become several times slower. Functions with a throw of their own keep the status check either way. It applies to executables and their LLVM and assembly output; object output and other platforms keep the status checks. A profile for --profile-use should be collected from a build with the same setting.

--target-cpu <baseline|x86-64-v2|x86-64-v3|x86-64-v4|native>

On x86-64 targets, compile the program's code for an x86-64 microarchitecture level. The default, baseline, runs on any x86-64 CPU. A higher level lets LLVM use more instructions, and the executable then runs only on CPUs that support that level. native uses the highest level the build machine supports. Valid for executable, assembly, and object output on x86-64 targets. See Target CPU.

--cpu-dispatch

On x86-64 targets, compile the program's code twice, for the baseline and for x86-64-v3, and choose the copy when the program starts. The executable runs on any x86-64 CPU and uses the x86-64-v3 code on CPUs that support it. Not used with a --target-cpu level above baseline. Valid only for executable builds. See Runtime CPU dispatch.

--profile-generate <pattern>

On Linux, build an instrumented executable for profile-guided optimization. Each run writes a raw profile to the path pattern, where %p expands to the process ID; the LLVM_PROFILE_FILE environment variable overrides the pattern at run time. A relative pattern resolves from the current working directory. Instrumented programs run slower. With --profile-use, the build is optimized by that profile and instrumented after inlining, the second phase of a context-sensitive profile. Valid only for executable builds with --optimization=release or speed.

--profile-use <file.profdata>

Optimize the executable with a profile from scriptc merge-profiles: code is laid out, inlined, and split by how the profiled runs used it. Code the profile does not describe, or describes from an older version of the program, is optimized as without a profile, so a stale profile only loses part of its gain; a block-count file beside the profile gives changed functions their counts again. A new or changed profile compiles every partition of the program again. scriptc build prints how the profile matched the program's functions on stderr; see Profile-guided optimization. A profile with context-sensitive counts also orders each function's blocks by them on Linux. Valid only for executable builds with --optimization=release or speed.

--npm-static <pkg[,pkg…]|auto>

Name npm packages to compile even if they don't ship their own type declarations (repeatable). A trailing ..., as in fs-extra..., also names every package that package depends on. auto uses the default automatic selection. Packages that can't compile produce diagnostics. See npm Dependencies.

--provenance-sources

Experimental. Compile npm dependencies from the source at the commit their provenance attestation names. Packages without a usable attestation compile from their installed files.

--external-types <specifier=file.d.ts>

Coverage only. Map an exact bare module specifier to a local declaration file supplied by an embedder. Repeat the option for multiple modules. The declaration supplies checker types so application coverage can continue; runtime imports and values remain explicit SC1010 blockers. Relative paths resolve from the current working directory. Accepted files end in .d.ts, .d.mts, or .d.cts.

--tier <auto|static-only>

The tier policy for code that has no static lowering. auto is the default. static-only guarantees that the program contains no dynamic-tier demotions: every such construct stays a compile error in TypeScript and a deferred runtime error in JavaScript, which is how both modes behave today. Use it in CI to keep a program fully static. Library mode is always static-only. See Dynamic tier.

--explain-dynamic[=<name>]

Coverage only. After the report, list the functions that already operate on values typed only at runtime and the bindings, fields, functions, classes and modules that unsupported constructs would move to the dynamic tier, each with the diagnostic behind it. With a name such as x, Point, or Point.x, show only the matching units. See Dynamic tier.

--no-dynamic-tier-warning

Build and coverage. Leave out SC6101, the warning that names functions that likely run often and use untyped values. Not allowed with --fail-on=dynamic. See Untyped code that likely runs often.

--wasm <file.wasm>

Coverage only. Report a WebAssembly module the program loads from a path its sources do not spell out. The report already lists modules whose paths the compiler resolves, modules inlined as base64 literals, and .wasm files shipped by packages that use WebAssembly; a scriptc.wasm array in package.json adds files the same way as this flag. Each module is listed with its size, whether it validates, and the WebAssembly proposals it uses. Builds translate the modules they find to native code; a build reads the scriptc.wasm array but not this flag. Repeatable.

--sanitize

Build an executable with AddressSanitizer and a reference-count audit at exit, the same checks scriptc's own test suite uses. Requires a C compiler and is available only for host builds. Not supported with --emit=asm or --emit=obj.

--emit-ir

Additive IR side artifact. It is deprecated for executable builds for one release cycle; prefer --emit=ir when IR is the primary output. Library mode retains --emit-ir because --emit does not select library artifacts.

--keep-llvm / --no-keep-llvm

Keep (default) or delete the generated .ll file next to the executable.

--lib, --profile <profile.json>

Build in library mode from the given profile. --lib requires --profile and works only with build.

-h, --help

Show usage.

-v, --version

Print the installed version.

Environment variables

SCRIPTC_CACHE_DIR

Override the persistent build-cache root. By default it is $XDG_CACHE_HOME/scriptc/build when set, $HOME/Library/Caches/scriptc/build on macOS, %LOCALAPPDATA%\scriptc\cache\build on Windows, and $HOME/.cache/scriptc/build elsewhere. Cached frontend results and LLVM artifacts, including the compiled partitions of large executables, are verified against their source, helper, target, and compilation settings. Native outputs also depend on the selected runtime pack and linker inputs. FFI objects, archives, and system libraries relink against their current dependencies. Sanitizer development builds additionally cache instrumented runtime objects and verify external compiler and header inputs. An existing POSIX override must already be private; otherwise caching is bypassed without changing the directory's permissions.

SCRIPTC_NO_CACHE

Set to 1 to bypass all build-cache reads and writes. An explicitly empty SCRIPTC_CACHE_DIR has the same effect.

SCRIPTC_CACHE_MAX_MB

Maximum build-cache size in megabytes. The default is 4096; the default cache is swept periodically, while an explicitly configured cap is checked after every successful cache write. Least-recently-used entries are removed when the cache exceeds the cap.

SCRIPTC_CC

The C compiler used for --sanitize builds. zigcc selects zig's cc subcommand.

SCRIPTC_LINKER

The linker driver for executable builds, in place of the default (clang on macOS and glibc Linux, zig elsewhere). It receives only object files, archives, and system libraries, and locates the platform SDK and C runtime itself.

SCRIPTC_TARGET

Target triple for cross-compilation, such as aarch64-linux-gnu.2.36, x86_64-windows-gnu, or wasm32-wasi. WASI builds default to a .wasm output name. See Platform Support.

SCRIPTC_RUNTIME_PACK

A runtime pack directory to use instead of an installed @scriptc/runtime-<target> package.

SCRIPTC_CHECKER

The TypeScript 7 API server that checks the program: tsc-ts (the default), which scriptc includes, or tsgo, from the typescript package scriptc also includes. Both give the same diagnostics and generated code.

SCRIPTC_CHECKER_SERVER

On Linux and macOS, builds check with a tsc-ts server that later builds share. The first build in a working directory starts it: a tsc-ts process, started with --api and --listen, that keeps running in the background with no terminal and keeps the files it parsed, so the next build in that directory loads its program faster. Each user, working directory and scriptc installation gets its own server, and a build connects only to the server of its own scriptc and tsc-ts. The socket is in $XDG_RUNTIME_DIR/scriptc, or /tmp/scriptc-<uid>, a directory only that user can access. A build that finds the server in use by another build, cannot start or reach it, or loses its connection to it, checks with its own tsc-ts process. The server exits after 10 minutes without a build, or after a build when its resident memory is above 2048 MB (TSC_TS_LISTEN_MEMORY sets another limit in megabytes). To stop it sooner, end that process, for example with pkill -f 'tsc-ts --api .*--listen'. Set to 0 to check with a tsc-ts process of each build's own. When CI is set to a value other than 0 or false, builds use their own process unless this variable is 1. Diagnostics and generated code are the same with and without the server. It applies to the default checker, tsc-ts.

$ SCRIPTC_TARGET=aarch64-linux-gnu.2.36 scriptc build fib.ts -o fib-linux
$ file fib-linux
fib-linux: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 2.0.0, with debug_info, not stripped

Profile-guided optimization

A profile records how often each branch and call ran in representative runs of the program. With it, the optimizer inlines the hot calls, keeps hot paths together, and moves cold code out of the way. Profiling takes three steps:

$ scriptc build app.ts --optimization=speed --profile-generate profiles/%p.profraw -o app-instrumented
$ ./app-instrumented typical-input.json
$ scriptc merge-profiles -o app.profdata profiles/*.profraw
$ scriptc build app.ts --optimization=speed --profile-use app.profdata

Train on workloads like the ones the program will run: code the training never reached is optimized as without a profile. The profile can be committed and reused as the program changes, and in other checkouts and on other machines: it names functions by the entry's file name, not its directory. Functions whose control flow changed since the profile was collected lose their profile, and the rest keep theirs, so regenerate it when much of the program has changed. Build parallelism describes what a profile adds to build time.

scriptc build --profile-use prints one line on stderr with how the profile matched the program's functions:

scriptc: profile app.profdata: 9170 functions annotated, 0 mismatched, 28636 without a record

• annotated: functions optimized with the profile's counts.
• mismatched: functions whose control flow changed since the profile was collected. They are optimized without counts.
• without a record: functions the profile does not describe: new functions, and functions the profiled runs never reached.
• When the build reuses cached partitions whose counts were not recorded, the line ends with the number of those partitions.

When more than 10% of the functions the profile describes (annotated and mismatched) are mismatched, the build also prints a warning:

scriptc: warning: 3739 of the 8947 functions app.profdata describes (41.8%) changed since it was collected and are optimized without their counts; collect the profile again

The build still succeeds. Collecting the profile again with the current program and scriptc version restores the counts.

Context-sensitive profiles

A profile from the steps above counts each function's branches before the optimizer inlines calls. A second phase counts them again after inlining, separately for every place a function was inlined into:

$ scriptc build app.ts --optimization=speed --profile-use app.profdata --profile-generate profiles-cs/%p.profraw -o app-instrumented-cs
$ ./app-instrumented-cs typical-input.json
$ scriptc merge-profiles -o app-cs.profdata app.profdata profiles-cs/*.profraw
$ scriptc build app.ts --optimization=speed --profile-use app-cs.profdata

• First phase: --profile-generate alone. It instruments the program before inlining and gives the profile of the steps above.
• Second phase: --profile-use with the first profile and --profile-generate together. The build is optimized by the first profile and instrumented after inlining, and scriptc merge-profiles adds its counts to the first profile.
• Optimized build: --profile-use with the merged profile. On Linux, it also orders each function's blocks by the counts and moves blocks the runs never reached into separate sections, so the code that runs sits together.

A profile that already holds context-sensitive counts cannot start a second phase. Merge the second phase's raw profiles into the first-phase profile instead. Both phases run the same workloads.

Block counts

A profile matches a function only while the function's control flow hashes as it did when the profile was collected, so a change to the program or to scriptc leaves the changed functions without counts. A block-count file beside the profile, with its name and a .blocks extension in place of .profdata (app.blocks beside app.profdata), describes each function by the labels of its blocks instead. --profile-use reads it when it exists and annotates the functions whose control flow changed (the mismatched ones): blocks that keep their place in the function take their recorded counts, and the counts of the other blocks follow from the counts of the blocks and edges around them. The file also names the functions that never ran while the profile was collected, which a profile merged with --sparse has no record of. Those functions are compiled as cold code (an entry count of 0, optimized for size and placed with the other unlikely code), which shortens the build. A function the file does not name, for example one added since the profile was collected, keeps no counts and is optimized as without a profile. The report then adds a line, and the warning counts only the functions that remain without counts:

scriptc: profile app-cs.profdata: 0 functions annotated, 1 mismatched, 0 without a record
scriptc: profile app-cs.profdata: 1 function without profile counts annotated from app-cs.blocks

A --profile-use build writes the block counts of the functions its profile annotates, and the names of the functions it has no record of, when the SCRIPTC_RECORD_PROFILE_BLOCKS environment variable names a path; such a build reuses no cached artifacts. For a context-sensitive profile, record them in the second phase, which the first-phase profile annotates:

$ SCRIPTC_RECORD_PROFILE_BLOCKS=app-cs.blocks scriptc build app.ts --optimization=speed --profile-use app.profdata --profile-generate profiles-cs/%p.profraw -o app-instrumented-cs

A new or changed block-count file compiles every partition of the program again. Delete it when the profile it was recorded with is replaced.

The file holds the counts before inlining. With a context-sensitive profile, a function whose control flow changed, and a function it is inlined into, also lose their context-sensitive counts and keep the counts from before inlining.

Target CPU

By default, x86-64 executables run on any x86-64 CPU, so the compiler uses only the baseline instruction set (SSE2). --target-cpu compiles the program's code for a higher x86-64 microarchitecture level. Each level includes the ones below it:

$ scriptc build app.ts --target-cpu=x86-64-v3 -o app

Loops over typed arrays and numbers gain the most, because LLVM vectorizes them with wider registers. Some loops run slower at a higher level, so measure the program on the machines it will run on.

An executable built for a level runs only on CPUs that support that level. On an older CPU, it crashes with an illegal-instruction signal (SIGILL) when it reaches an instruction the CPU lacks. A named level is portable to every machine of that level. native selects the highest level the build machine supports, so use it only for executables that run on the machine that built them or on identical machines.

The level applies to the program's own code. The runtime pack keeps its baseline code. Builds for different levels never share cached artifacts, and baseline builds are the same as builds without the option.

Runtime CPU dispatch

--cpu-dispatch keeps the executable portable and still uses the higher level where the CPU has it. The program's functions are compiled for the baseline and for x86-64-v3. At startup, the executable checks the CPU and the operating system's register support, and then runs the x86-64-v3 code on CPUs that support every feature of that level. Calls between the program's functions stay within the chosen copy.

$ scriptc build app.ts --optimization=speed --cpu-dispatch -o app

The second copy makes the executable larger and the first build of the program slower, since LLVM compiles the program's code twice. Unchanged rebuilds are not affected. Both copies compute the same results: neither contracts floating-point operations into fused multiply-adds.

A function's x86-64-v3 copy runs its baseline code when its optimized code has vectors of at most 128 bits, none wider, and no rounding or bit counting in a loop. In such code, x86-64-v3 only lets LLVM's vectorizers move scalar work onto vector instructions, which can run slower. Its calls still go to the x86-64-v3 copies of the functions it calls.

The SCRIPTC_CPU_LEVEL environment variable caps the level the executable uses, for example to test the baseline code on a newer machine. It takes a level from 0 to 4, baseline, or a level name such as x86-64-v3; any other value selects the baseline code.

$ SCRIPTC_CPU_LEVEL=baseline ./app

LLVM backend

scriptc generates LLVM IR and compiles it to native code. Executable builds link the result with the matching precompiled runtime pack. Use --emit=llvm to inspect the generated code.

For source breakpoints in Xcode or LLDB, build with --optimization=dev. In an Xcode custom build rule, list the executable and its .dSYM bundle as outputs. Keep the bundle next to the executable and retain the original source files at their build paths. LLVM preserves source locations across imported modules.

Tool requirements