Native compilation and performance

LLVM native is the current reference execution target. Its results define routine correctness and performance acceptance while future providers are built over the same canonical artifact boundary.

Pipeline overview

source
→ parser and surface desugaring
→ environments and semantic checks
→ strict bidirectional type checking
→ closed typed Stage-R
→ specialization and evidence closure
→ artifact-local RuntimeCore
→ shared effect lowering
→ verify → optimize → verify
→ native LIR → LLVM
→ compiler-shipped clang++/LLD and runtime bitcode

There is no Surface-to-backend fallback. The provider receives an immutable closed program with exact entries, signatures, call intent, evidence, layouts, and origins.

The released compiler carries its pinned LLVM worker, Clang, LLD, runtime artifact, compiler runtime archive, and private shared libraries. Native builds do not search the host PATH or require an installed LLVM SDK. The no-argument shell shares this pipeline through LLVM emission, then loads a namespaced module in an isolated out-of-process ORC worker.

Optimizations

The shared RuntimeCore pipeline includes safe eta reduction, inlining, constant folding, known-constructor simplification, and dead-code elimination. Native lowering can specialize, unbox, scalar-replace, and use intrinsics only while preserving the canonical semantics.

Build controls

Project profiles select O0–O3, debug information, and floating contraction. Single-file builds accept --output, --entry, --backend native, and --fp-contract=off|fast.

Performance tests

./tests/run_awfy.sh
./tests/bench_native.sh 3

AWFY workloads and custom benchmarks verify exact results before timing. Timings exclude compilation where the runner specifies and record enough environment information to avoid treating noise as a language claim.

Writing predictable code

State numerical policies explicitly, use representations through checked repr mappings, prefer abstractions that permit specialization, and do not rely on current LLVM layout accidents. Semantic telescope arity and provider layout limits are distinct.

Future providers

.NET, JavaScript, accelerators, and other targets must consume the same verified RuntimeCore program. Provider-specific optimization is welcome; a second semantic compiler pipeline is not.

Common mistakes

Do not benchmark compilation when a runner promises execution-only timing, infer language semantics from today’s object layout, or use a native-only intrinsic where a portable algebra already expresses the operation.

Recap

Native compilation closes typing and evidence before lowering, optimizes one verified runtime core, and hands an environment-free artifact to LLVM. Future providers must enter at the same boundary.

Further details: Codegen Design, Compiled REPL, and LLVM Backend Design.