OptimizeInstructions: Eq64 of 0 => Eqz64 #2421
Conversation
| @@ -1312,6 +1312,8 @@ struct OptimizeInstructions | |||
| !EffectAnalyzer(getPassOptions(), binary->left) | |||
| .hasSideEffects()) { | |||
| return binary->right; | |||
| } else if (binary->op == EqInt64) { | |||
| return Builder(*getModule()).makeUnary(EqZInt64, binary->left); | |||
There was a problem hiding this comment.
Where is this optimization done for i32.eqz? I would expect this optimization to be organized to be symmetrically located with the i32 version.
There was a problem hiding this comment.
The other one appears to be here:
binaryen/src/passes/OptimizeInstructions.cpp
Line 373 in 7fa8c78
There was a problem hiding this comment.
Yeah, this is not structured in a very symmetrical way atm. It grew organically + some thoughts about checking common patterns early. So i32.eqz is much more common than i64.eqz, and hence they are differently located. It's very possible that's not worth it, and this should be refactored.
| (local.get $0) | ||
| (i64.const 0) | ||
| (i32.eqz | ||
| (i64.eqz |
There was a problem hiding this comment.
It seems i32.eqz i64.eqz could be eliminate at all for CFG operands
There was a problem hiding this comment.
What do you mean by "CFG" here?
There was a problem hiding this comment.
I meant arguments for control operations like if (i64) but I forgot that if should be accept only i32 input argument, so series of eqz may be better than i64.ne + i64.const 0
Fixes #2417
cc @dcodeIO