Enable aot compiler and jit based on llvm-14.0 and llvm-15.0git,
replace LLVMBuildLoad/LLVMBuildInBoundsGEP/LLVMBuildCall with
LLVMBuildLoad2/LLVMBuildInBoundsGEP2/LLVMBuildCall2, and pass
them with related types, so as to meet the requirements of opaque
pointers.
And fix several compilation errors for llvm-14.0/15.0git.
Most spec cases and standalone cases are tested.
When WAMR_BUILD_TARGET isn't set, choosing right target is decided
by checking `CMAKE_SIZEOF_VOID_P` variable. However, choosing `X86_32`
target is not doing specifically checking size of void pointer. It is kind
a fallback target for others.
This patch explicitly checks the size of void pointer before setting the target
to `X86_32` to fix the issue.
Fix the following warning introduced by the recent change.
```
In file included from wamr/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/locking.h:17,
from wamr/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.h:18,
from wamr/core/iwasm/aot/../common/wasm_runtime_common.h:18,
from wamr/core/iwasm/aot/aot_runtime.h:10,
from wamr/core/iwasm/aot/aot_loader.c:6:
wamr/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/ssp_config.h:55: error: "CONFIG_HAS_ISATTY" redefined [-Werror]
#define CONFIG_HAS_ISATTY 1
In file included from wamr/core/shared/utils/../platform/include/platform_common.h:13,
from wamr/core/shared/utils/bh_platform.h:9,
from wamr/core/iwasm/aot/aot_runtime.h:9,
from wamr/core/iwasm/aot/aot_loader.c:6:
wamr/core/shared/platform/nuttx/platform_internal.h:75: note: this is the location of the previous definition
#define CONFIG_HAS_ISATTY 0
```
When using clang compiler, the f32/f64 return value might be
invalid when calling invokeNative asm code. Declare the return
type of invokeNative as void, and set volatile for the converted
function pointers to resolve the issue.
Enable dump call stack to a buffer, use API
`wasm_runtime_get_call_stack_buf_size` to get the required buffer size
and use API
`wasm_runtime_dump_call_stack_to_buf` to dump call stack to a buffer
Support integrating 3rd-party toolchain llc compiler or asm compiler
into wamrc by setting environment variable WAMRC_LLC_COMPILER
or WAMRC_ASM_COMPILER, wamrc will use these tools to generate
object file from LLVM IR firstly, and then refactor the object file into
aot file.
Move jit spill cache to the end of interp frame to reduce footprint
Fix codegen compare float issue: should not overwritten the source registers
Fix float to int conversion check integer overflow issue
Unify the float compare
Fix get_global issue
- use native functions to do f.eq and f.ne
- only use ZF=0 and CF=0 to do f.lt and f.gt
- only use CF=0 to do f.le and f.ge
could use comiss and setCC to replace comiss and jmpCC
be able to pass f32_cmp and f64_cmp
```
cmp_eq:
xor eax, eax
ucomisd xmm0, xmm1
mov edx, 0
setnp al
cmovne eax, edx
ret
cmp_ne:
xor eax, eax
ucomisd xmm0, xmm1
mov edx, 1
setp al
cmovne eax, edx
ret
```
Implement Go binding APIs of runtime, module and instance
Add sample, build scripts and update the document
Co-authored-by: venus-taibai <97893654+venus-taibai@users.noreply.github.com>
In one instruction, if one or multiple operands tending to lock some
hardware registers in IR phase, like EAX, EDX for DIV, ECX for SHIFT,
it leads to two known cases.
case 1: allocate VOID
`SHRU i250,i249,i3`. if pr_3 was allocated to vr_249 first, incoming
allocation of vr_3 leads a spill out of `vr_249` and clear the value
of `vr->hreg` of vr_249. When applying allocation result in FOREACH
in L732, a NULL will be assigned to.
case 2: unexpected spill out
`DIV_U i1,i1,i44`. if allocation of vr_44 needs to spill out one
hardware register, there is a chance that `hr_4` will be selected.
If it happens, codegen will operate EDX and overwrite vr_44 value.
The reason of how `hr_4` will be spilled out is a hidden bug that
both information of `rc->hreg[]` and `rc->vreg` can be transfered
from one block to the next one. It means even there is no vr binds
to a hr in current block, the hr may still be thought as a busy one
becase of the left infroamtion of previous blocks
Workaround for cases:
- Add `MOV LOCKED_hr LOCKED_hr` just after the instruction. It prevents
case 1
- Add `MOV LOCKED_hr LOCKED_hr` just before the instruction. It prevents
case 2
This header file is supposed to be used by user code, which is not
a part of WAMR. Usually WAMR configuration is not available there,
remove DEBUG_INTERP macro control in it.
