Skip to content

build-scripts/build_llvm.py: bump to llvm 19 #4213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

yamt
Copy link
Collaborator

@yamt yamt commented Apr 25, 2025

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

Copy link
Collaborator

@lum1n0us lum1n0us left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@yamt
Copy link
Collaborator Author

yamt commented May 1, 2025

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
Copy link
Collaborator Author

yamt commented May 1, 2025

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 yamt force-pushed the llvm-19 branch 6 times, most recently from 63d4bfc to 74e00ab Compare May 2, 2025 08:55
@yamt
Copy link
Collaborator Author

yamt commented May 2, 2025

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
Copy link
Collaborator Author

yamt commented May 6, 2025

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

yamt added 5 commits May 7, 2025 13:16
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
yamt added 5 commits May 7, 2025 13:16
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
@yamt yamt force-pushed the llvm-19 branch 2 times, most recently from 8fcbbc5 to 99160af Compare May 7, 2025 04:52
@calvin2021y
Copy link

calvin2021y commented May 7, 2025

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
Copy link
Collaborator Author

yamt commented May 7, 2025

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

@calvin2021y
Copy link

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

@yamt
Copy link
Collaborator Author

yamt commented May 7, 2025

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
Copy link

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
Copy link
Collaborator Author

yamt commented May 7, 2025

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
Copy link
Collaborator Author

yamt commented May 7, 2025

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

@calvin2021y
Copy link

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
Copy link

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.

@yamt
Copy link
Collaborator Author

yamt commented May 8, 2025

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
Copy link
Collaborator

Should we close it or leave it open?

@yamt
Copy link
Collaborator Author

yamt commented May 12, 2025

Should we close it or leave it open?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

llvm versions we use doesn't build with the latest Xcode
3 participants