Fuse i64.{and,or,xor} + i64.eqz + i32.eqz + br_if

[Robbepop]

The instruction sequence

i64.{and,or,xor}
i64.eqz
i32.eqz
{if, br_if}

Is very common. The i64.eqz, i32.eqz sequence acts as a double negative, thus nullifying itself. It exists for the purpose of casting the i64 into a i32 which the Wasm validation expects by if and br_if to form something like if and(a, b) where a and b are both i64 typed values.

This requires addition of the following wasmi IR instructions:

New compute instructions for the intermediate fuse steps:

• i64.and_eqz
• i64.and_eqz_imm16
• i64.or_eqz
• i64.or_eqz_imm16
• i64.xor_eqz
• i64.xor_eqz_imm16

New branch instructions:

• i64.branch_and_eqz
• i64.branch_and_eqz_imm16
• i64.branch_or_eqz
• i64.branch_or_eqz_imm16
• i64.branch_xor_eqz
• i64.branch_xor_eqz_imm16

This should be benchmarks thoroughly since it might well be that the addition of this optimization might degrade wasmi performance instead of acting as an optimization.

[OLUWAMUYIWA]

Would love to take this up

[Robbepop]

I already did this experimentally and didn't see great results so I concluded that this optimization is either not worth it or my implementation was doing something wrong. So please if you want to take this be prepared that it won't get merged in case you see similar results.

In constrast to the i32 version of this optimization we see far fewer occurrences in compiled Wasm binaries. One reason for this is that all conditionals return a i32 value and thus chaining is simply not a thing for i64 instructions.

But even if your PR does not yield great results either it is probably a good exercise.

[OLUWAMUYIWA]

Hmm. Thanks for the heads up!
I'm still going to try it though.