Enable the wast::Cranelift::spec::simd::simd_align test for AArch64

[akirilov-arm]

wast::Cranelift::spec::simd::simd_address also passes, even though there aren't any changes specifically for it.

Note that this PR makes the assumption that execution happens in a little endian environment; currently the AArch64 backend doesn't seem ready to deal with big endian anyway.

[github-actions]

Subscribe to Label Action

cc @bnjbvr

This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64"

Thus the following users have been cc'd because of the following labels:

• bnjbvr: cranelift

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

Thanks, LGTM!

Re: little-endian vs. big-endian -- yes, we don't have a notion of any sort of config option for aarch64be, and a lot of other things would have to change as well, so I think the comment you left is fine.

[cfallin]

Hmm, the CI seems to be hitting a test timeout (or just a really slow test -- our aarch64 tests run under qemu on the x86 CI hosts):

test wast::Cranelift::spec::start ... test wast::Cranelift::spec::start has been running for over 60 seconds
error: test failed, to rerun pass '-p wasmtime-cli --test all'

Not sure what's going on -- did tests pass for you locally?

[akirilov-arm]

I usually test with cargo test --all --exclude lightbeam, which passes locally. However, I run everything in an actual AArch64 environment - no emulation.

[cfallin]

I re-kicked the tests; likely just a spurious issue then. If still not green then I can look into the timeout settings.

[cfallin]

It appears there's a merge conflict now since we merged Joey's PR (#1801) -- sorry about that!

[akirilov-arm]

Now the build fails for reasons that are completely unrelated to my changes:

   --> crates/runtime/src/mmap.rs:185:55
    |
185 |         unsafe { region::protect(ptr.add(start), len, region::Protection::ReadWrite) }
    |                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `-D deprecated` implied by `-D warnings`

error: aborting due to previous error

error: could not compile `wasmtime-runtime`.

[cfallin]

Yep, I'm seeing the same CI build failure elsewhere; raised the issue on Zulip.

[cfallin]

@akirilov-arm we've fixed the CI issue on master, so if you rebase, the tests should pass now. Sorry about all the trouble!

[akirilov-arm]

It's still not clear to me why there are failures - this is the only information that I find in the log:

2020-06-03T22:34:04.7756111Z error: test failed, to rerun pass '-p wasmtime-cli --test all'
2020-06-03T22:34:04.8390830Z
2020-06-03T22:34:04.8395010Z Caused by:
2020-06-03T22:34:04.8429995Z   process didn't exit successfully: `/home/runner/qemu/bin/qemu-aarch64 -L /usr/aarch64-linux-gnu /home/runner/work/wasmtime/wasmtime/target/aarch64-unknown-linux-gnu/release/deps/all-1543c4079f5cddb8` (signal: 9, SIGKILL: kill)
2020-06-03T22:34:04.9333419Z ##[error]Process completed with exit code 101.

In particular, the tests that my changes are supposed to enable pass.

[akirilov-arm]

@cfallin I'll give it another try after the recently merged test fixes.

[akirilov-arm]

I am unable to get any useful log output from the latest CI failure - it looks like a timeout?

I have also tried running the tests locally on a x86 machine with QEMU 5.0.0. I have used the following command line (based on what CI is doing):

QEMU_LD_PREFIX=/usr/aarch64-linux-gnu cargo test --features test-programs/test_programs --release --all --exclude lightbeam --exclude peepmatic --exclude peepmatic-automata --exclude peepmatic-fuzzing --exclude peepmatic-macro --exclude peepmatic-runtime --exclude peepmatic-test --exclude wasmtime-fuzz --target aarch64-unknown-linux-gnu

Everything completes successfully.

@cfallin I am at a loss about how to proceed. It looks like everything is correct on my end and I am just blocked by CI issues.

[cfallin]

Sorry the CI is being so temperamental... I kicked the jobs again; let's see what happens. If still an issue, I can ping some others who know more about our CI setup.

[cfallin]

Job failed again with a segfault in qemu. Perhaps it's an issue with the qemu setup we have? We appear to be using version 4.2.0, according to the custom qemu build commands in our GitHub CI config. @alexcrichton , is there a way we could use a newer qemu? @akirilov-arm, is there a way you could try to replicate with 4.2.0 (to see if this is a qemu bug)?

[alexcrichton]

FWIW segfaults in qemu I've found are typically bugs in qemu (and are somewhat common, especially with things like fanciful instructions). It should be easy enough to update the copy in CI by updating this URL, and if it's working locally with 5.0.0 updating CI should do the trick! If you've got trouble doing that though I'd be happy to help

[cfallin]

@akirilov-arm I just rebased your commit on top of our qemu update -- let's see if this works.

[akirilov-arm]

FYI QEMU 4.2.0 works for me too. However, I have one remark - I didn't notice any segmentation faults in the old log, rather SIGKILL (it was the same error message as the one I posted above). Now, I am not familiar with the CI setup, but if I have to make a wild guess, I'd say we are running out of memory (and the OOM killer springs into action). Of course, I have no idea why any of the other PRs don't fail, including the ones that touch the AArch64 backend. As I said, that's just a wild guess.

[alexcrichton]

Yeah it actually sort of looks like OOM of some form since I can't see logs from the builders. One possibility is to turn down the concurrency to just one on aarch64 tests, but otherwise it's probably ok to not enable the tests here just yet and we can figure out how to do that in CI later.

[cfallin]

@akirilov-arm if you want to simply re-disable the test, I'm OK with merging this now; maybe open an issue for the SIGKILL-afflicted test and add a FIXME on the line that disables it?

[akirilov-arm]

OK, I will rework the patch, so that the vector element extensions go in (we need them for some upcoming changes; for example, I have already implemented what's necessary for simd_load_extend, but I have been waiting for this PR to get merged), but I won't enable any tests. Let's revisit them later.

[cfallin]

Thanks!