Propose two enhancements:
- Shared heap created from preallocated memory buffer: The user can create a shared heap from a pre-allocated buffer and see that memory region as one large chunk; there's no need to dynamically manage it(malloc/free). The user needs to make sure the native address and size of that memory region are valid.
- Introduce shared heap chain: The user can create a shared heap chain, from the wasm app point of view, it's still a continuous memory region in wasm app's point of view while in the native it can consist of multiple shared heaps (each of which is a continuous memory region). For example, one 500MB shared heap 1 and one 500 MB shared heap 2 form a chain, in Wasm's point of view, it's one 1GB shared heap.
After these enhancements, the data sharing between wasm apps, and between hosts can be more efficient and flexible. Admittedly shared heap management can be more complex for users, but it's similar to the zero-overhead principle. No overhead will be imposed for the users who don't use the shared heap enhancement or don't use the shared heap at all.
It is reported as "Multiplication result converted to larger type".
And "Multiplication result may overflow 'Type A' before it is
converted to 'Type B'." Type A is a larger type than Type B.
Since the conversion applies after the multiplication, arithmetic
overflow may still occur.
> The rule flags every multiplication of two non-constant integer expressions
> that is (explicitly or implicitly) converted to a larger integer type. The
> conversion is an indication that the expression would produce a result that
> would be too large to fit in the smaller integer type.
- Change `WAMR_ENABLE_COPY_CALLSTACK` to `WAMR_BUILD_COPY_CALL_STACK`, as
`WAMR_BUILD` is the prefix for a command line option.
- Change `WAMR_ENABLE_COPY_CALLSTACK` to `WASM_ENABLE_COPY_CALL_STACK`, as
`WASM_ENABLE` is the prefix for a macro in the source code.
- Change `CALLSTACK` to `CALL_STACK` to align with the existing
`DUMP_CALL_STACK` feature.
- Continue using `WASMCApiFrame` instead of `wasm_frame_t` outside of
*wasm_c_api.xxx* to avoid a typedef redefinition warning, which is
identified by Clang.
* static PGO compatible with llvm18 and add CI job to test static PGO on coremark benchmark
* update comments and warning info, bitmaps section in llvm profdata shouldn't be used in PGO
* initialize WASI stdio handles to invalid for better error handling
* implement os_invalid_raw_handle function for consistent invalid handle representation
LLVM 16 and later expands cttz intrinsic to a table lookup,
which involves some relocations. (unless ZBB is available,
in which case the native instructions are preferred over
the table-based lowering.)
cf. https://reviews.llvm.org/D128911
the corresponding LLVM intrinsics' return types are same as
their first argument. eg. i64 for llvm.cttz.i64.
cf. https://llvm.org/docs/LangRef.html#llvm-cttz-intrinsic
this commit changes the return types of our versions of the
intrinsics to match llvm versions as our aot compiler,
specifically __call_llvm_intrinsic, assumes.
strictly speaking, this is a potential AOT ABI change.
however, I suppose it isn't a problem for many of 64-bit ABIs
out there, where (lower half of) a 64-bit register is used to
return a 32-bit value anyway. (for such ABIs, this commit
would fix the upper 32-bit value of the register.)
LLVM 19 and later started to use srodata ("small read only data")
sections for RISCV. cf. https://github.com/llvm/llvm-project/pull/82214
this commit makes our aot emitter/loader deal with those sections.
an alternative would be to disable small data sections completely by
setting the "SmallDataLimit" module attribute to zero. however, i feel
this commit is more straightforward and consisitent as we are already
dealing with sdata sections.
* Fix errors on the "i386-windows-msvc" platform
* Refactor symbol name handling for AOT COFF32 binary format
* Fix preprocessor directive placement for Windows compatibility in aot_reloc_x86_32.c
---------
Co-authored-by: liang.he@intel.com <liang.he@intel.com>
```
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
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
* Remove indirect-load for constants on Xtensa Target to improve performance
* Remove const intrinsics flags for xtensa instead of adding too much #ifdef
* Add AOT_INTRINSIC_FLAG_F32_CONST for xtensa frontend, because espressif xtensa llvm backend does not support float-point immediate for now
---------
Co-authored-by: zhanheng1 <Zhanheng.Qin@sony.com>
* Use CMAKE_INSTALL_BINDIR for wamrc installation
* Fix wamrc build failure for 32bit non-x86 targets
* Handle PIC flags by cmake in wamrc
* Use dummy AOT reloc functions when building wamrc
AOT reloc functions are used only when loading AOT WebAssembly modules
on target, not during AOT compilation. Original code led to build issues
when building wamrc as cross-compiler, using arm header on x86 build.
* Add option to turn off SIMD support in wamrc
