Implement more cases for "combine or" in OptimizeInstruction pass

[MaxGraey]

Added more peephole optimizations for "combine or"

• (x <=> y) | (x == y) → x <=> y
• (x < y) | (x > y) → x != y
• (x == y) | (x != y) → 1
• (x != y) | (x == y) → 1
• (x <= y) | (x > y) → 1
• (x < y) | (x >= y) → 1
• (x >= y) | (x <= y) → 1
• (x > y) | (x <= y) → 1
• (x >= y) | (x < y) → 1

relate to #1764

[tlively]

I think these optimizations could be much simpler to write if we had some nice template magic to abstract over the signedness and size of operations. Perhaps it's worth doing some up-front investment in that area?

[tlively]

I don't think this empty default case (or the ones below) should be necessary.

[MaxGraey]

Without this I can't compile due to -Werror,-Wswitch. But I'll use default: break instead

[tlively]

How are the left-side >= expressions handled? I don't see those cases below.

[MaxGraey]

Added

[tlively]

It looks like the tests didn't need updating, but I see a few examples in the tests with i32.ge_s on the left hand side. Were they somehow being handled already by previous code?

[MaxGraey]

My guess it swapped (canonize) by code earlier:

if (Properties::isSymmetric(binary)) {
  canonicalize(binary);
}

here: https://github.com/WebAssembly/binaryen/blob/master/src/passes/OptimizeInstructions.cpp#L348

[MaxGraey]

I think these optimizations could be much simpler to write if we had some nice template magic to abstract over the signedness and size of operations. Perhaps it's worth doing some up-front investment in that area?

Unfortunately in this case we can't use switch/case any more what could make stuffs more complicate for readability. Also such switch cases pretty fast in term of performance. Also I thought how we could automatize some pattern matching but if we will use de-morgan's laws it cover just minor part of x < y | x >= y and tree similar patterns and that's it. So I guess current solution near to optimal