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.

[kripken]

Good question - I dont know. It might be worth seeing if this is a fluke on this data, and if not, looking at stack traces or debug prints to see why this happens. I'm surprised by it.

[stevenfontanella]

Added some logging and I found that the vast majority of tuple.make instructions come from makeConst, e.g. with 171 TupleMakes generated, 165 came from makeConst and 6 did not (I guess these came from makeConcrete or something similar). With these proportions it makes sense that we'd see very few wide arithmetic instructions.

Based on this, I think we should have a follow-up fix to increase the odds of non-const expressions compared to const expressions.

[kripken]

Interesting, thanks for looking into this!

It is possible makeConst is called from makeTrivial - we end up emitting only constants past some depth (to avoid using all the random data immediately). Not sure offhand how best to adjust that, if so.

[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.

[stevenfontanella]

Will continue this and test the fuzzer in #8781.