[OptimizeInstructions] Combine some relational ops joined Or/And

[MaxGraey]

(i32(x) >= 0) & (i32(y) >= 0)   ==>   i32(x | y) >= 0
(i64(x) >= 0) & (i64(y) >= 0)   ==>   i64(x | y) >= 0

(i32(x) >= 0) | (i32(y) >= 0)   ==>   i32(x & y) >= 0
(i64(x) >= 0) | (i64(y) >= 0)   ==>   i64(x & y) >= 0

(i32(x) == -1) & (i32(y) == -1)   ==>   i32(x & y) == -1
(i64(x) == -1) & (i64(y) == -1)   ==>   i64(x & y) == -1

(i32(x) != -1) | (i32(y) != -1)   ==>   i32(x & y) != -1
(i64(x) != -1) | (i64(y) != -1)   ==>   i64(x & y) != -1

Done:

(i32(x) == 0) & (i32(y) == 0)   ==>   i32(x | y) == 0
(i64(x) == 0) & (i64(y) == 0)   ==>   i64(x | y) == 0

(i32(x) != 0) | (i32(y) != 0)   ==>   i32(x | y) != 0
(i64(x) != 0) | (i64(y) != 0)   ==>   i64(x | y) != 0

(i32(x) < 0) | (i32(y) < 0)   ==>   i32(x | y) < 0
(i64(x) < 0) | (i64(y) < 0)   ==>   i64(x | y) < 0

(i32(x) < 0) & (i32(y) < 0)   ==>   i32(x & y) < 0
(i64(x) < 0) & (i64(y) < 0)   ==>   i64(x & y) < 0

[MaxGraey]

Fuzzed ITERATION: 10577

[MaxGraey]

Refuzzed: ITERATION: 11631

[kripken]

There are several optimization-related PRs from you @MaxGraey . To organize things, how about opening an issue with a list of them, in the order of most important to review? I think that would make things simpler and more efficient, for me at least.

[MaxGraey]

@kripken Sure. I will

[kripken]

This is quite a lot of independent patterns in one PR. How about creating a separate PR for each pattern? Some closely-related ones might make sense together in a PR, but when the code for patterns is completely separate then separate PRs is better I think.

[MaxGraey]

Hmm, they are all very similar. But I could split this into two separate PRs. Will that be enough? Breaking it down into 9 PRs would be too costly, both in terms of review and fuzzing

[kripken]

In terms of review, it will be far faster for me if you split it up. The problem with large PRs is that one change ends up causing me to re-read the whole thing.

In terms of fuzzing, I think it's good enough if you've fuzzed them all together here, and don't do any more fuzzing in the new PRs (not unless we actually make significant changes to the logic).

9 PRs would be the right thing, I think. That will be the fastest to review, but even more importantly, it will be the best in terms of bisection. Small commits is the least risky approach, especially with patterns like these where it's possible to miss a corner case. It is a little more work to open the PRs, but I think it is worth it.

[MaxGraey]

Alright. I started here: #4333