what the heck

That looks bigger than it's supposed to be.

Also, it looks like produces a lot of unnecessary extra locals which do only local.set $x / local.get $x sequentially and nothing more

@CountBleck @MaxGraey
Thank you for review. I also agree that this fix is not very beautiful. But unfortunately, after aligned with @HerrCai0907, we think there is no way better than this, except we make big refactor on current code.

This bug can be easily fixed as supposed because current compile flow emit instruction as pesudo code

setter(this, indexStatement, getter(indexStatement));

The problem here is, assemblyscript + binary organize statements as tree and compiles from top to down. When compile the setter function, the getter(indexStatement) is just a statement. The compiler can't easily know there is a common indexStatement which need to be compiled in advanced.

To fix this bug, we need

index = indexStatement;
tmp = getter(index)
setter(this, index, tmp);

To achieve this, we need to hack a bit into the compiled getter(indexStatement). Otherwise, in assemblyscript's top down compile flow, it's difficult to let indexStatement be compiled in advanced.

This also explained by additional temps are created. But this shall not be a big problem because binary optimization pass can remove them.

I think it is a more generic issue for compound assignment instead of only for IndexSignature

This code will call getA() twice.

class A {
  a: i32 = 0;
}

function getA(): A {
  trace("get A");
  return new A();
}

export function _start(): void {
  getA().a |= 10;
}

Unless someone else finds a cleaner alternative to whatever this mess¹ is, this is something I'll definitely have to look into myself, once I have the time.

Heacking the previsouly generated IR problem is solved, which makes the commit clearer. But this still can't solve the getA().a |= 10; problem. So I didn't update this to PR. I will also think about a better solution.
Changqing-JING@a3cb730