bug: AOT compiler wrongly optimizes invalid loads

[candymate]

Summary

AOT compiler wrongly optmizes invalid loads. When loads with invalid offsets are in the execution path, the program should trap with "out of bound memory access". However, due to optimizations, this kind of trap is not occurred.

(module
  (type (;0;) (func (result i32)))
  (func (;0;) (type 0) (result i32)
    i64.const 0xcafebabe
    i32.const 0xdeadbeef
    i64.load8_s
    i64.eq)
  (memory (;0;) 1)
  (export "mem" (memory 0))
  (export "main" (func 0)))

In this example, the trap should occur due to invalid load of i32.const 0xdeadbeef and i64.load8_s. However, the trap does not occur when optimization is applied.

Current State

We can compare two optimization levels on AOT compiler.

$ wasmedge/bin/wasmedgec --optimize 0 test.wasm test.so; wasmedge/bin/wasmedge test.so main
[2024-04-19 08:26:08.995] [info] compile start
[2024-04-19 08:26:08.996] [info] verify start
[2024-04-19 08:26:08.996] [info] optimize start
[2024-04-19 08:26:08.997] [info] codegen start
[2024-04-19 08:26:08.998] [info] output start
[2024-04-19 08:26:09.001] [info] compile done
[2024-04-19 08:26:09.017] [error] execution failed: out of bounds memory access, Code: 0x88
[2024-04-19 08:26:09.017] [error]     When executing function name: "main"

$ wasmedge/bin/wasmedgec --optimize 1 test.wasm test.so; wasmedge/bin/wasmedge test.so main
[2024-04-19 08:26:13.799] [info] compile start
[2024-04-19 08:26:13.799] [info] verify start
[2024-04-19 08:26:13.799] [info] optimize start
[2024-04-19 08:26:13.802] [info] codegen start
[2024-04-19 08:26:13.804] [info] output start
[2024-04-19 08:26:13.808] [info] compile done
0

Expected State

The correct result comes from -O0. The program should trap.

Reproduction steps

• Download the release version of wasmedge
• Run wasmedgec to get AOT compiled .so, run the .so with wasmedge runtime
• Give optimization levels differently using --optimize option for wasmedgec

Screenshots

Any logs you want to share for showing the specific issue

No response

Components

CLI

WasmEdge Version or Commit you used

0.13.5

Operating system information

Ubuntu 22.04

Hardware Architecture

x86_64

Compiler flags and options

Using the release version of wasmedge 0.13.5 - see above

[suryyyansh]

I looked into this using wasmedge --dump to check the llvm IR being generated for the -O0 and -O1 options. It seems that the replacement of the load instruction with a load volatile instruction in the -O1 is what's causing the difference in memory access checks.

@hydai I checked the compiler.cpp file, it seems there are no wasmedge-specific optimizations happening here. How would we go about preventing this "optimization" from happening? Or is there a better approach for analyzing and preventing this behavior?