simd: apply some fixes to test generation

[evacchi]

This fixes some aspects of the SIMD test codegen, introducing some (debatable) wider changes, so I'm going to push this as a draft, to let you judge :) some of these changes could be also applied to a utility class, but this should be the gist anyway

• I am now passing args through an MStack so that we can push V128s onto it: the reason is that codegen might become complicated otherwise: each v128 is a long[] so, you would have to "unpack" each long to several pushes. This way you can just push it all at once.
• I have added an Mstack.pushAll(long[]) method, so that we can easily push vectors all at once.
• I have added an MStack.slice(start, len) method returning a copy of the array (thus, only useful for tests), so that
  a. all places expecting a given arg size (e.g. I have seen this behavior in the new tail call feature) do not get confused by a larger input array
  b. we can pass in a number of values we want to pull; this is important when there are v128 values, since they are size=2
• I have added a WasmValueType.size() that is 2 for v128 and 1 otherwise

I have also added a few more missing (?) lanes (i64x2, F64x2) and the reverse of vecTo32(), etc...

I will add some other notes inline.

@mfirry this should unblock you!

folks, feel free to push directly to this branch to apply your fixes on top

[evacchi]

I think we don't need to parse these into Float bits in this case, the raw integer will do

[evacchi]

notice, this is not correct, but works for now. It should be adapted to do same thing as the lines below, but it required a little more refactoring, and I wanted to push this out quickly to unblock @mfirry

[cloudflare-workers-and-pages]

Deploying chicory with    Cloudflare Pages

Latest commit:	55c7a9f
Status:	✅  Deploy successful!
Preview URL:	https://6f99da75.chicory.pages.dev
Branch Preview URL:	https://simd-testgen-fixes.chicory.pages.dev

View logs

[evacchi]

here's an example of a test (simd_bitwise) after the change:

    @Test()
    @Order(9)
    @DisplayName("simd_bitwise.wast:31")
    public void test9() {
        ExportFunction varAnd = testModule0Instance.export("and");
        var args = new MStack();
        args.pushAll(i32ToVec( new long[] { Long.parseUnsignedLong("0"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("4294967295"), Long.parseUnsignedLong("4294967295") }));
        args.pushAll(i32ToVec( new long[] { Long.parseUnsignedLong("0"), Long.parseUnsignedLong("4294967295"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("4294967295") }));
        var results = varAnd.apply(args.slice(0, 4));
        var expected = new long[] {Long.parseUnsignedLong("0"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("4294967295") };
        assertArrayEquals(expected, vecTo32(results));
    }

vs before:

    @Test()
    @Order(9)
    @DisplayName("simd_bitwise.wast:31")
    public void test9() {
        ExportFunction varAnd = testModule0Instance.export("and");
        var results = varAnd.apply(new long[] { 0, 0, 4294967295, 4294967295 }, new long[] { 0, 4294967295, 0, 4294967295 });
        var expected = new long[] {Long.parseUnsignedLong("0"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("0"), Long.parseUnsignedLong("4294967295") };
        assertArrayEquals(expected, vecTo32(results));
    }

notice:

• varAnd.apply() took 2 long arrays (incorrect)
• we wrap the two arg vectors intoi32ToVec(), because even though it's 4 longs each, they should be treated as i32x4 consts, i.e. 4 integers for a v128 value
• we avoid having to concat the 2 resulting long[2] arrs by pushing to a stack instead
• 4294967295 is an integer literal so it errors out because it won't fit (you can add L, but it's more correct to treat it as unsigned)

notice that it's not strictly necessary to modify MStack, we can also implement and ad-hoc stack or utility class (e.g. "TestArgs") only for tests

[evacchi]

FYI, I'll be AFK for the rest of the week, so feel free to rebase/change/rewrite this PR 👋

[andreaTP]

Thanks @evacchi for the effort!
For anyone landing here, I like where this is going, and I think is close enough.
Two missing steps:

• do not use MStack directly in the tests, if there are no cases where the types of the arguments are diverging I'd like to see something like:

var results = varAnd.apply(i32ToVec(new long[] { 0, 0, 4294967295, 4294967295 }, new long[] { 0, 4294967295, 0, 4294967295 }));

• add some generated tests to guarantee the fix is working

if anyone wants to step up and bring this to conclusion, just drop a message! 🙏

[andreaTP]

Updated to use an ArgsAdapter instead of MStack, we need to progress in arguments and local size tracking, I started here: fa6bea1

for anyone that want to take over the work.

[andreaTP]

A couple of nitpicks but this is ready to go, thanks 👍

[andreaTP]

Nothing critical, but FYI @electrum , personally I think it's fine to relax those checks as most of the spec have already been included and we will still review the incoming PRs.

[andreaTP]

LGTM, this is ready to go, thanks @evacchi !