bytecodealliance
build-scripts/build_llvm.py: bump to llvm 19
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4210
why 19, not 20? because, as of writing this, 19 is the latest released version for the xtensa fork of llvm: https://github.com/espressif/llvm-project while we can use different versions for different targets, it's nicer to use the same version everywhere when possible.
wamrc --target=riscv32 --target-abi=ilp32 --cpu=generic-rv32 --cpu-features=+m,+a,+c --xip --bounds-checks=0 generates a few text relocations with llvm16 and later for the following module:
(module
(func (export "foo") (result i32)
i32.const 13
i32.ctz
)
)
with llvm16:
.text
.attribute 4, 16
.attribute 5, "rv32i2p0"
.file "WASM Module"
.section .rodata.cst32,"aM",@progbits,32
.LCPI0_0: # -- Begin function aot_func#0
.ascii "\000\001\034\002\035\016\030\003\036\026\024\017\031\021\004\b\037\033\r\027\025\023\020\007\032\f\022\006\013\005\n\t"
.text
.globl "aot_func#0"
.p2align 2
.type "aot_func#0",@function
"aot_func#0": # @"aot_func#0"
# %bb.0: # %func_end
addi sp, sp, -16
sw ra, 12(sp) # 4-byte Folded Spill
lw a0, 32(a0)
lw a0, 0(a0)
beqz a0, .LBB0_2
# %bb.1: # %cond.false
neg a1, a0
and a0, a0, a1
lui a1, 30667
addi a1, a1, 1329
call __mulsi3@plt
srli a0, a0, 27
lui a1, %hi(.LCPI0_0)
addi a1, a1, %lo(.LCPI0_0)
add a0, a1, a0
lbu a0, 0(a0)
j .LBB0_3
.LBB0_2: # %cond.end
li a0, 32
.LBB0_3: # %cond.end
lw ra, 12(sp) # 4-byte Folded Reload
addi sp, sp, 16
ret
.Lfunc_end0:
.size "aot_func#0", .Lfunc_end0-"aot_func#0"
# -- End function
.section ".note.GNU-stack","",@progbits
with llvm15:
.text
.attribute 4, 16
.attribute 5, "rv32i2p0"
.file "WASM Module"
.globl "aot_func#0" # -- Begin function aot_func#0
.p2align 2
.type "aot_func#0",@function
"aot_func#0": # @"aot_func#0"
# %bb.0: # %func_end
addi sp, sp, -16
sw ra, 12(sp) # 4-byte Folded Spill
lw a0, 32(a0)
lw a0, 0(a0)
beqz a0, .LBB0_2
# %bb.1: # %cond.false
addi a1, a0, -1
not a0, a0
and a0, a0, a1
srli a1, a0, 1
lui a2, 349525
addi a2, a2, 1365
and a1, a1, a2
sub a0, a0, a1
lui a1, 209715
addi a1, a1, 819
and a2, a0, a1
srli a0, a0, 2
and a0, a0, a1
add a0, a2, a0
srli a1, a0, 4
add a0, a0, a1
lui a1, 61681
addi a1, a1, -241
and a0, a0, a1
lui a1, 4112
addi a1, a1, 257
call __mulsi3@plt
srli a0, a0, 24
j .LBB0_3
.LBB0_2: # %cond.end
li a0, 32
.LBB0_3: # %cond.end
lw ra, 12(sp) # 4-byte Folded Reload
addi sp, sp, 16
ret
.Lfunc_end0:
.size "aot_func#0", .Lfunc_end0-"aot_func#0"
# -- End function
.section ".note.GNU-stack","",@progbits
wamrc --target=riscv32 --target-abi=ilp32 --cpu=generic-rv32 --cpu-features=+m,+a,+c --xip --bounds-checks=0generates a few text relocations with llvm16 and later for the following module:
because of https://reviews.llvm.org/D128911
for some reasons, it seems a few tests using llvm-jit are timed out on the ci. (ubuntu) i couldn't reproduce them on macOS.
for some reasons, it seems a few tests using llvm-jit are timed out on the ci. (ubuntu) i couldn't reproduce them on macOS.
where it stalls doesn't seem consistent.
it used to be in Test_callback_chain, Test_memory. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/14696495796/job/41264236395
but now it's in Test_global, Test_hostref, Test_memory. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/14870500344/job/41757793101?pr=4213
I use this patch test pass --invoke-c-api-import --enable-tail-call --format=aot --target=x86_64-pc-linux-gnu --enable-segue for linux.
For windows, get this error with --invoke-c-api-import --enable-tail-call --format=aot --target=x86_64-w64-windows-gnu: (x86_64-pc-windows-msvc has same result)
[06:27:37:277 - 7FF7666DA940]: Warning: loader mmap memory address is not in the first 2 Gigabytes of the process address space.
[06:27:37:282 - 7FF7666DA940]: Warning: loader mmap memory address is not in the first 2 Gigabytes of the process address space.
[06:27:37:287 - 7FF7666DA940]: Warning: loader mmap memory address is not in the first 2 Gigabytes of the process address space.
[06:27:37:291 - 7FF7666DA940]: the buffer is not ELF entry!
[06:27:37:293 - 7FF7666DA940]: Warning: loader mmap memory address is not in the first 2 Gigabytes of the process address space.
[06:27:37:298 - 7FF7666DA940]: wamr\core\iwasm\common\wasm_runtime_common.c, line 1498, WASM module load failed
[06:27:37:301 - 7FF7666DA940]: AOT module load failed: relocation truncated to fit IMAGE_REL_AMD64_ADDR32 failed. Try using wamrc with --size-level=1 option.
[06:27:37:306 - 7FF7666DA940]: wasm_module_new_ex failed
change -size-level=1 not fix the problem, -size-level=0 get crash.
for darwin --invoke-c-api-import --enable-tail-call --format=aot --target=x86_64-apple-darwin --enable-segue:
[00:16:33:841 - 7FF84AE43BC0]: the buffer is not ELF entry!
[00:16:33:843 - 7FF84AE43BC0]: wamr/core/iwasm/common/wasm_runtime_common.c, line 1498, WASM module load failed
[00:16:33:843 - 7FF84AE43BC0]: AOT module load failed: relocation truncated to fit R_X86_64_32S failed. Try using wamrc with --size-level=1 or 0 option.
[00:16:33:843 - 7FF84AE43BC0]: wasm_module_new_ex failed
for a simple fib number without wasi, all 3 platform work ok.
fresh build from https://github.com/bytecodealliance/wasm-micro-runtime/commit/0e8b57d8a8af644cc44bc3f0f44ed78d409c834c
@calvin2021y i'm not sure what you are trying with this PR. can you give me a context?
I am build this PR with llvm19, and try run AOT app for linux/apple/windows platform.
I am build this PR with llvm19, and try run AOT app for linux/apple/windows platform.
why? are you trying to find out regressions?
I am not try find out regressions, this is my first time to try this combination.
for some reasons, it seems a few tests using llvm-jit are timed out on the ci. (ubuntu) i couldn't reproduce them on macOS.
where it stalls doesn't seem consistent.
it used to be in Test_callback_chain, Test_memory. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/14696495796/job/41264236395
but now it's in Test_global, Test_hostref, Test_memory. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/14870500344/job/41757793101?pr=4213
it seems the stall was due to an unrelated bug. (a proposed fix: https://github.com/bytecodealliance/wasm-micro-runtime/pull/4252)
i don't know how llvm-19 exposed the issue though. maybe heap activities in a bad timing?
i feel https://github.com/espressif/llvm-project/issues/112 is a show blocker. what do you think?
use --invoke-c-api-import --enable-tail-call --format=aot --target=x86_64-pc-linux-gnu --opt-level=1 --size-level=0 work for apple x64 aot.
use --invoke-c-api-import --enable-tail-call --format=aot --target=aarch64v8.5-unknown-linux-android for apple arm64 aot.
windows still get Segmentation fault for --size-level=0, use --size-level=1 get this:
AOT module load failed: relocation truncated to fit IMAGE_REL_AMD64_ADDR32 failed. Try using wamrc with --size-level=1 option.
after patch with https://github.com/bytecodealliance/wasm-micro-runtime/pull/4092, windows --size-level=0 not Segmentation fault at start but after finish run.
--size-level=1 still get AOT module load failed: relocation truncated to fit IMAGE_REL_AMD64_ADDR32 failed. Try using wamrc with --size-level=1 option. error like apple x64.
i feel espressif/llvm-project#112 is a show blocker. what do you think?
for now i gave up and submit an alternative with llvm 18: https://github.com/bytecodealliance/wasm-micro-runtime/pull/4259
Should we close it or leave it open?
leave it for a whlie. let's see how long https://github.com/espressif/llvm-project/issues/112 takes.
why 19, not 20? because, as of writing this, 19 is the latest released version for the xtensa fork of llvm: https://github.com/espressif/llvm-project while we can use different versions for different targets, it's nicer to use the same version everywhere when possible.
the espressif fork of llvm is now swiching their dev branch to llvm 20. hopefully we can use it for the next attempt.