Add multi-threaded tests for acquire/release atomics

[stevenfontanella]

• Add multi-threaded execution tests exercising acquire/release atomics
  • Most tests demonstrate at least one possible result that would not be possible with seqcst. It's impossible to write a test that would fail on an engine that implements acqrel using seqcst, since strengthening an atomic operation is always sound.
  • (atomic.fence acqrel) currently can't be exercised in a way that's correct without being completely redundant alongside another acqrel load/store. With a relaxed memory ordering the test would make more sense.
• Invoke the pause instruction in the basic.wast test which was previously unexercised
• In support.split_wast, ensure that (thread ...) and (wait ...) expressions are captured in the split output (the latter is currently a no-op anyway but best to include it for readability and correctness).
• Rename relaxed_atomic_execution_tests -> acquire_release_atomics_execution_tests to match the new proposal name
• The new tests pass in Binaryen's interpreter in an uninteresting way because (thread) blocks always run sequentially in a blocking manner.

[tlively]

Is there a way to express "either (1, 2) or (3, 4) or (2, 4)" with the either construct? Or would you have to write test code to explicitly check that kind of condition?

[stevenfontanella]

I think we would have to write test code. We can't have either of a product, instead it has to be a product of eithers like I have here:

Are you asking for testing seqcst?

[tlively]

Right, I was having trouble understanding how to read this because I would have expected either to be more powerful. It's fine for this case, but it would be useful to have more expressive power for the seqcst case.

[stevenfontanella]

I'll leave it for now, and if we have a seqcst test in the future it might make more sense to make both into a check function.

[tlively]

It's awfully inconvenient to have to repeat so much of the module contents on each thread! It might be worth going back and adding some richer .wast infrastructure either in the original threads repo or as part of the acquire-release proposal.

[stevenfontanella]

I looked into this and one potential solution is the (module definition ...) and (module instance ...) syntax from the upstream spec interpreter (example). I think we would have one module that exports the shared memory, then a module definition that imports the shared memory and exports functions for the spinlock, then each threads instantiates the second module separately.

But I think we should wait on this solution, since the threads repo (and thus the acquire-release-atomics repo) is behind the upstream spec and doesn't support this syntax, so we wouldn't be able to run this on the spec interpreter. I'd suggest that we keep it this way and simplify the test once the threads + acquire-release-atomics interpreter have support for this syntax.

[tlively]

Sounds good to me 👍

[tlively]

Sounds good to me 👍