I'm wondering is it possible to fix this issue without increasing stack with this PR?
WebAssembly/binaryen#5646

The other PR seems to address stack overflows in setMemory only, where previously all the data segments were allocated on the stack, easily overflowing it, hence proposing that these are instead allocated on the heap. The issues seen here, however, appear to happen during optimizations, more precisely in chains of PrecomputingExpressionRunner::visit that overflow the stack. From a quick glimpse, what happens is that visitBinary for example creates additional expression runners, incl. for LHS and RHS, so if there are sufficiently nested binaries within binaries for instance, the stack overflows. Makes me wonder, rather, whether the design of expression runners can be improved, since even if we increase stack size x10, this doesn't prevent that x10 complex nested expressions still overflow the stack. Some additional details in WebAssembly/binaryen#5648.