"Optimized" bulk array instructions, e.g. `array.new_copy`

[Liedtke]

This is a follow-up to #313 (comment) where the question was raised whether we'd need or want to have an array.new_copy instruction.

We have a micro-benchmark mainly consisting of copying an existing array.
Right now, the sequence is array.new_default followed by an array.copy.

There are two options to skip the default initialization of the array:

1. We rely on engines detecting such patterns and optimizing it (e.g. skipping initialization if the array.new is followed by an array.copy with the same bounds as the array.new.)
2. Adding a new instruction array.new_copy that combines the two, relying on code generators / tool chains to make sure to use these instructions in such cases.

A second very common use case is growing a backing store. For that we'd need at least one more parameter which is the size of the new array. To make it more universally useful, I tried to collect use cases for "create a new array based on (some) contents of an existing array":

1. Copy an array.
2. Grow a backing store.
3. Slice an array. (Array.prototype.slice in JS or arr[a:b] in Python)

Now there could be also use cases where the content of the source array would not appear at the beginning, although those should be rather rare, one example would be "test".rjust(6, "x") in Python which would produce xxtest. (assuming using 1 Byte ASCII arrays)

If we wanted to support all these use cases with an "optimized" instruction, we'd end up with the following parameters:
(source_array, source_start_index, copy_length, target_start_index, target_length, default_value)
with some constraints like copy_length <= min(target_start_index + target_length, array.len(source_array) + source_start_index).

At least for use-case (1) this would already feel unnecessarily complicated to just copy an array.

How do people feel about this? Should it be the responsibility of the engine to optimize such patterns or should WebAssembly provide more specific instructions to be able to express the desired semantic in a more specific way?
And would we be interested in having an array.new_copy as part of the MVP?

[tlively]

We discussed this at the meeting this morning and decided more complicated bulk array instructions like this would be in-scope for a post-MVP proposal.

[mkustermann]

Apart from the fusion of array creation & copy instructions, a array.new_copy instruction would be very valuable to create arrays of const field types:

Right now one cannot create arrays with const field types of unknown length. The length currently has to be known at compile type and has to be below 10k and the array has to be created using array.new_fixed.

=> A new array.new_copy instruction could solve this limitation by allowing to create const array types of arbitrary length from mutable arrays. See #570