Stream: git-wasmtime

Topic: wasmtime / issue #10641 Use "builtins" instead of "libcal...

Wasmtime GitHub notifications bot (Apr 22 2025 at 18:43):

Destructor17 opened issue #10641:

Feature

Currently Cranelift emits "libcalls" for float-to-int conversion on baseline x86_64.
It is a problem because libcalls require relocation, but relacations are not possible for externally owned code memory.
The idea is to let people to prohibit compiler from emitting libcalls even on baseline x86_64 by using "builtins".

Benefit

This feature would allow to freely use wasmtime::CustomCodeMemory without fear of "Unable to apply relocations to readonly MmapVec" error.
It is especially useful for scenarios described in https://github.com/bytecodealliance/wasmtime/issues/7777

Implementation

First approach is to completely replace "libcalls" with "builtins".
AFAIK builtins do the same libcalls do, but require no relocations, passes vmcontext and may trap, so I bet they are a bit slower then libcalls.

Builtins are already used for some atomic operations, memory growth, GC and many other things, while libcalls are used only in rare cases for f32/f64 rounding and X86Pshufb (whatever it is).

Note that this approach may brake non-Wasmtime usecases of Cranelift, so maybe alternative approach makes more sense.

Alternatives

Alternatively we can add new entry in wasmtime::Config to allow programmers to choose weather builtins or libcalls variants will be used when needed.
This approach is more complicated, but will not add any overhead if replacement is not needed.

Wasmtime GitHub notifications bot (Apr 22 2025 at 19:27):

alexcrichton commented on issue #10641:

If the CPU you're running code on has various SSE3+ proposals you can also use Config::cranelift_flag_enable to enable those and avoid the use of libcalls. If it doesn't though and you need the libcalls then this change is part of https://github.com/bytecodealliance/wasmtime/pull/9093 where libcalls are avoided entirely in Wasmtime, as you suggest (and also removes the relocation handling path entirely as a result)

Wasmtime GitHub notifications bot (Apr 24 2025 at 17:36):

alexcrichton closed issue #10641:

Feature

Currently Cranelift emits "libcalls" for float-to-int conversion on baseline x86_64.
It is a problem because libcalls require relocation, but relacations are not possible for externally owned code memory.
The idea is to let people to prohibit compiler from emitting libcalls even on baseline x86_64 by using "builtins".

Benefit

This feature would allow to freely use wasmtime::CustomCodeMemory without fear of "Unable to apply relocations to readonly MmapVec" error.
It is especially useful for scenarios described in https://github.com/bytecodealliance/wasmtime/issues/7777

Implementation

First approach is to completely replace "libcalls" with "builtins".
AFAIK builtins do the same libcalls do, but require no relocations, passes vmcontext and may trap, so I bet they are a bit slower then libcalls.

Builtins are already used for some atomic operations, memory growth, GC and many other things, while libcalls are used only in rare cases for f32/f64 rounding and X86Pshufb (whatever it is).

Note that this approach may brake non-Wasmtime usecases of Cranelift, so maybe alternative approach makes more sense.

Alternatives

Alternatively we can add new entry in wasmtime::Config to allow programmers to choose weather builtins or libcalls variants will be used when needed.
This approach is more complicated, but will not add any overhead if replacement is not needed.

Wasmtime GitHub notifications bot (Apr 24 2025 at 17:36):

alexcrichton commented on issue #10641:

Done in https://github.com/bytecodealliance/wasmtime/pull/10657 (thanks @sunfishcode!)

Last updated: Dec 06 2025 at 07:03 UTC