LoopInvariantCodeMotion: struct.new is hoisted out of a loop, so all iterations share one object #9184

Summary

unsafeToMove does not treat an allocation as generative, so local.set $x (struct.new ...) is moved out of the loop and every iteration mutates the same object.

Root cause

struct.new is considered movable because it has no side effect on existing state, but it creates a new identity on each evaluation.

Affected passes

Only LoopInvariantCodeMotion. Allocations in other loop-hoisting code were not examined.

Reproducer

In C-like pseudo code, the function below is:

struct T { int f; };

int f(void) {
  struct T *x;
  int i = 0;
  do {
    x = new_T(0);   // a new object on every iteration
    x->f = x->f + 1;
    i = i + 1;
  } while (i < 2);
  return x->f;      // 1
}

After --licm, new_T(0) is moved above the loop, so both iterations update the same object and f returns 2:

  x = new_T(0);
  do {
    x->f = x->f + 1;
    i = i + 1;
  } while (i < 2);
  return x->f;      // 2

(module
  (type $T (struct (field (mut i32))))
  (func (export "f") (result i32)
    (local $x (ref null $T)) (local $i i32)
    (loop $l
      (local.set $x (struct.new $T (i32.const 0)))
      (struct.set $T 0 (local.get $x)
        (i32.add (struct.get $T 0 (local.get $x)) (i32.const 1)))
      (br_if $l (i32.lt_u (local.tee $i (i32.add (local.get $i) (i32.const 1))) (i32.const 2))))
    (struct.get $T 0 (local.get $x))))

$ wasm-opt in.wat --enable-gc --enable-reference-types --licm --fuzz-exec -o /dev/null
[fuzz-exec] export f
[fuzz-exec] note result: f => 1
[fuzz-exec] export f
[fuzz-exec] note result: f => 2
[fuzz-exec] comparing f
values not identical! 2 != 1
[fuzz-exec] optimization passes changed results

Expected vs actual

The original returns 1 (each iteration starts from a fresh object). After the pass the object is shared across the two iterations and the function returns 2.

Version

Reproduced on upstream main at 4d8ac549e2ab9b283246ea95e79ebe139ca579ac (wasm-opt version 133).

AI was used as part of the process of finding this issue. I have manually checked and reproduced it.