build-scripts/build_llvm.py: bump to llvm 19 by yamt · Pull Request #4213 · bytecodealliance/wasm-micro-runtime

yamt · 2025-04-25T01:32:34Z

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.

lum1n0us

LGTM

yamt · 2025-05-01T08:04:25Z

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

yamt · 2025-05-01T09:06:47Z

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:

because of https://reviews.llvm.org/D128911

yamt · 2025-05-02T09:46:14Z

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.

yamt · 2025-05-06T23:34:42Z

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

cf. bytecodealliance#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.

with the recent version of LLVM, wamrc --size-level=1 often generates R_X86_64_32S relocations which fail on load with the infamous error: "relocation truncated to fit R_X86_64_32S failed" it seems that these relocations are often for jump tables. this commit workarounds it with --size-level=0. an alternative is to disable jump tables. (although it seems that jump tables are not the only source of these relocations.) cf. bytecodealliance#3035 it might be better to do this in wamrc itself. however, currently target info is not available there in case of native compilation. related: bytecodealliance#3356

cf. bytecodealliance#3035

cf. llvm/llvm-project#95031 llvm/llvm-project#89693

I observed errors like the following when trying to upgrade our LLVM from 15 to 19. ``` AOT module load failed: resolve symbol .srodata.cst8 failed ``` The concept itself has been available since LLVM 9. I don't know what exactly happened to trigger the use of it. cf. https://reviews.llvm.org/D57493

This reverts commit 6b7ff69.

This reverts commit 6ae395a.

calvin2021y · 2025-05-07T06:32:14Z

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 0e8b57d

yamt · 2025-05-07T06:45:46Z

@calvin2021y
i'm not sure what you are trying with this PR.
can you give me a context?

calvin2021y · 2025-05-07T06:50:04Z

I am build this PR with llvm19, and try run AOT app for linux/apple/windows platform.

yamt · 2025-05-07T06:56:11Z

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?

calvin2021y · 2025-05-07T07:12:00Z

I am not try find out regressions, this is my first time to try this combination.

in case of WASM_ENABLE_LAZY_JIT==0, compile_jit_functions should have already joined these threads. joining them again here is an undefined behavior.

yamt · 2025-05-07T09:36:14Z

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: #4252)

i don't know how llvm-19 exposed the issue though. maybe heap activities in a bad timing?

yamt · 2025-05-07T10:05:43Z

i feel espressif/llvm-project#112 is a show blocker. what do you think?

calvin2021y · 2025-05-07T13:25:10Z

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.

calvin2021y · 2025-05-07T18:22:47Z

after patch with #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.

core/iwasm/interpreter/wasm_loader.c

yamt · 2025-05-08T08:03:00Z

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: #4259

lum1n0us · 2025-05-12T02:24:30Z

Should we close it or leave it open?

yamt · 2025-05-12T02:50:09Z

Should we close it or leave it open?

leave it for a whlie.
let's see how long espressif/llvm-project#112 takes.

yamt · 2025-07-11T04:57:59Z

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.

yamt force-pushed the llvm-19 branch from 0bdfa28 to 0cad7b7 Compare April 25, 2025 02:40

lum1n0us previously approved these changes Apr 25, 2025

View reviewed changes

yamt force-pushed the llvm-19 branch from 7d15e12 to 37487ea Compare April 25, 2025 04:35

This was referenced Apr 25, 2025

LLVM: don't verify instcombine fixpoint #4219

Merged

LLVMCreateTargetMachineWithOpts: disable large data #4220

Merged

lum1n0us mentioned this pull request Apr 27, 2025

Update version to 2.3.0 #4171

Merged

yamt force-pushed the llvm-19 branch 3 times, most recently from cd3f420 to 344e74c Compare May 1, 2025 00:04

yamt mentioned this pull request May 1, 2025

symbol '.LCPI0_0' is already defined (LLVM-442) espressif/llvm-project#112

Closed

3 tasks

yamt force-pushed the llvm-19 branch 6 times, most recently from 63d4bfc to 74e00ab Compare May 2, 2025 08:55

lum1n0us linked an issue May 5, 2025 that may be closed by this pull request

llvm versions we use doesn't build with the latest Xcode #4210

Closed

This was referenced May 6, 2025

wamrc CommandLine Error: Option 'o' registered more than once! #4246

Closed

add x86_64-w64-windows-gnu/aarch64-w64-windows-gnu/i686-w64-windows-gnu aot triple support #4103

Closed

yamt force-pushed the llvm-19 branch from 74e00ab to c2df008 Compare May 6, 2025 21:57

yamt force-pushed the llvm-19 branch from c2df008 to e114bcc Compare May 6, 2025 23:45

yamt added 5 commits May 7, 2025 13:16

wamr-compiler: size_level=0 for sgx mode

b8bd1ef

cf. bytecodealliance#3035

aot_resolve_object_relocation_group: adapt to LLVM 19

4d73ab0

cf. llvm/llvm-project#95031 llvm/llvm-project#89693

wamr-test-suites: disable xtensa text section literals for now

0c9dd5a

yamt added 5 commits May 7, 2025 13:16

Revert "wamr-test-suites: disable xtensa text section literals for now"

db6ea1d

This reverts commit 6b7ff69.

spec_test_on_nuttx.yml: disable xtensa xip

26c35cb

Revert "aot_create_comp_context: disable small data section"

0df6dc4

This reverts commit 6ae395a.

CI: make macos' build_samples_wasm_c_api similar to ubuntu

0860d7f

yamt force-pushed the llvm-19 branch 2 times, most recently from 8fcbbc5 to 99160af Compare May 7, 2025 04:52

JIT: don't join worker threads twice

10e7fb7

in case of WASM_ENABLE_LAZY_JIT==0, compile_jit_functions should have already joined these threads. joining them again here is an undefined behavior.

yamt force-pushed the llvm-19 branch from 270d7b8 to 10e7fb7 Compare May 7, 2025 09:16

lum1n0us reviewed May 8, 2025

View reviewed changes

core/iwasm/interpreter/wasm_loader.c Show resolved Hide resolved

TianlongLiang mentioned this pull request May 30, 2025

Static PGO SEGFAULTS with WAMR-2.3.0 #4293

Closed

yamt dismissed lum1n0us’s stale review via 10e7fb7 October 20, 2025 05:36

psilva261 mentioned this pull request Dec 19, 2025

Add riscv-wamr-qemu platform eth-act/wasrisc#3

Merged

Conversation

yamt commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lum1n0us left a comment

Choose a reason for hiding this comment

Uh oh!

yamt commented May 1, 2025

Uh oh!

yamt commented May 1, 2025

Uh oh!

yamt commented May 2, 2025

Uh oh!

yamt commented May 6, 2025

Uh oh!

calvin2021y commented May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yamt commented May 7, 2025

Uh oh!

calvin2021y commented May 7, 2025

Uh oh!

yamt commented May 7, 2025

Uh oh!

calvin2021y commented May 7, 2025

Uh oh!

yamt commented May 7, 2025

Uh oh!

yamt commented May 7, 2025

Uh oh!

calvin2021y commented May 7, 2025

Uh oh!

calvin2021y commented May 7, 2025

Uh oh!

Uh oh!

yamt commented May 8, 2025

Uh oh!

lum1n0us commented May 12, 2025

Uh oh!

yamt commented May 12, 2025

Uh oh!

yamt commented Jul 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yamt commented Apr 25, 2025 •

edited

Loading

calvin2021y commented May 7, 2025 •

edited

Loading