[OptimizeInstructions] Combine extend to i64 and 32-bit load operations

[MaxGraey]

i64.extend_i32_u(i32.load8_u(x))   ->  i64.load8_u(x)
i64.extend_i32_u(i32.load16_u(x))  ->  i64.load16_u(x)

i64.extend_i32_s(i32.load8_u(x))   ->  i64.load8_u(x)
i64.extend_i32_s(i32.load16_u(x))  ->  i64.load16_u(x)
i64.extend_i32_s(i32.load8_s(x))   ->  i64.load8_s(x)
i64.extend_i32_s(i32.load16_s(x))  ->  i64.load16_s(x)

i64.extend_i32_u(i32.load(x)))  ->  i64.load32_u(x)
i64.extend_i32_s(i32.load(x)))  ->  i64.load32_s(x)

don't apply to

i64.extend_i32_u(i32.load8_s(x))   ->  skip
i64.extend_i32_u(i32.load16_s(x))  ->  skip
i64.extend_i32_s(i32.atomic.load(x))  ->  skip

[lexaknyazev]

Are you sure about these?

i64.extend_i32_u(i32.load8_s(x))   ->  i64.load8_s(x)
i64.extend_i32_u(i32.load16_s(x))  ->  i64.load16_s(x)

For example:

• 0xFF is loaded by i32.load8_s as 0xFFFFFFFF and i64.extend_i32_u produces 0x00000000FFFFFFFF.
• On the other hand, loading 0xFF with i64.load8_s returns 0xFFFFFFFFFFFFFFFF.

The same applies to the 16-bit case.

[MaxGraey]

@lexaknyazev Yes, such pairs of operations we should avoid

[MaxGraey]

Fuzzed ITERATION: 27789

[MaxGraey]

@tlively @kripken could take a look please?

[kripken]

Nice, looks good!

Please fuzz the last version, unless you already have?

[MaxGraey]

Ok, I'll refuzz this tomorrow

[MaxGraey]

Hmm, I got this:

[wasm-validator error in function 57] unexpected true: atomic loads must be unsigned, on 
(i64.atomic.load32_s offset=22
 (i32.and
  (i32.const -66)
  (i32.const 15)
 )
)

for seed 16896761022808288108

Upd: Oh atomics doesn't have sign extended versions for loads!
Upd Upd: Fixed!

[MaxGraey]

Refuzzed ITERATION: 17513