Fuzz wide arithmetic instructions

[stevenfontanella]

Part of #8544. Continued in #8781.

Drive-by fix: ensure that tuples aren't generated with a size larger than TUPLE_MAX_SIZE:

-  size_t maxElements = 2 + upTo(fuzzParams->MAX_TUPLE_SIZE - 1);
+  size_t maxElements = 2 + upTo(fuzzParams->MAX_TUPLE_SIZE - 2);

After increasing the seed file size, the wide arithmetic instructions were generated (ctrl + f "wideint"), but fails in CI due to #8770. For now I leave the seed file unchanged without showing that the wide arithmetic instructions are generated in the golden file.

Also generated a new seed for test/lit/fuzz-import.wast since it was failing after these changes, seemingly due to bad luck (which the test file mentions is a possibility).

[kripken]

lgtm % comments

[kripken]

Why VeryImportant?

[stevenfontanella]

Changed the code a bit to skew the probabilities differently. After increasing the seed file size I see these statistics:

 ...
 SIMDLoad       : 1       
 SIMDReplace    : 2       
 SIMDShuffle    : 1       
 SIMDTernary    : 2       
 TupleExtract   : 113     
 TupleMake      : 150
 WideIntAddSub  : 1

(I can't check in the increased seed size because of #8770) It's still a lower proportion of wide arithmetic instructions than I'd like (WideIntMul doesn't appear at all). I'm a little confused on why this is because the correct type is generated for 50% of tuples:

binaryen/src/tools/fuzzing/fuzzing.cpp

Lines 6457 to 6459 in e63a6d5

	if (wasm.features.hasWideArithmetic() && oneIn(2)) {
	return Types::getI64Pair();
	}

. Then if the type matches, 50% of the time a wide arithmetic instruction is generated:

binaryen/src/tools/fuzzing/fuzzing.cpp

Lines 2816 to 2817 in e63a6d5

	if (type == Types::getI64Pair() && oneIn(2)) {
	options.add(FeatureSet::WideArithmetic, &Self::makeWideIntExpression);

. So I would expect wide arithmetic instructions to appear 1/3 as often as TupleMake (25% versus 75%).

One possible reason for the difference is that TupleMake can appear in constant expressions and wide arithmetic can't. Maybe in practice a large number of tuple types appear in constant expressions rather than function bodies? Anyway the proportion of wide arithmetic instructions is comparable to some existing SIMD instructions, so I'm ok with it as-is. I'm curious if you have any thoughts in any case.

[stevenfontanella]

Tried to give wide arithmetic instructions more probability by including them in constant expressions, but I realized that they're not actually constant expressions. Let me send another update.

[stevenfontanella]

Tried to give wide arithmetic instructions more probability by including them in constant expressions, but I realized that they're not actually constant expressions. Let me send another update.

Done.