Wasmtime GitHub notifications bot (Jan 15 2026 at 23:04): Wasmtime GitHub notifications bot (Jan 15 2026 at 23:04):alexcrichton opened issue #12363:
This is an issue which proposes adding the concept of platform-defined intrinsics to Cranelift. This is in contrast to today's IR where any functionality must be modeled as a CLIF instruction with precise semantics. The downside of today's situation is that there's a loose expectation that all CLIF instructions are implemented on all platforms (in the limit at least). There are a variety of ways to achieve this and improve on the current situation, but this doesn't map well to a number of scenarios:
- There are preexisting instructions which are platform-specific, e.g.
x86_pshufb. These CLIF instructions have a clear semantic definition (aka "whatever x86 does") but no real viable path to implementation on other platforms. There's not much motivation to implement such intrinsics nor is there much tooling we have to ensure that all possible edge cases are handled in a theoretical non-native lowering.- Pulley has special opcodes for hostcalls which are modeled right now through relocations/call targets/etc but this is a bit kludge. It'd be nicer if the hostcall instruction was modeled as a function which proper arguments and such. This would help avoiding the need to shoehorn what Pulley does into CLIF.
- There are hypothetical instructions we'd want to add to Cranelift such as AES instructions which have subtly different semantics across architectures. A fallback for these to implement everywhere would be quite large and error prone, moreso than something low-level like
pshufb.Overall while a platform-defined intrinsic is not the best fit for all functionality I personally at least believe that it's a good fit for some functionality still. There's currently no real mechanism by which today Cranelift can support platform-specific intrinsics, and that's what this issue is proposing. What I'd roughly envision for something in Cranelift is along these lines:
- Perhaps a new
call_intrinsicinstruction in Cranelift which takes a name and arguments.- There is a list of all known intrinsics for all backends in Cranelift somewhere which would assist with validation of input IR. Validation would have the expected signature of the intrinsic which would be type-checked against the IR. Another possibility would be to update
TargetIsato have a list of intrinsics, and then CLIF validation would be target-specific (e.g. would use the list of intrinsics in aTargetIsafor validation of what intrinsics were found)- Lowering rules in each backend would have a rule-per-intrinsic which would delegate to the machine instruction as appropriate.
I'm not aware of a burning desire for any particular intrinsic at this time as most desirable instructions right now fit pretty well into CLIF as-is, but wanted to write down this issue nonetheless.
Wasmtime GitHub notifications bot (Jan 15 2026 at 23:04):alexcrichton added the cranelift label to Issue #12363.
Last updated: Jan 29 2026 at 13:25 UTC