LLVM 18 and later, instcombine perfoms only one iteration.
it performs extra "verify fixpoint" operation when instcombine
is specified in certain ways, including how we do so here.
a problem is that the verification raises a fatal error when it
finds we didn't reach a fixpoint:
LLVM ERROR: Instruction Combining did not reach a fixpoint
after 1 iterations
while it should be rare, it's quite normal not to reach a fixpoint.
this commit fixes the issue by simply disabing the verification.
cf. https://github.com/llvm/llvm-project/commit/41895843b5915bb78e9d02aa711fa10f7174db43
In call_wasm_with_hw_bound_check/call_native_with_hw_bound_check,
ensure to set up the stack boundary (wasm_exec_env_set_thread_info)
before checking the overflow.
It seems that the problem was introduced by:
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2940
This fixes link errors seen on my environment.
(macOS 15.2, x86-64, Xcode 16.2)
Tested as:
```
mkdir b
cd b
cmake -D WAMR_BUILD_JIT=1 -D LLVM_DIR=/usr/local/opt/llvm@19/lib/cmake/llvm ..
make
```
* Bump AOT_CURRENT_VERSION for WAMR 2.x (gc, memory64)
Maybe it's too late because we have already made a few releases
since then.
But this might still help users who haven't upgraded to WAMR 2.x yet.
Also, for the purpose of the versioning, it's safer to bump
needlessly than missing necessary bumps.
Fixes https://github.com/bytecodealliance/wasm-micro-runtime/issues/3837
* test-tools/aot-analyzer/include/config.h: bump AOT_CURRENT_VERSION
I'm not sure we want to use C99 %tu here.
While C99 %zu is more widely used in WAMR, %tu is rare (if any)
and I'm not sure if it's ubiquitously implemented in platforms
we support.
For JIT, we naturally use mach-o on macOS, where the section name
we currently use is not valid and ends up with the errors like:
```
LLVM ERROR: Global variable '__orc_lcl.aot_stack_sizes.0' has an invalid section specifier '.aot_stack_sizes': mach-o section specifier requires a segment and section separated by a comma.
```
Because the dedicated section is not necessary for JIT,
this commit simply stops using it.
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/3730
This allows users to specify llvm command line options, similarly to clang's -mllvm option.
My motivations:
* -debug and friends
* -mtext-section-literals for xtensa
The current coding assumes the tmp file is created in /tmp.
However,
* It's somewhere under /var/folders/... by default on macOS.
* A user can set TMPDIR.
The "handlers" on the interpreter stack is sometimes treated as
host pointers and sometimes treated as i64 values. It's quite broken
for targets where pointers are not 64-bit.
This commit makes them host pointers consistently. (at least for
32-bit and 64-bit pointers. We don't support other pointer
sizes anyway.)
Fixes https://github.com/bytecodealliance/wasm-micro-runtime/issues/3110
aot_load_const_from_table() hides the const-ness of the
value and prevents optimizations like
https://github.com/bytecodealliance/wasm-micro-runtime/pull/3552.
This commit makes the aot compiler tracks the const-ness
of the value directly in the AOTValue and enables the above
mentioned optimization for XIP.
* I believe that LLVM MemoryBuffer interface is supposed to be read-only
and it's allowed to use eg. read-only mmap of the underlying file.
It isn't appropriate to modify the view at all.
* in case of WASM_ENABLE_DEBUG_AOT, the whole buffer is written as the text
section of the aot file. the modified e_type would confuse dwarf consumers.
note that, even when we are using XIP, the debug info usually contains
relocations. for example, llvm-dwarfdump doesn't seem to perform relocations
on .debug_info section for ET_CORE (== 4 == our E_TYPE_XIP) objects.
Consider the following wasm module:
```wast
(module
(func (export "foo")
i32.const 0x104
i32.const 0x12345678
i32.store
)
(memory 1 1)
)
```
While the address (0x104) is perfectly aligned for i32.store,
as our aot compiler uses 1-byte alignment for load/store LLVM
IR instructions, it often produces inefficient machine code,
especially for alignment-sensitive targets.
For example, the above "foo" function is compiled into the
following xtensa machine code.
```
0000002c <aot_func_internal#0>:
2c: 004136 entry a1, 32
2f: 07a182 movi a8, 0x107
32: 828a add.n a8, a2, a8
34: 291c movi.n a9, 18
36: 004892 s8i a9, a8, 0
39: 06a182 movi a8, 0x106
3c: 828a add.n a8, a2, a8
3e: ffff91 l32r a9, 3c <aot_func_internal#0+0x10> (ff91828a <aot_func_internal#0+0xff91825e>)
3e: R_XTENSA_SLOT0_OP .literal+0x8
41: 004892 s8i a9, a8, 0
44: 05a182 movi a8, 0x105
47: 828a add.n a8, a2, a8
49: ffff91 l32r a9, 48 <aot_func_internal#0+0x1c> (ffff9182 <aot_func_internal#0+0xffff9156>)
49: R_XTENSA_SLOT0_OP .literal+0xc
4c: 41a890 srli a10, a9, 8
4f: 0048a2 s8i a10, a8, 0
52: 04a182 movi a8, 0x104
55: 828a add.n a8, a2, a8
57: 004892 s8i a9, a8, 0
5a: f01d retw.n
```
Note that the each four bytes are stored separately using
one-byte-store instruction, s8i.
This commit tries to use larger alignments for load/store LLVM IR
instructions when possible. with this commit, the above example is
compiled into the following machine code, which seems more reasonable.
```
0000002c <aot_func_internal#0>:
2c: 004136 entry a1, 32
2f: ffff81 l32r a8, 2c <aot_func_internal#0> (81004136 <aot_func_internal#0+0x8100410a>)
2f: R_XTENSA_SLOT0_OP .literal+0x8
32: 416282 s32i a8, a2, 0x104
35: f01d retw.n
```
Note: this doesn't work well for --xip because aot_load_const_from_table()
hides the constness of the value. Maybe we need our own mechanism to
propagate the constness and the value.
Probably it's better to skip the optimized out parameters.
(that is, parameters w/o locations)
However, I'm not sure how/if it can be done with the lldb api.
For now, just disable parameter processing to avoid crashes.
While band-aid fixes like this is not plausible IMO,
some people prefer to have some debug info even if it's
partial/limited/broken. This commit partially (re)enables
C++ processing. On the other hand, do not bother to process
variables because it's known incompatible with C++.
Although I don't know what exactly the esp32s3 rom version of memset is,
it seems that the current code crashes only with a small "len". I guess
it changes the logic depending on the size.
Anyway, it's safer to use dbus here.
- Add a few API (https://github.com/bytecodealliance/wasm-micro-runtime/issues/3325)
```c
wasm_runtime_detect_native_stack_overflow_size
wasm_runtime_detect_native_stack_overflow
```
- Adapt the runtime to use them
- Adapt samples/native-stack-overflow to use them
- Add a few missing overflow checks in the interpreters
- Build and run the sample on the CI
The old value (1KB) doesn't seem sufficient for many cases.
I suspect that the new value is still not sufficient for some cases.
But it's far safer than the old value.
Consider if the classic interpreter loop (2600 bytes) calls
host snprintf. (2000 bytes)
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/3314
This reverts commit 0e8d949440.
Because it doesn't make much sense anymore after we disabled debug info
processing on C++ functions in:
"aot debug: process lldb_function_to_function_dbi only for C".
This increases the chance to use "short" calls.
Assumptions:
- LLVM preserves the order of functions in a module
- The wrapper function are smaller than the wrapped functions
- The target CPU has "short" PC-relative variation of call/jmp instructions
and they are preferrable over the "long" ones.
A motivation:
- To avoid some relocations for XIP, I want to use xtensa PC-relative
call instructions, which can only reach ~512KB.
While we used a different approach for poll_oneoff [1],
the implementation works only when the poll list includes
an absolute clock event. That is, if we have a thread which is
polling on descriptors without a timeout, we fail to terminate
the thread.
This commit fixes it by applying wasm_runtime_begin_blocking_op
to poll as well.
[1] https://github.com/bytecodealliance/wasm-micro-runtime/pull/1951
Possible alternatives:
* Make wasm_cluster_destroy_spawned_exec_env take two exec_env.
One for wasm execution and another to specify the target to destroy.
* Make execute functions to switch exec_env as briefly discussed in
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2047
It seems that some users want to wrap rather large chunk of code
with wasm_runtime_begin_blocking_op/wasm_runtime_end_blocking_op.
If the wrapped code happens to have a call to
e.g. wasm_runtime_spawn_exec_env, WASM_SUSPEND_FLAG_BLOCKING is
inherited to the child exec_env and it may cause unexpected behaviors.
