LLVM Route Signatures
Many Morph features eventually need to target the host LLVM route.
To do that correctly, package authors need to understand route signature metadata.
Real Route Fields
LLVM-backed route declarations commonly include fields such as:
provider_id = "provider.core.host_llvm"
route_id = "host.llvm"
artifact_kind = "host.llvm_value"
required_extensions = ["llvm.runtime_import.v1"]
required_runtime_families = ["tensor"]
These fields are not decoration. They are the route signature.
What Each Field Means
| Field | Meaning |
|---|---|
provider_id | which provider the route targets |
route_id | which backend route id is targeted (for example host.llvm) |
artifact_kind | what the route produces |
required_extensions | which backend host extensions must exist |
required_runtime_families | which runtime families must be available |
Required Extensions
Extensions tell the backend host which advanced capabilities a route expects.
Examples from the repo include:
llvm.base.v1llvm.numeric.v1llvm.runtime_import.v1
If the route requires an extension, that requirement should be declared in package metadata, not implied in source code comments.
Required Runtime Families
Runtime requirements are just as important.
If an LLVM route needs tensor or graphics runtime support, declare it explicitly with required_runtime_families.
That keeps route validation and failure modes explicit.
Signature Design Rule
If a route depends on:
- a provider
- a route id
- an artifact kind
- an extension
- a runtime family
declare all of it explicitly.
Do not rely on hidden defaults or core-owned assumptions.
Next Steps
- Runtime Families - the runtime side of route declarations
- Platform-Specific Lowering - real host vs GPU route splits
- Emit Walkthrough - what the backend emitter actually does
- Tooling Command APIs - another descriptor-heavy extension surface