Raising the limit on the number of locals in input files

[vouillon]

The wasm_of_ocaml compiler is generating code using a fresh local variable for each intermediate value. We rely on wasm-opt to optimize this. Since #6677, the binary parser will reject functions with more then 50,000 locals. We are currently reaching this limit on some large programs. Maybe it would make sense to raise this limit since wasm-opt is expected to take as input unoptimized code. Or maybe there should be an option to lift the limit?

[kripken]

Good point, I agree we should change this. I think the check should error on 2^32 which is the absolute limit in the spec, and which has a spec test, while for the Web limit of 50,000 we should just warn like we do here:

binaryen/src/wasm/wasm-binary.cpp

Lines 471 to 474 in ccef354

	if (func->getParams().size() > WebLimitations::MaxFunctionParams) {
	std::cerr << "Some VMs may not accept this binary because it has a large "
	<< "number of parameters in function " << func->name << ".\n";
	}

And that warning should be during writing, not reading.

Would you like to open a PR for that?

[vouillon]

Ok, I'll do that.

@tlively mentioned an issue with allocation failures on CI as a justification for this limit. I'm not sure what he meant.

[kripken]

Oh, we do allocate a vector for locals (whose elements are pointers, so 8 bytes in 64-bit), so trying to allocate one of length 2^32 might indeed hit a CI limit. And it does look like the test has 2^32 - 1 locals of one type and then one of another, so we allocate almost 2^32 before the error. That could be fixed by first reading the counts and types, validating, and only then adding to currFunction->vars if valid.