-
Notifications
You must be signed in to change notification settings - Fork 695
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
cd3f420
to
344e74c
Compare
with llvm16:
with llvm15:
|
because of https://reviews.llvm.org/D128911 |
63d4bfc
to
74e00ab
Compare
for some reasons, it seems a few tests using llvm-jit are timed out on the ci. (ubuntu) |
where it stalls doesn't seem consistent. it used to be in Test_callback_chain, Test_memory. but now it's in Test_global, Test_hostref, Test_memory. |
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
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.
8fcbbc5
to
99160af
Compare
I use this patch test pass For windows, get this error with [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 for darwin [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 |
@calvin2021y |
I am build this PR with llvm19, and try run AOT app for linux/apple/windows platform. |
why? |
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.
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? |
i feel espressif/llvm-project#112 is a show blocker. what do you think? |
use use windows still get AOT module load failed: relocation truncated to fit IMAGE_REL_AMD64_ADDR32 failed. Try using wamrc with --size-level=1 option. |
after patch with #4092, windows
|
for now i gave up and submit an alternative with llvm 18: #4259 |
Should we close it or leave it open? |
leave it for a whlie. |
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.